Re: Identifier for group of individulas

2009-05-13 Thread Allen Tom 
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 
:



  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 > 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
mailto:[email protected]>> 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
mailto:[email protected]>> 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
mailto:[email protected]>>
>> > 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
>> >>
>> >> --

Re: Identifier for group of individulas

2009-05-13 Thread Nat Sakimura 
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  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  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 
>> 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 
>> > 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 
>> >> > 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
>> >> >> [email protected]
>> >> >> http://openid.net/mailman/listinfo/specs
>> >>

Re: Identifier for group of individulas

2009-05-13 Thread Andrew Arnott 
>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  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 
> 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 
> 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 
> >> > 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
> >> >> [email protected]
> >> >> http://openid.net/mailman/listinfo/specs
> >> >>
> >> >
> >> > ___
> >> > specs mailing list
> >> > [email protected]
> >> > 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-gr

Re: Identifier for group of individulas

2009-05-13 Thread Nat Sakimura 
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  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  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 
>> > 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
>> >> [email protected]
>> >> http://openid.net/mailman/listinfo/specs
>> >>
>> >
>> > ___
>> > specs mailing list
>> > [email protected]
>> > 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
>> [email protected]
>> http://openid.net/mailman/listinfo/specs
>
>
> ___
> specs mailing list
> [email protected]
> http://openid.net/mailman/listinfo/specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs

Re: Identifier for group of individulas

2009-05-13 Thread Andrew Arnott 
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  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 
> 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
> >> [email protected]
> >> http://openid.net/mailman/listinfo/specs
> >>
> >
> > ___
> > specs mailing list
> > [email protected]
> > 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
> [email protected]
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs

Re: Identifier for group of individulas

2009-05-13 Thread Santosh Rajan 

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  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
>> [email protected]
>> http://openid.net/mailman/listinfo/specs
>>
> 
> ___
> specs mailing list
> [email protected]
> 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
[email protected]
http://openid.net/mailman/listinfo/specs

Re: Identifier for group of individulas

2009-05-13 Thread Andrew Arnott 
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  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
> [email protected]
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs