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: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt >> Sent: Thursday, October 12, 2006 10:29 AM >> To: [email protected] >> 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 >> [email protected] >> http://openid.net/mailman/listinfo/specs >> >> > _______________________________________________ > specs mailing list > [email protected] > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
