[KI-LC] Call for Votes: Concordia DG Interim Report - Deployment Guide for Proxying Assurance between OpenID and SAML

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 