[KI-LC] Call for Votes: Concordia DG Interim Report - Deployment Guide for Proxying Assurance between OpenID and SAML
paulmadsen at rogers.com
Thu Jun 3 12:50:20 EDT 2010
thanks Bob, yes, another unstated assumption in the use case is that the
SAML SP chooses to not deploy OpenID but rather rely on the SAML IdP for
Separately, an SP participating in separate trust frameworks (perhaps
through different protocols) creates a different set of burdens. Perhaps
the Federation Interop WG activity mitigates that ....
I think I'm running out of 'unstated assumptions' now :-)
On 03/06/2010 12:20 PM, Bob Pinheiro wrote:
> 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.......
> 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
>> 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 Pinheiro
>>> Chair, Consumer Identity WG
>>> kantara at 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. 
>>>> 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,
>>> LC mailing list
>>> LC at kantarainitiative.org
>>> 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
> LC mailing list
> LC at kantarainitiative.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LC