Identifier for group of individulas
Allen Tom
atom at yahoo-inc.com
Thu May 14 04:10:48 UTC 2009
The intent of the fragment was to allow OPs to recycle OpenIDs, and the
fragment is intended to be a "generation identifier" that RPs can use to
determine that the OpenID was recycled.
Allen
Andrew Arnott wrote:
> From the spec
> <http://openid.net/specs/openid-authentication-2_0.html#identifying>:
>
>
> 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 <sakimura at gmail.com
> <mailto:sakimura at gmail.com>> 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
> <andrewarnott at gmail.com <mailto:andrewarnott at 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
> <santrajan at gmail.com <mailto:santrajan at 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
> <sakimura at gmail.com <mailto:sakimura at 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 at openid.net <mailto:specs at openid.net>
> >> >> http://openid.net/mailman/listinfo/specs
> >> >>
> >> >
> >> > _______________________________________________
> >> > specs mailing list
> >> > specs at openid.net <mailto:specs at 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 at openid.net <mailto:specs at openid.net>
> >> http://openid.net/mailman/listinfo/specs
> >
> >
> > _______________________________________________
> > specs mailing list
> > specs at openid.net <mailto:specs at openid.net>
> > http://openid.net/mailman/listinfo/specs
> >
> >
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090513/60fa7050/attachment.htm>
More information about the specs
mailing list