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

John Bradley jbradley at mac.com
Thu Jun 3 14:05:55 EDT 2010

The issue with openID at LoA 2 is that the assertion is not protected from disclosure.

With SAML it may be protected by encryption or by using direct communications.

In any sort of proxy scenario between openID & SAML if such a thing were permitted by the ICAM Trust Framework the resulting ICAM LoA would be 1.

It is possible to configure SAML to be less secure than openID if you set your mind to it.  That is why there are deployment profiles.

It is fair to say that SAML when deployed appropriately can reach higher LoA than openID can currently.

Determining the resulting LoA of any transaction involving multiple protocols can be tricky.

Paul knew the ICAM comment would get me:)

John B.
On 2010-06-03, at 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/22e23b29/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/lc/attachments/20100603/22e23b29/attachment.bin 

More information about the LC mailing list