Re: Consolidated Delegate Proposal
Dick Hardt wrote: > > Won't the IdP will still have to resolve the i-name? The IdP can't > trust the RP, or know that the i-name and i-number are really linked > unless it checks itself. > The IdP is only authenticating the i-number. The i-name is for display to the user and possibly to allow the user to choose that as the display identity to send back to the RP. The only attacks possible are: * RP tries to "fool" the user into authenticating as a different i-number by sending a false i-name. I'm not sure what the benefit of this attack would be for the RP. * The RP tries to convince the IdP to send back an incorrect display identity back in the response. But then the RP is just fooling itself! The spec should probably contain some words to say that the IdP should not do any processing on the public identifier (whether it be a delegated HTTP URL or an XRI) that relies on the i-name to i-number mapping without first ensuring that the mapping is correct; any such processing would be outside of what is required for the Auth spec, though. Assuming for the moment that we've conceptually "separated the public identifier from the IdP token" per my proposal, the public (delegate) identifier or i-name is for the RP (it checks the mapping), and the IdP token (which is some URI that doesn't necessarily even have to be resolvable) is for the IdP. Both parties validate their own token; if either party doesn't validate its own token, it opens itself up to the other party telling lies. However, they do not have to authenticate *each-other*'s tokens. The RP's validation of its own token is defined by the spec. The IdP's authentication is not defined by the spec; the IdP doesn't necessarily even have to resolve its own tokens, but it can do if it wishes. >> Lastly, in the case where the identifier-the-RP-stores and the >> identifier-the-IdP-stores are different, if the RP has already >> discovered >> the latter, then the RP can be stateless by sending both to the >> IdP, knowing >> it will receive both back in the response. > > Then the RP is trusting the IdP will send back a correct mapping. This one bothers me too. Unless the RP can sign its initial request parameters to stop the IdP from tampering with them, I don't see how the RP can trust the IdP to return a correct mapping. My old stateless RP demo implementation just re-resolved this stuff when it got back the response to make sure that the IdP was telling the truth. I'd love to hear that this was unnecessary, since it did double the identity resolving overhead. > This discussion has me wondering about XRI resolution though. Given > that multiple i-names can resolve to the same i-number, just as > multiple domain names can resolve to the same IP address, and that > the i-name is the identifier the user sees, it would seem tht the i- > name is what should be stored by the RP, otherwise there is no > difference between using any of the i-names that resolve to the same > i-number, or is that the idea? I think this is the intention, though it does show an interesting inconsistency between the use of XRIs and the use of i-numbers. I currently have three URL-based identifiers all pointing at the same server and the same Yadis document, yet those identifiers are distinct. However, in the comparable XRI case, it would appear that those identifiers would all be considered to be the same. I wonder how easy it is to get hold of new i-numbers. If they are basically "throw-away" cheap, then I'm able to decide for myself how to distribute my mappings to separate them. However, if these i-numbers are going to be "expensive" (for some sense of the word) to aquire, I've got less freedom in this respect. Drummond? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Graves, Michael wrote: > > > I won't delve into where we are with respect to that capability here, > but want to suggest that maybe as we move to OpenID 2.0, and now offer > portable IDs (as well as run-time chosen IDs selected at auth-time?), we > may be wise to just make the jump to using "homesite" and "membersite" > across the board, rather than "IdP" and "relying party", both of which > are technically problematic for our framework. > I kinda get "homesite", but I don't understand the thinking behind "membersite": What is this site supposed to be a "member" of? Personally, I quite liked the old OpenID term "consumer". :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
Drummond Reed wrote: > +1 to getting it done. This area of terminology is more a > usability/marketing issue at this point. I agree we need to converge on > good, simple user-facing terms for describing OpenID in ways ordinary > Web users can easily understand. Although I have great respect for Dick > & Sxip’s pioneering work in this area, I don’t believe terms that use > the word “site” are the right metaphor, and the concept of “membersite”, > while good for the context Sxip originally used it, would send the wrong > message about OpenID. > > > > But I suggest we move that terminology discussion to the marketing list. > What marketing list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
Marius Scurtescu wrote: > On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote: > >> On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: >>> If passing through all unrecognized parameters can cause problems >>> then there could be a special namespace for this purpose. For >>> example, all parameters with names starting with openid.pass. should >>> be ignored by the IdP and passed back to the RP. >> Yahoo Browser-based authentication [1] has a single parameter called >> "appdata" (that you can find in [2]) that is used for this purpose. >> This seems general enough to me. > > True, even one single pass through parameter should do. This causes the minor inconvenience that the RP will probably now have to implement its own parsing, rather than using the framework's pre-supplied functions for dealing with urlencoded query strings. Not a major deal, but I'd guess that this is where the idea to use return_to args came from in the first place. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] request nonce and name
On 10/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote: > > True, even one single pass through parameter should do. > > This causes the minor inconvenience that the RP will probably now have > to implement its own parsing, rather than using the framework's > pre-supplied functions for dealing with urlencoded query strings. > > Not a major deal, but I'd guess that this is where the idea to use > return_to args came from in the first place. return_to arguments can only be trusted if they are taken from the signed return_to parameter, which means parsing the signed return_to parameter anyway. So it's at least no worse. It's better in that the parameters do not now appear twice in the response (once double-encoded) Example of a response with parameter in the return_to: http://a.url/?drink=0xC0FFEE%21&openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521&;... Example of a response with hypothetical openid.appdata field: http://a.url/?openid.appdata=drink%3D0xC0FFEE%21&openid.return_to=http%3A//a.url/&;... Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] request nonce and name
Hi All, Just so everyone remembers: "GET" encoded "http://"; URLs usually appear en-mass in public lists (from proxy cache logs). If you don't want to "POST" data anyplace, remember to expect "replay attacks" often. Kind Regards, Chris Drake Friday, October 13, 2006, 7:48:31 PM, you wrote: JH> On 10/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote: >> > True, even one single pass through parameter should do. >> >> This causes the minor inconvenience that the RP will probably now have >> to implement its own parsing, rather than using the framework's >> pre-supplied functions for dealing with urlencoded query strings. >> >> Not a major deal, but I'd guess that this is where the idea to use >> return_to args came from in the first place. JH> return_to arguments can only be trusted if they are taken from the JH> signed return_to parameter, which means parsing the signed return_to JH> parameter anyway. So it's at least no worse. JH> It's better in that the parameters do not now appear twice in the JH> response (once double-encoded) JH> Example of a response with parameter in the return_to: JH> http://a.url/?drink=0xC0FFEE%21&openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521&;... JH> Example of a response with hypothetical openid.appdata field: JH> http://a.url/?openid.appdata=drink%3D0xC0FFEE%21&openid.return_to=http%3A//a.url/&;... JH> Josh JH> ___ JH> specs mailing list JH> specs@openid.net JH> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Title: RE: Delegation discussion summary There is an established vocabulary, it should be used. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 09:04 PM Pacific Standard Time To: Gabe Wachob; Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary I'd have to agree with Gabe about this, let's get it done! :) -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time To: Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary *If* we are going to open up the terminology discussion, for me the terms "authenticating party" (formerly the "IDP") and "accepting party" (formerly the "relying party") seem more descriptive. The authenticating party issues authentication assertions in the form of special HTTP request/responses with the other party, who then accepts these assertions and decides whether or not they are good enough to let a user do something. As far as Dick's terminology, I'm not sure how "membersite" makes sense here. Perhaps it's a matter of history or perspective that I haven't been enlightened on. In any case, I'd rather get openid 2.0 out sooner than have a long discussion on terminology, so I won't push this any further unless someone else really thinks its valuable. Gabe > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf > Of Graves, Michael > Sent: Thursday, October 12, 2006 5:00 PM > To: specs@openid.net > Subject: RE: Delegation discussion summary > > Josh, et al, > > I believe the first of your options -- "Both portable and IdP-specific > identifiers" -- is the superior choice here. It preserves OpenID 1 > semantics, and unambiguously makes room for portable identifiers. I > don't see the added burden carried by relying party code for this option > viz. portable identifiers only as being significant. Recommend we > proceed with the "both" strategy. > > Also, this may be throwing a wrench in the gears here, but I'd like to > toss in the idea of using this point in time to pivot on our terminology > and look at adopting Dick Hardt's terminology here. Portable identifiers > are a powerful upgrade in and of themselves, and get us off the "IDP > lock-in" hook that I've been hung up with customers on now a couple > times. But as we move away from explicit IdP-specific URLs as the only > identifier, I think that the Sxip "homesite" model becomes more > important to consider as well. I very much like the idea of entiring in > my "homesite" URL at a participating "membersite" (OpenID relying > party), say "http://myidmanager.com" and during the authentication > process, being able to choose from one of n available personae managed > for me by myidmanager.com. So my "final" identifier may be > "http://myidmanager.com/73648729" or even "http://graves.isnuts.com". > > I won't delve into where we are with respect to that capability here, > but want to suggest that maybe as we move to OpenID 2.0, and now offer > portable IDs (as well as run-time chosen IDs selected at auth-time?), we > may be wise to just make the jump to using "homesite" and "membersite" > across the board, rather than "IdP" and "relying party", both of which > are technically problematic for our framework. > > Anyway, that's a bit off topic, but something to consider. > > In any case, the "both" option below gets my vote. > > Good work Josh! > > -Mike > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Josh Hoyt > Sent: Thursday, October 12, 2006 12:29 PM > 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
RE: Delegation discussion summary
Title: RE: Delegation discussion summary +1 -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 10:46 PM Pacific Standard Time To: 'Josh Hoyt'; 'Marius Scurtescu' Cc: specs@openid.net Subject: RE: Delegation discussion summary +1 to Josh's point. IMHO identifier portability is "sacred". If anyone disagrees, please post, can we assume we have consensus on this? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 8:56 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Delegation discussion summary On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The protocol does not need to touch on IdP-specific identifiers (aka > delegated identifiers) at all IMO. If there is a specified mechanism that must be supported for using a portable identifier, all IdPs will support it, so identifiers will actually be portable. You'd have a very difficult time trying to get people here to remove portable identifier support from the OpenID protocol. Josh ___ 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
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]_.
>
RE: Delegation discussion summary
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 i
RE: Delegation discussion summary
>> But I suggest we move that terminology discussion to the marketing list. >> > > What marketing list? http://lists.iwantmyopenid.org/mailman/listinfo/marketing. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 12-Oct-06, at 11:47 PM, Drummond Reed wrote: >> Marius wrote: >> >> I was suggesting that portability can be resolved between the user >> and >> the IdP. I cannot see how the protocol can help this by passing two >> identifiers. And if only the portable identifier is passed then >> there is >> no need to mention the IdP-specific identifier. > > Marius, see the analysis at > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now > updated > to include Josh's lastest thinking from > http://openid.net/pipermail/specs/2006-October/000357.html. > > In sum, not being able to send the IdP-specific identifier: a) > forces the > IdP to redo resolution, which is unnecessary and slows performance, > and Not necessarily. When you register with the IdP most likely you will claim all your portable identifiers with this IdP, so the IdP knows about them. > b) > prevents the protocol from being stateless. How? The RP deals only with the portable identifier and this is the only thing the IdP sends back. Why do you need state? Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
Makes sense, but do you *have* to put delegation info in an XRDS document? I'd like to think if I were to use an RP that I trust not to 'collude' with the IDP, there would be no reason for the IDP to know potential delegation? That gives me true identity portability and an open choice of IDPs. Once an IDP knows of and starts tracking my vanity identifier (bound to happen) I cannot easily give up that identifier. > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Friday, October 13, 2006 9:11 AM > To: Granqvist, Hans; 'Josh Hoyt'; specs@openid.net > Subject: RE: Delegation discussion summary > > 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
Use of i-numbers (was RE: Consolidated Delegate Proposal)
>Martin wrote: > >I think this is the intention, though it does show an interesting >inconsistency between the use of XRIs and the use of i-numbers. I >currently have three URL-based identifiers all pointing at the same >server and the same Yadis document, yet those identifiers are distinct. >However, in the comparable XRI case, it would appear that those >identifiers would all be considered to be the same. If they point to the exact same XRDS document with the same i-number as the CanonicalID, that would establish all three URLs and the CanonicalID i-number as synonyms (yes, it is possible to have URLs and XRIs that are synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new BackRef element that will enable an XRDS document to back reference any type of identifier that points to it, such as a URL, so you can machine-verify the back reference if you want. If you wanted to keep the three URLs as distinct, separate identities, point them at three different XRDS documents with different i-numbers. >I wonder how easy it is to get hold of new i-numbers. If they are >basically "throw-away" cheap, then I'm able to decide for myself how to >distribute my mappings to separate them. However, if these i-numbers are >going to be "expensive" (for some sense of the word) to aquire, I've got >less freedom in this respect. Drummond? The short answer is that delegated i-numbers (and this is the federated identifier meaning of the term "delegation") are as "throw-away" cheap as URL (at the path level), third-level DNS names, or any other form of delegated identifier. The "cost" is all in resolution, i.e., someone somewhere maintaining a registry that will point you to the XRDS document if you resolve it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Delegation discussion summary
>>> Marius wrote: >>> >>> I was suggesting that portability can be resolved between the user >>> and >>> the IdP. I cannot see how the protocol can help this by passing two >>> identifiers. And if only the portable identifier is passed then >>> there is >>> no need to mention the IdP-specific identifier. >> >> Marius, see the analysis at >> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now >> updated >> to include Josh's lastest thinking from >> http://openid.net/pipermail/specs/2006-October/000357.html. >> >> In sum, not being able to send the IdP-specific identifier: a) >> forces the >> IdP to redo resolution, which is unnecessary and slows performance, >> and > >Not necessarily. When you register with the IdP most likely you will >claim all your portable identifiers with this IdP, so the IdP knows >about them. With XRI i-name/i-number infrastructure that's neither practical nor desirable. With XRIs, users control their own synonyms, i.e., I can register a delegated i-name within a specific community (for example, at @example.community I could register @example.community*drummond) and then point that at my personal i-name (=drummond.reed) and the IdP for =drummond.reed will never know -- and doesn't need to know. I could go to any RP and login in as @example.community*drummond, the RP will resolve this to =drummond.reed (through the way XRI resolution automatically handles reference processing -- let me know if you want more info about this), and end out storing the CanonicalID i-number for =drummond.reed (which is =!F83.62B1.44F.2813). >> b) prevents the protocol from being stateless. > >How? The RP deals only with the portable identifier and this is the >only thing the IdP sends back. Why do you need state? It follows from the above. But this is so important that I'm going to send a separate message about it. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Identifier portability: the fundamental issue
Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following "postulate": "To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier)." I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: Yesterday we established consensus that with OpenID, identifier portability is sacred. Could somebody please post a succinct definition of "identifier portability" somewhere. If we have a new religion, we might as well agree what it is ;-) Preferably a public web page. Starting a list of "Design principles" comes to mind, I mean "List of sacred cows" or something ;-) Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and I agree, but I'm not sure that this is a big issue. Won't a simple cookie be sufficient? Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
> "To achieve identifier portability in OpenID, it MUST be > possible for the RP and the IdP to identify the user using > two different identifiers: an identifier by which the RP > knows the user (the portable identifier), and an identifier > by which the IdP knows the user (the IdP-specific identifier)." There is no reason why the idp MUST require to know both identifiers for identifier portability to be possible in the system. > I would submit that if this postulate is true, then OpenID > Authentication 2.0 requires two identifier parameters because > if the protocol only allows sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must > keep state to maintain mapping to the portable identifier (bad), and Why is it so bad for an RP to be required to maintain such state? (Besides, an RP could advertise whether it is willing to keep that state, and the user would decide what to do.) Keeping such state seems a very slight inconvenience for a much greater goal: true portability of my identifiers. What the idp doesn't know, it cannot take away. > ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
On Fri, 13 Oct 2006, Granqvist, Hans wrote:
> > "To achieve identifier portability in OpenID, it MUST be
> > possible for the RP and the IdP to identify the user using
> > two different identifiers: an identifier by which the RP
> > knows the user (the portable identifier), and an identifier
> > by which the IdP knows the user (the IdP-specific identifier)."
>
> There is no reason why the idp MUST require to know both
> identifiers for identifier portability to be possible in
> the system.
Existence proof: OpenID 1.1 does identifier portability without two
identifiers in the spec.
And despite all the "but it can't be stateless without two!" noise, it
actually can: you put the portable identifier in the return_to URL and
verify it again when you get the signature back from the IdP. That is,
verify the mapping from portable -> IdP-specific still holds. Because you
can't just trust the 1 (or 2) values you get back from the IdP, otherwise
the IdP (which could be malicious) could be fucking with you, asserting a
portable identifier which it's not actually permitted to do, according to
the portable identifer's YADIS//etc.
So with 1 or 2, you still need to verify, but that verification doesn't
have to be painful: you can cache it. "But that's state! omg!" Okay,
so don't cache it and re-check it. But OpenID's been all about the
state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Counter-argument: but OpenID 1.1 does have two parameters: one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not "openid.", but something else...
the Perl library uses "oic." or something). So then it's harder to
document the correct behavior to people ("RPs should verify the mapping
when you get a signature!") because the parameter names aren't consistent
between RP clients.
So whether it's in the spec formally or not, I don't really care. But the
spec MUST contain details on the precautions a RP should take.
- Brad
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Delegation discussion summary
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote: Marius wrote: I was suggesting that portability can be resolved between the user and the IdP. I cannot see how the protocol can help this by passing two identifiers. And if only the portable identifier is passed then there is no need to mention the IdP-specific identifier. >>> >>> Marius, see the analysis at >>> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now >>> updated >>> to include Josh's lastest thinking from >>> http://openid.net/pipermail/specs/2006-October/000357.html. >>> >>> In sum, not being able to send the IdP-specific identifier: a) >>> forces the >>> IdP to redo resolution, which is unnecessary and slows performance, >>> and >> >> Not necessarily. When you register with the IdP most likely you will >> claim all your portable identifiers with this IdP, so the IdP knows >> about them. > > With XRI i-name/i-number infrastructure that's neither practical nor > desirable. With XRIs, users control their own synonyms, i.e., I can > register > a delegated i-name within a specific community (for example, at > @example.community I could register @example.community*drummond) > and then > point that at my personal i-name (=drummond.reed) and the IdP for > =drummond.reed will never know -- and doesn't need to know. I could > go to > any RP and login in as @example.community*drummond, the RP will > resolve this > to =drummond.reed (through the way XRI resolution automatically > handles > reference processing -- let me know if you want more info about > this), and > end out storing the CanonicalID i-number for =drummond.reed (which is > =!F83.62B1.44F.2813). I don't see the point if hiding some of your portable identifiers (@example.community*drumond) from your IdP and at the same time disclose it to all the RPs you deal with. If you are using a portable identifier and you have an IdP then it seems normal to me to trust your IdP to know your portable identifier. I would be more nervous about all the RP knowing my IdP issued identifier. What is not practical about registering your portable identifier with your IdP? > >>> b) prevents the protocol from being stateless. >> >> How? The RP deals only with the portable identifier and this is the >> only thing the IdP sends back. Why do you need state? > > It follows from the above. But this is so important that I'm going > to send a > separate message about it. I can't see it, sorry. If the RP is indexing your account based on your i-number then it could send your i-number to your IdP for authentication, but it can also send your i-name. I don't think it matters. The IdP should know both and it can lookup your account with any of them. What state must the RP save? The RP has both your i-name and i-number as well (unless you are registering), so when the response comes back it can look you up with any. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: > Yesterday we established consensus that with OpenID, identifier > portability > is sacred. > > Today I'd like to establish consensus on the following "postulate": > > "To achieve identifier portability in OpenID, it MUST be possible > for the RP > and the IdP to identify the user using two different identifiers: an > identifier by which the RP knows the user (the portable > identifier), and an > identifier by which the IdP knows the user (the IdP-specific > identifier)." > > I would submit that if this postulate is true, then OpenID > Authentication > 2.0 requires two identifier parameters because if the protocol only > allows > sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must keep > state to > maintain mapping to the portable identifier (bad), and I agree with that. > > 2) If the RP sends the portable identifier, an IdP is forced to do a > resolution a second time after the RP has already done resolution > (bad). No, the IdP is not forced to do a resolution. The IdP already knows that. > > OTOH, if the postulate is false, then a case can be made for OpenID > Authentication 2.0 having just one identifier parameter. > > PROOF > > CASE 1: the protocol supports only IdP-specific identifiers and no > portable > identifiers. > > RESULT: IdPs can achieve identifier lockin. Not acceptable. End of > Case 1. Agreed. > > CASE 2: the protocol supports only portable identifiers and no IdP- > specific > identifiers. > > RESULT: IdP is forced to know and store all portable identifiers > for a user, > including identifiers for which the IdP is not authoritative, and > users Why would the IdP need to know identifiers over which it is not authoritative? > would be forced to register all their portable identifiers with > their IdP, > and to update these registrations every time the user adds or > deletes a > portable identifier. Highly undesirable if not impossible. I don't see this as undesirable but as necessary. If I have a portable identifier and I configure it to point to some IdP for authentication it only makes sense for the IdP to know about the identifier as well. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Title: RE: Identifier portability: the fundamental issue We must have different understandings of the term sacred then. My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2006 12:58 PM Pacific Standard Time To: specs@openid.net Subject: Identifier portability: the fundamental issue Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following "postulate": "To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier)." I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote: >>> Drummond wrote: >>> Since the RP has to do discovery on the i-name, the RP already >>> has the >>> i-number (CanonicalID). Further, as explained in previous >>> threads, the >>> CanonicalID is the primary key the RP wants to store for the user, >>> not the >>> i-name, because the i-number is forever while the i-name could >>> change. >>> >>> The RP is also motivated to send the i-number to the IdP for the >>> same reason >>> that the RP is motivated to send the delegate URL (if available): to >>> increase performance by saving the IdP from having to re-resolve >>> the i-name >>> (in the XRI case) or original URL (in the URL case). >> >> Dick wrote: >> >> Won't the IdP will still have to resolve the i-name? The IdP can't >> trust the RP, or know that the i-name and i-number are really linked >> unless it checks itself. > > There are no trust issues involved with the IdP using the > identifiers sent > by the RP. The RP is "relying" on the IdP, not vice versa. If the > RP sends > the wrong identifiers, it's fooling no one but itself. Thus the IdP > has no > reason to re-resolve (and good performance reasons not to). The IdP is issuing a signed assertion about these identifiers, I would assume the IdP to check the link between these identifiers. What if a bad RP sends an auth request with a mismatched set and then re-posts the response to some other RP? I am sure someone will figure a way to exploit this. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Consolidated Delegate Proposal
On 10/13/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > The IdP is issuing a signed assertion about these identifiers, I > would assume the IdP to check the link between these identifiers. Sending two identifiers does not *prevent* the IdP from checking to make sure they match. > What if a bad RP sends an auth request with a mismatched set and then > re-posts the response to some other RP? I am sure someone will figure > a way to exploit this. It is, and must be, the relying party's responsibility to ensure that the information in the response matches what is discovered. This is true regardless when portable identifiers are used and when they are not. It is true for all of the proposed delegation mechanisms. It is really one of the fundamental elements of OpenID. A response from an IdP is meaningless until it is compared with the discovered information for the identifier in question. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
> > Drummond wrote:
>> >
>> > "To achieve identifier portability in OpenID, it MUST be
>> > possible for the RP and the IdP to identify the user using
>> > two different identifiers: an identifier by which the RP
>> > knows the user (the portable identifier), and an identifier
>> > by which the IdP knows the user (the IdP-specific identifier)."
>>
>> Hans wrote:
>>
>> There is no reason why the idp MUST require to know both
>> identifiers for identifier portability to be possible in
>> the system.
>
>Brad wrote:
>
>Existence proof: OpenID 1.1 does identifier portability without two
>identifiers in the spec.
Just to clarify: the "postulate" above did not mean to imply there must be
two different identifiers in the spec/protocol. It was just meant to assert
that the principle of identifier portability (upon which we already have
consensus) requires that it be possible for the RP and IdP to use two
different identifiers.
I was hoping to inch our way towards consensus here by seeing if we had
agreement on this second principle (as some messages have been implying that
IdP-specific identifiers were not needed at all).
>And despite all the "but it can't be stateless without two!" noise, it
>actually can: you put the portable identifier in the return_to URL and
>verify it again when you get the signature back from the IdP. That is,
>verify the mapping from portable -> IdP-specific still holds. Because you
>can't just trust the 1 (or 2) values you get back from the IdP, otherwise
>the IdP (which could be malicious) could be fucking with you, asserting a
>portable identifier which it's not actually permitted to do, according to
>the portable identifer's YADIS//etc.
Good point. I've never figured an attack vector for the RP to send the wrong
identifiers to the IdP, since the RP is just "fooling itself". But I agree
there can be one for a malicious IdP to return the wrong ones to an RP.
>So with 1 or 2, you still need to verify, but that verification doesn't
>have to be painful: you can cache it. "But that's state! omg!" Okay,
>so don't cache it and re-check it. But OpenID's been all about the
>state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Agreed.
>Counter-argument: but OpenID 1.1 does have two parameters: one's just in
>the return_to URL and managed by the client library, arguably in its own
>ugly namespace (not IdP/RP managed, not "openid.", but something else...
>the Perl library uses "oic." or something). So then it's harder to
>document the correct behavior to people ("RPs should verify the mapping
>when you get a signature!") because the parameter names aren't consistent
>between RP clients.
Agreed, and you articulated well the reasons for doing it at the spec level.
>So whether it's in the spec formally or not, I don't really care. But the
>spec MUST contain details on the precautions a RP should take.
Yup.(Got that, editors?)
=Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Authentication 2.0 Draft 10 Posted
With a good deal of work from both Josh and I this past week, we now have Draft 10 (http://openid.net/specs/openid-authentication-2_0-10.html)! While I previously proposed this be the final draft, the delegation proposal is still being actively discussed and it is quite important consensus be reached before I'd be comfortable calling the spec "final". I'll also be posting various questions I have, sometime in the next day or two, after fully re-reading the specification today. --David Changelog: - Rename trust_root to realm - Remove SIGNALL - Rename nonce to response_nonce, though do not add a request nonce - Add http://openid.net/signon/1.1 as an XRD Service type, since it is present in the wild. Indicate that it triggers compatibility mode. - Update August to October - Use "OpenID" and "OpenID Authentication" as appropriate - Reorder terminology section - Make "Identity Provider" the defined term, with IdP as the short-hand - Link to RFC when defining Diffie-Hellman Key Exchange - Fix various typos and cleanup wording - In 3.5, note that EU -> IdP auth is out of scope - Note that in 4.1.2 "openid." is only prefixed on request messages - Combine "Signature Algorithms" and "Procedure" into one uber "Signatures" section, though this still needs to be cleaned up more - Add motivation to OpenID logo in form field - Enumerate XRI Global Context symbols - Note the RP should keep the normalized/redirected URL as the Claimed Identifier - Swap 10.3 and 10.4 due to order introduced - Add additional cross-references - Add "mode" in 13.2.2.2 as a response parameter instead of only listing it as a request parameter - Update 9.3.3 to require support of 1.1 HTML-based discovery to match 14.1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
