[KI-LC] Call for Votes: Concordia DG Interim Report - Deployment Guide for Proxying Assurance between OpenID and SAML
Bob Pinheiro
kantara at bobpinheiro.com
Thu Jun 3 12:20:57 EDT 2010
Paul,
Yes, I think we can say that SAML is more appropriate for higher LOA,
and OpenID for lower LOA. What I was suggesting is that different trust
frameworks may emerge for different communities of interest such as
financial, healthcare, social media, government, etc. So a bank
presumably wouldn't be requesting a low assurance claim/assertion from a
SAML IdP in the first place. But if there were different banking
transactions that required either a low assurance or high assurance
claim/assertion, then it seems as if the banking RP ought to know that
and request the appropriate claim/assertion directly from an IdP/OP it
trusts for those kinds of claims/assertions. So if this view is
correct, there would be no need for a SAML IdP to proxy to a OpenID OP.
Unless maybe the SAML IdP advertises that it also provides low assurance
claims/assertions as well, and to lower costs it outsources the job to
an OpenID OP. "One stop shopping", so to speak. Which I guess brings
us back to where we started.......
Bob
On 6/3/2010 11:26 AM, Paul Madsen wrote:
> Hi Bob, thanks for your thoughts,
>
> The original thinking for this use case was, as you say, that the SAML
> IdP would choose to focus on those higher LOA authentications for
> which it could charge more (or at all) - and outsource the lower LOA
> authns to an OP.
>
> While it would seem easy for an IdP capable of high LOA to also
> support lower LOA (throwing it in for free perhaps), doing so wouldnt
> be without cost (e.g. password resets, etc) additional to the costs of
> supporting the higher LOA.
>
> To a degree, the SAML IdP in this case is making the same analysis as
> do some SPs, ie keeping higher LOA authentications to itself while
> using OpenID for lower. The difference here is that the original
> authentication request comes from an external SP.
>
> There is very definitely an implicit assumption in the use case that
> SAML is more appropriate than OpenID for higher LOA use cases. But
> this is validated by ICAM is it not?
>
> thanks again
>
> paul
>
>
>
> On 03/06/2010 11:02 AM, Bob Pinheiro wrote:
>> Even though I already voted in support of acceptance, one thought does
>> occur to me which maybe (or maybe not) would be useful to address in the
>> Motivation section of the report. The point is made that a SAML RP
>> might request an assertion from a SAML IdP at a lower LOA than supported
>> by the IdP; therefore the IdP may want to proxy to an OpenID OP that can
>> provide the lower level assertion. Although this document isn't meant
>> to address business issues, I wonder why the SAML IdP wouldn't just
>> provide the lower level assertion or claim itself. There are two issues
>> I can think of that would come into play. One is that the higher level
>> assertion or claim would be more robust or contain more information than
>> would be required for a lower level claim/assertion. But why couldn't
>> the SAML IdP just provide a watered-down claim/assertion to satisfy the
>> lower assurance request? And since the subject already has higher
>> assurance credentials issued by the SAML IdP, those same credentials
>> would still be good for the lower assurance authentication.
>>
>> The second issue is that presumably the higher level claim/assertion is
>> more "expensive" for the IdP to provide. Depending on the business
>> model in play to compensate the IdP for its trouble, the SAML IdP could
>> just "charge" the RP a lower price for the lower level claim/assertion
>> (if that is the business model in use), or could provide it for free,
>> since OpenID providers don't charge anybody for their low assurance
>> assertions anyway.
>>
>> I think there's an underlying assumption that people may use SAML IdPs
>> for their high assurance identity needs, and OpenIDs for their low
>> assurance needs. It may more likely be the case that the need for
>> multiple IdPs revolves around the kinds of SPs/RPs that people will
>> interact with.....so financial SPs/RPs may trust certain IdPs,
>> healthcare SPs/RPs may trust different IdPs, etc. depending on which
>> IdPs/OPs are conformant to different trust frameworks that may emerge
>> for these different communities. Or maybe not. Anyway, these kinds of
>> issues are probably better addressed elsewhere.....maybe in the Consumer
>> Identity WG.
>>
>> Bob
>>
>> ---------------------------
>> Bob Pinheiro
>> Chair, Consumer Identity WG
>> 908-654-1939
>> kantara at bobpinheiro.com
>> www.bobpinheiro.com
>>
>>
>>
>> On 6/1/2010 3:11 PM, J. Trent Adams wrote:
>>
>>> All -
>>>
>>> This is a call for you to vote on the following motion regarding the
>>> acceptance of an Interim Report from the Concordia Discussion Group.
>>> Please reply according to the options listed below.
>>>
>>> -----
>>> MOTION: To accept the Concordia Discussion Group Interim Report titled
>>> "Deployment Guide for Proxying Assurance between OpenID and SAML" as
>>> submitted to the Leadership Council Secretary on June 1st, 2010. [1]
>>> -----
>>>
>>>
>>> Your options:
>>>
>>> A. Reply with any discussion on this motion prior to voting.
>>>
>>> B. Reply to this message with a "YES" if you support the
>>> acceptance of the interim report.
>>>
>>> C. Reply to this message with a "NO" if you do not support
>>> accepting the interim report. Also, please include your
>>> rationale for a "NO" vote.
>>>
>>> D. Reply to this message with an "ABSTAIN" if you abstain.
>>>
>>> The deadline for voting is Tuesday, June 8th at 23:59 UTC.
>>>
>>> This vote requires a Simple Majority to pass (i.e. more than 50% of
>>> votes received - excluding abstentions).
>>>
>>> Thanks in advance,
>>> Trent
>>>
>>> [1]
>>> http://kantarainitiative.org/confluence/download/attachments/41650124/Kantara-concordiadg-proxyingassurance-report-08.pdf?version=2&modificationDate=1274824442000
>>>
>>>
>>>
>>>
>> _______________________________________________
>> LC mailing list
>> LC at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/lc
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG -www.avg.com
>> Version: 9.0.819 / Virus Database: 271.1.1/2915 - Release Date: 06/03/10 02:25:00
>>
>>
>
>
> _______________________________________________
> LC mailing list
> LC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/lc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/lc/attachments/20100603/7dff26f2/attachment.html
More information about the LC
mailing list