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 <andrewarn...@gmail.com> 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 <santra...@gmail.com> 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 <sakim...@gmail.com> >> > 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 >> >> specs@openid.net >> >> http://openid.net/mailman/listinfo/specs >> >> >> > >> > _______________________________________________ >> > specs mailing list >> > specs@openid.net >> > 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 >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
