No subject

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

--000e0cd48872d13e4c0469ceb281
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable