Hans, This has come up a few times and the mapping between the portable identifier and the IdP-specific identifier is available in public XRDS documents. So there's no point in trying to hide that information from the IdP -- and it may even be misleading to suggest to end-users that they could try to do so.
=Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Friday, October 13, 2006 8:52 AM To: Josh Hoyt; specs@openid.net Subject: RE: Delegation discussion summary 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: specs@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@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
