Identifier for group of individulas

Wed May 13 21:32:54 UTC 2009

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 <andrewarnott at gmail.com> 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 <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/
>
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/