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 <sakim...@gmail.com
<mailto:sakim...@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
<andrewarn...@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto:specs@openid.net>
>> >> http://openid.net/mailman/listinfo/specs
>> >>
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs@openid.net <mailto: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 <mailto:specs@openid.net>
>> http://openid.net/mailman/listinfo/specs
>
>
> _______________________________________________
> specs mailing list
> specs@openid.net <mailto: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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
