|
»
»
linking an openid to an existing account
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
linking an openid to an existing account
by Shane B Weeden
::
Rate this Message:
I have a question about best-practices. Consider a website with an existing user base. You want to provide the users an alternate means of authentication with an OpenID (e.g. replacing existing password-based authentication), so you show them a page (after they've authenticated) which says "Link an OpenID to your account". The user authenticates with an OpenID, and the site associates <something> with the user's existing account so that in the future OpenID authentication can happen as the primary login and the same <something> can be used to figure out which user account to login as. My question is what is the best thing to use as <something>. There are options, most with certain limitations, and I wanted to see if the community has a general pattern or recommendation. For example, the <something> could be (non-exhaustive): 1. The "as-typed-in-by-the-user" user-supplied identifier. This has limitations that a user can have multiple user-supplied identifiers that normalize to the same id, and they can confuse themselves (e.g. shane.myopenid.com = http://shane.myopenid.com). This doesn't work well with OP identifiers. 2. The claimed identifier after discovery. This doesn't play well with delegation if a user switches OP's but keeps their user-supplied identifier. 3. Some other combination? Your thoughts appreciated. _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: linking an openid to an existing account
by Dan Ragle-2
::
Rate this Message:
Hi,
I think the key to use is the claimed_id returned by the OP as part of a positive assertion (which you have to verify against your own discovered data as part of the authentication); otherwise you run into the potential future-user-inherits-the-account problem: > 1. The "as-typed-in-by-the-user" user-supplied identifier. This has > limitations that a user can have multiple user-supplied identifiers that > normalize to the same id, and they can confuse themselves (e.g. > shane.myopenid.com = http://shane.myopenid.com). This doesn't work well > with OP identifiers. And it also has the problem that a user may abandon an ID at a particular OP, and that another user might take it over at some point in the future and thus gain access to your already associated account through it. Of course, I'm assuming here that the OP uses some type of fragment identifier on the returned claimed_id to historically differentiate the new vs. old ID (i.e., like Yahoo does now). > > 2. The claimed identifier after discovery. This doesn't play well with > delegation if a user switches OP's but keeps their user-supplied > identifier. As I recall, in the case of delegation, the claimed_id after discovery is just the normalized user supplied ID, or the canonical ID if an XRI was supplied (i.e., the ID that is used to verify the user at the OP is the OP-Local ID, not the claimed identifier). So it should still work if the user delegates and switches OPs later, unless I've misunderstood your point. But in the case of non-delegation, this scenario has the same potential problem as above. > > 3. Some other combination? As I understood it, the returned claimed_id from the OP should be the normalized user supplied ID in the case of delegation, or an historically unique form of the user's chosen (in the case of OP IDs) or supplied ID otherwise. Thus, I believe it's the most accurate link. > > Your thoughts appreciated. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: linking an openid to an existing account
by Dan Ragle-2
::
Rate this Message:
P.S. - per section 11.5 of the OpenID specs:
"The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted." Cheers! Dan > I have a question about best-practices. > > Consider a website with an existing user base. You want to provide the > users an alternate means of authentication with an OpenID (e.g. replacing > existing password-based authentication), so you show them a page (after > they've authenticated) which says "Link an OpenID to your account". > > The user authenticates with an OpenID, and the site associates <something> > with the user's existing account so that in the future OpenID > authentication can happen as the primary login and the same <something> > can be used to figure out which user account to login as. > > My question is what is the best thing to use as <something>. There are > options, most with certain limitations, and I wanted to see if the > community has a general pattern or recommendation. > > For example, the <something> could be (non-exhaustive): > > 1. The "as-typed-in-by-the-user" user-supplied identifier. This has > limitations that a user can have multiple user-supplied identifiers that > normalize to the same id, and they can confuse themselves (e.g. > shane.myopenid.com = http://shane.myopenid.com). This doesn't work well > with OP identifiers. > > 2. The claimed identifier after discovery. This doesn't play well with > delegation if a user switches OP's but keeps their user-supplied > identifier. > > 3. Some other combination? > > Your thoughts appreciated. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: linking an openid to an existing account
by Shane B Weeden
::
Rate this Message:
Agree for OpenID 2.0. What about OpenID 1.1 backwards-compatibility, which doesn't have the claimed_id concept?
P.S. - per section 11.5 of the OpenID specs: "The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted." Cheers! Dan > I have a question about best-practices. > > Consider a website with an existing user base. You want to provide the > users an alternate means of authentication with an OpenID (e.g. replacing > existing password-based authentication), so you show them a page (after > they've authenticated) which says "Link an OpenID to your account". > > The user authenticates with an OpenID, and the site associates <something> > with the user's existing account so that in the future OpenID > authentication can happen as the primary login and the same <something> > can be used to figure out which user account to login as. > > My question is what is the best thing to use as <something>. There are > options, most with certain limitations, and I wanted to see if the > community has a general pattern or recommendation. > > For example, the <something> could be (non-exhaustive): > > 1. The "as-typed-in-by-the-user" user-supplied identifier. This has > limitations that a user can have multiple user-supplied identifiers that > normalize to the same id, and they can confuse themselves (e.g. > shane.myopenid.com = http://shane.myopenid.com). This doesn't work well > with OP identifiers. > > 2. The claimed identifier after discovery. This doesn't play well with > delegation if a user switches OP's but keeps their user-supplied > identifier. > > 3. Some other combination? > > Your thoughts appreciated. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: linking an openid to an existing account
by Dan Ragle-2
::
Rate this Message:
In that case, I believe the claimed id after discovery
(which, in the case of 1.1, should be the normalized user supplied ID) is your best choice (that's the one I use). Perhaps not optimal, but if you need 1.1 compatibility that's the best of the options. This blurb from the specs (section 14.2.1) seems to at least indirectly concur: "openid.claimed_id" is not defined by OpenID Authentication 1.1. Relying Parties MAY send the value when making requests, but MUST NOT depend on the value being present in authentication responses. When the OP-Local Identifier ("openid.identity") is different from the Claimed Identifier, the Relying Party MUST keep track of what Claimed Identifier was used to discover the OP-Local Identifier, for example by keeping it in session state. Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user. Hope that's helpful! Dan > Agree for OpenID 2.0. > > What about OpenID 1.1 backwards-compatibility, which doesn't have the > claimed_id concept? > > > > > > > Dan Ragle <dragle@...> > Sent by: general-bounces@... > 19/07/2008 12:01 AM > > To > general@... > cc > > Subject > Re: [OpenID] linking an openid to an existing account > > > > > > > P.S. - per section 11.5 of the OpenID specs: > > "The Claimed Identifier in a successful > authentication response SHOULD be used > by the Relying Party as a key for local > storage of information about the user. > The Claimed Identifier MAY be used as a > user-visible Identifier. When displaying > URL Identifiers, the fragment MAY be > omitted." > > Cheers! > > Dan > >> I have a question about best-practices. >> >> Consider a website with an existing user base. You want to provide the >> users an alternate means of authentication with an OpenID (e.g. > replacing >> existing password-based authentication), so you show them a page (after >> they've authenticated) which says "Link an OpenID to your account". >> >> The user authenticates with an OpenID, and the site associates > <something> >> with the user's existing account so that in the future OpenID >> authentication can happen as the primary login and the same <something> >> can be used to figure out which user account to login as. >> >> My question is what is the best thing to use as <something>. There are >> options, most with certain limitations, and I wanted to see if the >> community has a general pattern or recommendation. >> >> For example, the <something> could be (non-exhaustive): >> >> 1. The "as-typed-in-by-the-user" user-supplied identifier. This has >> limitations that a user can have multiple user-supplied identifiers that > >> normalize to the same id, and they can confuse themselves (e.g. >> shane.myopenid.com = http://shane.myopenid.com). This doesn't work well >> with OP identifiers. >> >> 2. The claimed identifier after discovery. This doesn't play well with >> delegation if a user switches OP's but keeps their user-supplied >> identifier. >> >> 3. Some other combination? >> >> Your thoughts appreciated. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> general mailing list >> general@... >> http://openid.net/mailman/listinfo/general > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general > > general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: linking an openid to an existing account
by Shane B Weeden
::
Rate this Message:
It is useful, and is the same conclusion I arrived at. Thanks, Shane.
In that case, I believe the claimed id after discovery (which, in the case of 1.1, should be the normalized user supplied ID) is your best choice (that's the one I use). Perhaps not optimal, but if you need 1.1 compatibility that's the best of the options. This blurb from the specs (section 14.2.1) seems to at least indirectly concur: "openid.claimed_id" is not defined by OpenID Authentication 1.1. Relying Parties MAY send the value when making requests, but MUST NOT depend on the value being present in authentication responses. When the OP-Local Identifier ("openid.identity") is different from the Claimed Identifier, the Relying Party MUST keep track of what Claimed Identifier was used to discover the OP-Local Identifier, for example by keeping it in session state. Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user. Hope that's helpful! Dan > Agree for OpenID 2.0. > > What about OpenID 1.1 backwards-compatibility, which doesn't have the > claimed_id concept? > > > > > > > Dan Ragle <dragle@...> > Sent by: general-bounces@... > 19/07/2008 12:01 AM > > To > general@... > cc > > Subject > Re: [OpenID] linking an openid to an existing account > > > > > > > P.S. - per section 11.5 of the OpenID specs: > > "The Claimed Identifier in a successful > authentication response SHOULD be used > by the Relying Party as a key for local > storage of information about the user. > The Claimed Identifier MAY be used as a > user-visible Identifier. When displaying > URL Identifiers, the fragment MAY be > omitted." > > Cheers! > > Dan > >> I have a question about best-practices. >> >> Consider a website with an existing user base. You want to provide the >> users an alternate means of authentication with an OpenID (e.g. > replacing >> existing password-based authentication), so you show them a page (after >> they've authenticated) which says "Link an OpenID to your account". >> >> The user authenticates with an OpenID, and the site associates > <something> >> with the user's existing account so that in the future OpenID >> authentication can happen as the primary login and the same <something> >> can be used to figure out which user account to login as. >> >> My question is what is the best thing to use as <something>. There are >> options, most with certain limitations, and I wanted to see if the >> community has a general pattern or recommendation. >> >> For example, the <something> could be (non-exhaustive): >> >> 1. The "as-typed-in-by-the-user" user-supplied identifier. This has >> limitations that a user can have multiple user-supplied identifiers that > >> normalize to the same id, and they can confuse themselves (e.g. >> shane.myopenid.com = http://shane.myopenid.com). This doesn't work well >> with OP identifiers. >> >> 2. The claimed identifier after discovery. This doesn't play well with >> delegation if a user switches OP's but keeps their user-supplied >> identifier. >> >> 3. Some other combination? >> >> Your thoughts appreciated. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> general mailing list >> general@... >> http://openid.net/mailman/listinfo/general > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general > > _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
choosing endpoint after performing discovery on claimed_id from response
by James Tindall
::
Rate this Message:
Suppose a relying party is operating under stateless mode. Suppose also
that the discovery phase for the given claimed_id returned more than one endpoint. Then suppose that association attempts failed on at least one of the endpoints but then succeeded on one of the other endpoints further down the priority order. Then upon receiving the authentication (id_res) response from the chosen OP the RP must perform discovery on the claimed_id contained in the response in order to be able to verify the response data against discovered data. But then if, as is probable, the discovery phase again returns more than one endpoint, how is the RP to choose which one to verify the response data against? =james.tindall _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: choosing endpoint after performing discovery on claimed_id from response
by Greg Byrd
::
Rate this Message:
(1) Section 11.2 says that RP must perform discovery "[i]f the Claimed
Identifier was not previously discovered." So I think you don't need to do that second discovery step in your email. But you said stateless mode, so maybe you don't remember that you discovered the ID in the first place, so... (2) The op_endpoint field is returned in id_res, so the verification should just check whether any of the OPs returned from discovery match the supplied op_endpoint. ...Greg James Tindall wrote: > Suppose a relying party is operating under stateless mode. Suppose also > that the discovery phase for the given claimed_id returned more than one > endpoint. Then suppose that association attempts failed on at least one > of the endpoints but then succeeded on one of the other endpoints > further down the priority order. Then upon receiving the authentication > (id_res) response from the chosen OP the RP must perform discovery on > the claimed_id contained in the response in order to be able to verify > the response data against discovered data. But then if, as is probable, > the discovery phase again returns more than one endpoint, how is the RP > to choose which one to verify the response data against? > > =james.tindall > > > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: choosing endpoint after performing discovery on claimed_id from response
by James Tindall
::
Rate this Message:
Ah, to answer my own (silly?) question - If running in stateless mode
then association would not have been even attempted - so the RP should be fairly confident that the endpoint to choose is the first in the priority list? James Tindall wrote: > Suppose a relying party is operating under stateless mode. Suppose also > that the discovery phase for the given claimed_id returned more than one > endpoint. Then suppose that association attempts failed on at least one > of the endpoints but then succeeded on one of the other endpoints > further down the priority order. Then upon receiving the authentication > (id_res) response from the chosen OP the RP must perform discovery on > the claimed_id contained in the response in order to be able to verify > the response data against discovered data. But then if, as is probable, > the discovery phase again returns more than one endpoint, how is the RP > to choose which one to verify the response data against? > > =james.tindall > > > _______________________________________________ > general mailing list > general@... > http://openid.net/mailman/listinfo/general > > _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: choosing endpoint after performing discovery on claimed_id from response
by James Tindall
::
Rate this Message:
Thanks Greg,
I think you're right - but it's possible that more than one endpoint in the xrds has the same op_endpoint as that supplied in the response - so it would be necessary to also compare other fields to select the best matching endpoint. This is making OpenID kind of a protracted process. =james.tindall Greg Byrd wrote: > (1) Section 11.2 says that RP must perform discovery "[i]f the Claimed > Identifier was not previously discovered." So I think you don't need > to do that second discovery step in your email. But you said > stateless mode, so maybe you don't remember that you discovered the ID > in the first place, so... > > (2) The op_endpoint field is returned in id_res, so the verification > should just check whether any of the OPs returned from discovery match > the supplied op_endpoint. > > ...Greg > > > James Tindall wrote: >> Suppose a relying party is operating under stateless mode. Suppose >> also that the discovery phase for the given claimed_id returned more >> than one endpoint. Then suppose that association attempts failed on >> at least one of the endpoints but then succeeded on one of the other >> endpoints further down the priority order. Then upon receiving the >> authentication (id_res) response from the chosen OP the RP must >> perform discovery on the claimed_id contained in the response in >> order to be able to verify the response data against discovered data. >> But then if, as is probable, the discovery phase again returns more >> than one endpoint, how is the RP to choose which one to verify the >> response data against? >> >> =james.tindall >> >> >> _______________________________________________ >> general mailing list >> general@... >> http://openid.net/mailman/listinfo/general > > > _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
||||||||||
|
|
Re: choosing endpoint after performing discovery on claimed_id from response
by Andrew Arnott
::
Rate this Message:
As James mentioned, Greg, the spec requires that you verify more than just the op_endpoint. In fact 4 fields are listed in the table of section 11.2 that should be equal. And James, I think these four fields should be enough to narrow the endpoints down to just one. And even if it didn't, it might as well be since all the significant data is the same.
On Tue, Jul 22, 2008 at 7:47 AM, James Tindall <james@...> wrote: Thanks Greg, _______________________________________________ general mailing list general@... http://openid.net/mailman/listinfo/general |
| Free Forum Powered by Nabble | Forum Help |