Well, I think this just says that the full URI MUST not be reassigned to different (group of) entities, that the verified identifier will be always this non-recycled full identifier.
=nat On Thu, May 14, 2009 at 2:39 AM, Andrew Arnott <[email protected]> wrote: > From the spec: > > 11.5.1. Identifier Recycling > > OpenID Providers with large user bases can use fragments to recycle URL > Identifiers if it is so desired. When reassigning a URL Identifier to a new > end user OPs should generate a new, unique fragment part. > > The full URL with the fragment part constitutes the Claimed Identifier in > positive assertions, therefore Relying Parties will distinguish between the > current and previous owners of the fragment-less URL. > > This mechanism allows the (presumably short, memorable) recycled URL > Identifiers without the fragment to be used by end users at login time and > by Relying Parties for display purposes. > > This smells hugely of the idea that only one user controls an identifier at > a time. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - Voltaire > > > On Wed, May 13, 2009 at 10:27 AM, Nat Sakimura <[email protected]> wrote: >> >> My interpretation is that the fragment does not necessarily mean a new >> user, but it just differentiate among different users. >> >> =nat >> >> On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott <[email protected]> >> wrote: >> > Fragments are valid URI parts. But they are unique in that a web >> > browser >> > never sends them to the server. The OpenID 2.0 spec specifically calls >> > out >> > fragments as valid ways that OPs can indicate to RPs that a new user >> > controls this identifier. >> > >> > So in fact that may be a problem. Multiple users could be asserting >> > control >> > of the identifier (minus the fragment). The OpenID 2.0 spec at least >> > hints >> > that OPs will use this generational #fragment to indicate a new user >> > controls the identifier (identifier recycling). An RP that sees a new >> > fragment attached to a claimed_id may assume (perhaps rightly) that the >> > old >> > user is now gone and delete settings for the old user. If the OP >> > habitually >> > sticks on random goo to the end of an identifier via its #fragment, then >> > that interpretation by the RP would not be safe. >> > >> > I don't know if others read the spec that way though. >> > -- >> > Andrew Arnott >> > "I [may] not agree with what you have to say, but I'll defend to the >> > death >> > your right to say it." - Voltaire >> > >> > >> > On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan <[email protected]> >> > wrote: >> >> >> >> I am not sure about fragments. I dont think the fragment falls under >> >> the >> >> deifinition of URI. see rfc 3986. >> >> The group can be indentified within the path part, assuming all members >> >> of >> >> the group belong to the same OP and the group is known while issuing >> >> the >> >> OpenID. In that case we dont need anything to define at the OpenID >> >> level. >> >> Or am i missing something here? >> >> >> >> Andrew Arnott wrote: >> >> > >> >> > Appending a fragment at least will help the RP distinguish between >> >> > identifiers. And in the short term it has the merit of not requiring >> >> > any >> >> > spec changes. >> >> > >> >> > But I still would like to see a group membership claim kept separate >> >> > from >> >> > the identity claim, perhaps via the claim discovery I described in >> >> > the >> >> > other >> >> > thread. >> >> > -- >> >> > Andrew Arnott >> >> > "I [may] not agree with what you have to say, but I'll defend to the >> >> > death >> >> > your right to say it." - Voltaire >> >> > >> >> > >> >> > On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura <[email protected]> >> >> > wrote: >> >> > >> >> >> My previous post on pseudonymous identifier seemed to have kicked >> >> >> off >> >> >> interesting but orthogonal discussion of identifier for group of >> >> >> individuals (like school class, friends, etc.) >> >> >> >> >> >> Please use this thread instead for this discussion. >> >> >> >> >> >> Just to put an context to the discussion, I can put one deployed >> >> >> example of this type of identifier use. >> >> >> >> >> >> mixi, the largest Japanese SNS, is using the concept of "group >> >> >> identifier." >> >> >> >> >> >> For example, to prove you are a friend of mine, you can authenticate >> >> >> with the identifier >> >> >> >> >> >> https://id.mixi.jp/nat/friend >> >> >> >> >> >> The verified identifier would be something like >> >> >> https://id.mixi.jp/nat/friend#hashOfYourId etc., >> >> >> if I rememer right. >> >> >> >> >> >> As you can see, it requires no change in the OpenID AuthN 2.0 nor an >> >> >> extension. >> >> >> >> >> >> Anyways.. my 2c. >> >> >> >> >> >> =nat >> >> >> >> >> >> -- >> >> >> Nat Sakimura (=nat) >> >> >> http://www.sakimura.org/en/ >> >> >> _______________________________________________ >> >> >> specs mailing list >> >> >> [email protected] >> >> >> http://openid.net/mailman/listinfo/specs >> >> >> >> >> > >> >> > _______________________________________________ >> >> > specs mailing list >> >> > [email protected] >> >> > http://openid.net/mailman/listinfo/specs >> >> > >> >> > >> >> >> >> >> >> ----- >> >> >> >> Santosh Rajan >> >> http://santrajan.blogspot.com http://santrajan.blogspot.com >> >> -- >> >> View this message in context: >> >> >> >> http://www.nabble.com/Identifier-for-group-of-individulas-tp23525446p23526064.html >> >> Sent from the OpenID - Specs mailing list archive at Nabble.com. >> >> >> >> _______________________________________________ >> >> specs mailing list >> >> [email protected] >> >> http://openid.net/mailman/listinfo/specs >> > >> > >> > _______________________________________________ >> > specs mailing list >> > [email protected] >> > http://openid.net/mailman/listinfo/specs >> > >> > >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
