Delegation discussion summary

Dick Hardt dick at sxip.com
Sun Oct 15 03:04:38 UTC 2006 

Would you elaborate on those use cases? The current draft does not  
support this.

-- Dick

On 13-Oct-06, at 8:52 AM, Granqvist, Hans wrote:

> I can see potential use-cases where Alice doesn't want the
> idp to know what her portable URL is.  This would not work
> if the protocol requires "both" as per below.  Can it be
> solved by sending a hash of the portable identifier?
>
>
>> -----Original Message-----
>> From: specs-bounces at openid.net
>> [mailto:specs-bounces at openid.net] On Behalf Of Josh Hoyt
>> Sent: Thursday, October 12, 2006 10:29 AM
>> To: specs at openid.net
>> Subject: Delegation discussion summary
>>
>> Hello, list,
>>
>> I'm sure that another message in your inbox with "delegation"
>> in the title makes most of you cringe, so I'm sorry for
>> that.I hope that this one gets us closer to resolving this issue.
>>
>> I have attempted to summarize the proposed delegation
>> mechanisms, as well as the currently-specified delegation
>> mechanism in a single document. I have glossed over some
>> issues and left out some of the discussion, but I hope that I
>> captured most of the important stuff.
>> After reviewing the discussion, I think that we are actually
>> pretty close to consensus on a course of action.
>>
>> I have added one new thing in this write-up, which is that I
>> have started calling "delegation" "portable identifier
>> support", which gives rise to the term "portable identifier"
>> for what is currently called a "delegated identifier." I
>> think that this terminology is a little easier to understand
>> and less loaded than calling it "delegation."
>>
>> My write-up follows.
>>
>> Josh
>>
>> OpenID portable identifier support
>> ##################################
>>
>> Portable identifier support allows an IdP to do
>> authentication for an identifier that was not issued by that
>> IdP. It has two motivating use cases [1]_:
>>
>>   * allow users to use any identifier with any IdP
>>
>>   * allow users to move an identifier between IdPs (prevent
>> IdP lock-in)
>>
>> Each portable identifiers has an IdP-specific identifier tied
>> to it. This identifier allows the IdP to know what
>> credentials to require before issuing an authentication
>> response even though the IdP does not control the portable  
>> identifier.
>>
>> Throughout this discussion, I will assume that there is a
>> portable identifier called "http://my.portable.url/" that
>> uses an IdP-specific identifier called "http://my.idp.specific.url/".
>>
>>
>> Current implementation
>> ======================
>>
>> OpenID 1 [2]_ calls portable identifier support "delegation."
>> In this implementation, the IdP-specific identifier is the
>> only identifier that is communicated between the relying
>> party and the IdP. When a relying party discovers that it is
>> requesting authentication for a portable identifier, it must
>> keep that state available for processing the response, since
>> the response message does not contain the portable identifier at all.
>>
>> Request and response messages for this mechanism both use the
>> following field::
>>
>>   openid.identity = http://my.idp.specific.url/
>>
>> This mechanism has a few drawbacks:
>>
>>  * The relying party must manage state information for the  
>> duration of
>>    the transaction.
>>
>>  * The authentication messages are potentially confusing, since the
>>    authentication response is not meaningful without the context of
>>    the initiation, and the IdP-specific identifier does not even have
>>    to be a valid OpenID identifier.
>>
>>   * The IdP *cannot* be aware that it is using a portable identifier,
>>    so the IdP cannot assist the user in making decisions for  
>> different
>>    identifiers. For example, a user might wish to be prompted for
>>    confirmation each time he used one identifier, but allow automatic
>>    approval for another.
>>
>>   * IdP-driven identifier selection in the OpenID 2.0
>> specification (up
>>    to draft 9) cannot return assertions for portable identifiers,
>>    because the verification algorithm will fail.
>>
>>   * Portable identifiers must be treated differently from IdP-issued
>>    identifiers by the code running on the relying party
>>
>>
>> Proposed changes
>> ================
>>
>> All of the changes to delegation that have been proposed
>> retain the important features of portable identifier support.
>> Additionally, they all retain the same basic structure, where
>> the IdP-specific identifier is available from the standard
>> discovery process. Primarily, the proposals change what data
>> is available in the protocol messages, the relationship of
>> the request to the response, and/or the party who is
>> responsible for discovering the IdP-specific identifier for
>> the portable identifier.
>>
>> Both of the proposed changes to the response messages include
>> the portable identifier in the authentication response.
>> Changing the response to contain the portable identifier
>> removes the burden of maintaining that state from the relying
>> party. Removing this dependency on transaction state enables
>> portable identifiers to be used in both IdP-driven identifier
>> selection and IdP-initiated authentication ("bare response") [3]_.
>>
>> Neither proposal outlined here changes the protocol unless a
>> portable identifier is used.
>>
>>
>> Both portable and IdP-specific identifiers
>> ------------------------------------------
>>
>> Include both the portable identifier and the IdP-specific
>> identifier in the request and response ([4]_ and
>> [5]_)::
>>
>>   openid.identity = http://my.idp.specific.url/
>>   openid.portable = http://my.portable.url/
>>
>> The relying party is still responsible for checking to make
>> sure that the IdP-specific identifier that is returned
>> matches what is discovered from the portable identifier, but
>> since it is included in the authentication response, it is
>> not necessary for the relying party to maintain this state,
>> and an authentication response is meaningful without the
>> context of the request.
>>
>> The messages in this proposal are very explicit about what is
>> going on. The only way in which this differs from OpenID 1 is
>> that the portable identifier is also included in the
>> response. The meaning of the "openid.identity" parameter is
>> identical to its meaning in the OpenID 1 protocol (the
>> IdP-specific identifier).
>>
>>
>> Portable identifier only
>> ------------------------
>>
>> Include only the portable identifier in the request and
>> response ([6]_ and [7]_)::
>>
>>   openid.identity = http://my.portable.url/
>>
>> In this proposal, the relying party does not use the
>> IdP-specific fields that are available during discovery. The
>> IdP must do discovery on the supplied identifier to determine
>> what IdP-specific identifier has been specified.
>>
>> This proposal simplifies relying party behavior. The messages
>> that are passed have an obvious meaning and are easy to
>> verify. The meaning of the "openid.identity" parameter is
>> different from its meaning in the OpenID 1 protocol.
>>
>>
>> References
>> ==========
>>
>> .. [1] "openid.delegate explained."
>>
>>        Brad Fitzpatrick, 3 October 2006
>>
>>        http://openid.net/pipermail/specs/2006-October/000182.html
>>
>>
>>
>> .. [2] "OpenID Authentication 1.1"
>>
>>        David Recordon, Brad Fitzpatrick, May 2006
>>
>>        http://openid.net/specs/openid-authentication-1_1.html
>>
>>
>>
>> .. [3] "[PROPOSAL] bare response / bare request"
>>
>>        Dick Hardt, 30 September 2006
>>
>>        http://openid.net/pipermail/specs/2006-September/000142.html
>>
>>
>>
>> .. [4] "cachability of delegated identity URLs"
>>
>>        Brad Fitzpatrick, 8 June 2006
>>
>>        http://lists.danga.com/pipermail/yadis/2005-June/000676.html
>>
>>
>>
>> .. [5] "Delegation Proposal Amendment"
>>
>>        Josh Hoyt, 6 October 2006
>>
>>        http://openid.net/pipermail/specs/2006-October/000269.html
>>
>>
>>
>> .. [6] "Proposal: IdP-supported delegation"
>>
>>        Josh Hoyt, 4 September 2006
>>
>>        http://openid.net/pipermail/specs/2006-September/000002.html
>>
>>
>>
>> .. [7] "PROPOSAL: OpenID Authentication Flow and how delegate fits  
>> in"
>>
>>        Dick Hardt, 9 October 2006
>>
>>        http://openid.net/pipermail/specs/2006-October/000310.html
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>

More information about the specs mailing list