Re: Requiring Pseudonymous Identifier

[John Bradley]

So is it fair to characterize the use case delivering a attribute to a  
RP that the RP can trust because it knows or the issuer can prove it's  
authoritative for the attribute in some way,   while leaking the  
minimal amount of information to 3rd parties.


I don't know that the privacy goal can be met without a client side  
identity selector of some sort.

(this problem is solved in info-card that is why it has a selector)

The best thing would be for the RP to guide the user to select the  
correct endpoint OP endpoint for that assertion and perform a identity  
less openID transaction to get the attribute/claim from the OP.   If  
the user uses the same auth OP for the attribute OP the auth OP learns  
that the user has a relationsip with that attribute provider anyway,  
but at least they don't see the value of the attribute.


If you are going to pass the token through the users Authentication OP  
there are questions of end to end encryption that need to be  
addressed.  The token  issuer would need the cert of the RP etc.


This has been well thought out in SAML and WS-Fed/Infocard.  If there  
is a particular use case that needs solving I am OK with that, but  
lets not reinvent the wheel for a third time just for something to do.


The original design goal of openID was to provide correlation and  
disclosure for blogging.   Trying to retool it into something with  
perfect privacy will take work.


This is a hybrid service where a RP can ask for a claim from a 3rd  
party and have it encrypted end to end.   It uses information-cards  
hosted at the OP.

https://higgins.eclipse.org/cloud-selector-test/
ttp://wiki.eclipse.org/Cloud_Selector

Have a look at this and let me know if it solves part of the use case.

Once a User is logged in an identity less openenID request could be  
make and the user has the ability to direct via the card metaphor what  
issuer will generate the token.


John Bradley

On 16-May-09, at 10:42 PM, Andrew Arnott wrote:


Sounds like a great idea to mock up for a demo.

On Saturday, May 16, 2009, John Bradley  wrote:
There is nothing that would stop an RP from performing discovery on  
some group URI to discover a OP Endpoint.


Once the RP has the endpoint they can do an identity-less request  
to the OP for the session that is currently logged in.


The OP returns what is the openID equivalent of a bearer token in  
that it is about whoever presents it as it lacks a "Subject"/ 
claimed_id.


This would require some work to get right but is far better than  
overloading the identifier.


John Bradley


On 15-May-09, at 3:55 PM, SitG Admin wrote:


Keeping it identity-less also allows the assertion to come from a  
3rd party.


The group may be the only one that can say I belong to it.  They  
may have the openID's of there members and make membership  
assertions on there behalf without being a full IDP.  That could be  
done with AX or oAuth for transferring the attributes.



How about a restricted-access "group" (community, whatever an OP  
calls it) where members must have been approved? If the school  
doesn't want to run its own IDP, it can host an XRD file showing  
the URI's for Groups (Communities) on various 3rd-party sites that  
it has investigated and found to be run by those who will be  
responsible (cue internal policy decisions, here), so it declares  
them (groups, not sites) authoritative.


From then on, if RP's want to know that a user is a student at that  
school, they check the school's XRD file, then say "Okay, you can  
prove membership in this group on Facebook, that group on  
LiveJournal, or some other group at MySpace."


This kind of "delegation" brings us back to using those URI's,  
though. Then again . . . if the user's OP *is* that same site they  
are a member of some Group on, couldn't something be done there?  
(If the user is employing delegation as known to the spec, it seems  
unlikely that the Group page would be available for that user to  
control the OpenID headers of.)


-Shade





--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre




smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[SitG Admin]

Once the RP has the endpoint they can do an identity-less request to 
the OP for the session that is currently logged in.


The OP returns what is the openID equivalent of a bearer token in 
that it is about whoever presents it as it lacks a 
"Subject"/claimed_id.


OP chaining? Assuming the user is known to the first OP, and that the 
user is allright with this first OP knowing what other OP the user 
wants to vouch for their identity, I'd wonder whether the first OP 
would feel entitled to make its own decisions about who the user 
should be allowed to trust. Such matters should not be addressed in 
the spec, but I wonder if the school's XRD file (the same one that 
said "members of this group URI can be treated as Us") could also 
include a whitelist of OP's the school trusted to vouch for their 
students' identity. Wouldn't stop OP's determined to do so from not 
passing on user's choice of OP, but might provide an alternative to 
the first OP having to be entirely in charge of that.


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

Sounds like a great idea to mock up for a demo.

On Saturday, May 16, 2009, John Bradley  wrote:
> There is nothing that would stop an RP from performing discovery on some 
> group URI to discover a OP Endpoint.
>
> Once the RP has the endpoint they can do an identity-less request to the OP 
> for the session that is currently logged in.
>
> The OP returns what is the openID equivalent of a bearer token in that it is 
> about whoever presents it as it lacks a "Subject"/claimed_id.
>
> This would require some work to get right but is far better than overloading 
> the identifier.
>
> John Bradley
>
>
> On 15-May-09, at 3:55 PM, SitG Admin wrote:
>
>
> Keeping it identity-less also allows the assertion to come from a 3rd party.
>
> The group may be the only one that can say I belong to it.  They may have the 
> openID's of there members and make membership assertions on there behalf 
> without being a full IDP.  That could be done with AX or oAuth for 
> transferring the attributes.
>
>
> How about a restricted-access "group" (community, whatever an OP calls it) 
> where members must have been approved? If the school doesn't want to run its 
> own IDP, it can host an XRD file showing the URI's for Groups (Communities) 
> on various 3rd-party sites that it has investigated and found to be run by 
> those who will be responsible (cue internal policy decisions, here), so it 
> declares them (groups, not sites) authoritative.
>
> From then on, if RP's want to know that a user is a student at that school, 
> they check the school's XRD file, then say "Okay, you can prove membership in 
> this group on Facebook, that group on LiveJournal, or some other group at 
> MySpace."
>
> This kind of "delegation" brings us back to using those URI's, though. Then 
> again . . . if the user's OP *is* that same site they are a member of some 
> Group on, couldn't something be done there? (If the user is employing 
> delegation as known to the spec, it seems unlikely that the Group page would 
> be available for that user to control the OpenID headers of.)
>
> -Shade
>
>
>

-- 
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[John Bradley]

There is nothing that would stop an RP from performing discovery on  
some group URI to discover a OP Endpoint.


Once the RP has the endpoint they can do an identity-less request to  
the OP for the session that is currently logged in.


The OP returns what is the openID equivalent of a bearer token in that  
it is about whoever presents it as it lacks a "Subject"/claimed_id.


This would require some work to get right but is far better than  
overloading the identifier.


John Bradley


On 15-May-09, at 3:55 PM, SitG Admin wrote:

Keeping it identity-less also allows the assertion to come from a  
3rd party.


The group may be the only one that can say I belong to it.  They  
may have the openID's of there members and make membership  
assertions on there behalf without being a full IDP.  That could be  
done with AX or oAuth for transferring the attributes.


How about a restricted-access "group" (community, whatever an OP  
calls it) where members must have been approved? If the school  
doesn't want to run its own IDP, it can host an XRD file showing the  
URI's for Groups (Communities) on various 3rd-party sites that it  
has investigated and found to be run by those who will be  
responsible (cue internal policy decisions, here), so it declares  
them (groups, not sites) authoritative.


From then on, if RP's want to know that a user is a student at that  
school, they check the school's XRD file, then say "Okay, you can  
prove membership in this group on Facebook, that group on  
LiveJournal, or some other group at MySpace."


This kind of "delegation" brings us back to using those URI's,  
though. Then again . . . if the user's OP *is* that same site they  
are a member of some Group on, couldn't something be done there? (If  
the user is employing delegation as known to the spec, it seems  
unlikely that the Group page would be available for that user to  
control the OpenID headers of.)


-Shade




smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[SitG Admin]

Keeping it identity-less also allows the assertion to come from a 3rd party.

The group may be the only one that can say I belong to it.  They may 
have the openID's of there members and make membership assertions on 
there behalf without being a full IDP.  That could be done with AX 
or oAuth for transferring the attributes.


How about a restricted-access "group" (community, whatever an OP 
calls it) where members must have been approved? If the school 
doesn't want to run its own IDP, it can host an XRD file showing the 
URI's for Groups (Communities) on various 3rd-party sites that it has 
investigated and found to be run by those who will be responsible 
(cue internal policy decisions, here), so it declares them (groups, 
not sites) authoritative.


From then on, if RP's want to know that a user is a student at that 
school, they check the school's XRD file, then say "Okay, you can 
prove membership in this group on Facebook, that group on 
LiveJournal, or some other group at MySpace."


This kind of "delegation" brings us back to using those URI's, 
though. Then again . . . if the user's OP *is* that same site they 
are a member of some Group on, couldn't something be done there? (If 
the user is employing delegation as known to the spec, it seems 
unlikely that the Group page would be available for that user to 
control the OpenID headers of.)


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[John Bradley]

+1

Exactly group membership is an attribute and you may need to assert  
multiple ones at the same time.


I believe the SAML solution to the this is to use a sort of ephemeral  
for the subject of the assertion.


For openID the equivalent is not using a identifier at all.   The same  
effect can also be acived with managed  info-cards.


I think overloading the identifier with group meaning is a bad  
direction.


You could do it now,  by allowing multiple people to assert the same  
openID but that would cause all sorts of problems for RP's not  
understanding the difference.


Keeping it identity-less also allows the assertion to come from a 3rd  
party.


The group may be the only one that can say I belong to it.  They may  
have the openID's of there members and make membership assertions on  
there behalf without being a full IDP.  That could be done with AX or  
oAuth for transferring the attributes.


John Bradley
On 14-May-09, at 12:17 AM, Andrew Arnott wrote:

If an RP only needs group membership and no individual identity,  
then why assert an identifier at all?  Use OAuth or identity-less  
OpenID.  I think it would seriously cloud OpenID's Identifiers if an  
AX attribute that may or may not be noticed or included  
significantly changes what the identifier's significant meaning is.


--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the  
death your right to say it." - S. G. Tallentyre



On Wed, May 13, 2009 at 8:36 PM, SitG Admin > wrote:

Attributes like group membership belong in AX, not in the identifier.

I suspect the idea is to have a pseudonymous identifier that  
discloses nothing about the person using it other than the fact that  
they can assert the same ID each time they return to prevent  
correlation.


To further prevent correlation, the OP may wish to support users in  
authenticating as members of a group - *in such a way* that  
individual users cannot be distinguished from one another. If not  
for that, RP's could correlate information over time, establishing  
theoretical profiles of the users.


I think one compromise could be to use a traditional identifier, and  
then use AX to signal to the RP that the OP might vouch for more  
than one individual having that URI.


-Shade

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs





smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Paul Madsen]

I dont think this fits either PAPE or AX.

I cant see how the privacy characteristics of an identifier are part of 
'authentication policy'. How the user authenticates to the OP is 
(mostly) orthogonal to the nature of the identifier the OP asserts.


Nor does it fit the AX description of attribute as "a unit of personal 
identity information".


regards

paul

Andrew Arnott wrote:
This scenario doesn't fit what I've always felt AX was for.  I don't 
expect a fetch request to change anything about the underlying openid 
transport other than prompting the user for information disclosure at 
the OP. 

PAPE fits better in my mind.  But again, if PAPE is the only way to 
get a psuedo-anonymous identifier, then unsolicited assertions can't 
get it right.  But if we allow PAPE requests to ask for one, and for 
it to also be discoverable via the RP return_to service in its XRDS, 
then both unsolicited assertion and RP-behind-firewall scenarios work.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Wed, May 13, 2009 at 4:58 PM, David Recordon > wrote:


Does it make more sense to use a PAPE policy requesting a
pseudonymous identifier or an AX attribute requesting one?  Any of
these approaches would work, I just don't think we've mapped out
the pros/cons of each.

--David


On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous
identifiers are generated. That should be up to the OP. But I
like the idea of using a fixed URI as the claimed_id value to
specify the behavior desired by the RP. If, however, we need
to grow this to cover anonymous based identifiers (i.e. the
claims based models from earlier in this thread) then it might
make sense to look at a PAPE extension that covers the type of
identifier requested.

Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy
for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere
but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the
manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
mailto:dick.ha...@gmail.com>> wrote:

On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

Reason for using RP's Subject in XRD instead of
simply using realm is
to allow for something like group identifier.

would you elaborate on the group identifier concept?


This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be
possible to utilize AX
so that it will only be a profile that does not
require a WG.

So shall we start discussing which direction we
want to go forward?

sure!






___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

Absolutely.  Now if we could only find an OP that actually supports it. (per
my thread on the general list) :)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Wed, May 13, 2009 at 9:24 PM, SitG Admin  wrote:

>  If an RP only needs group membership and no individual identity, then why
>> assert an identifier at all?  Use OAuth or identity-less OpenID.  I think it
>> would seriously cloud OpenID's Identifiers if an AX attribute that may or
>> may not be noticed or included significantly changes what the identifier's
>> significant meaning is.
>>
>
> Good point. Is it possible to do identity-less OpenID without first
> establishing an identity, though?
>
> -Shade
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[SitG Admin]

If an RP only needs group membership and no individual identity, 
then why assert an identifier at all?  Use OAuth or identity-less 
OpenID.  I think it would seriously cloud OpenID's Identifiers if an 
AX attribute that may or may not be noticed or included 
significantly changes what the identifier's significant meaning is.


Good point. Is it possible to do identity-less OpenID without first 
establishing an identity, though?


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Allen Tom]

I don't think it makes sense to use an AX attribute for the pseudonymous 
identifier, since assertion will still contain the correlatable OpenID 
identifier. It seems that the OP should return a unique RP-specific 
OpenID in the response.


Breno's idea about using an identifier-less request is interesting, but 
the RP is asking to sign the user in, so the request is about an identifier.


Allen

David Recordon wrote:
Does it make more sense to use a PAPE policy requesting a pseudonymous 
identifier or an AX attribute requesting one?  Any of these approaches 
would work, I just don't think we've mapped out the pros/cons of each.


--David

On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous identifiers are 
generated. That should be up to the OP. But I like the idea of using 
a fixed URI as the claimed_id value to specify the behavior desired 
by the RP. If, however, we need to grow this to cover anonymous based 
identifiers (i.e. the claims based models from earlier in this 
thread) then it might make sense to look at a PAPE extension that 
covers the type of identifier requested.


Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their 
SmartCard.

Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  
wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using realm is
to allow for something like group identifier.


would you elaborate on the group identifier concept?



This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


sure!








___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

If an RP only needs group membership and no individual identity, then why
assert an identifier at all?  Use OAuth or identity-less OpenID.  I think it
would seriously cloud OpenID's Identifiers if an AX attribute that may or
may not be noticed or included significantly changes what the identifier's
significant meaning is.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Wed, May 13, 2009 at 8:36 PM, SitG Admin  wrote:

>  Attributes like group membership belong in AX, not in the identifier.
>>
>> I suspect the idea is to have a pseudonymous identifier that discloses
>> nothing about the person using it other than the fact that they can assert
>> the same ID each time they return to prevent correlation.
>>
>
> To further prevent correlation, the OP may wish to support users in
> authenticating as members of a group - *in such a way* that individual users
> cannot be distinguished from one another. If not for that, RP's could
> correlate information over time, establishing theoretical profiles of the
> users.
>
> I think one compromise could be to use a traditional identifier, and then
> use AX to signal to the RP that the OP might vouch for more than one
> individual having that URI.
>
> -Shade
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[SitG Admin]

Attributes like group membership belong in AX, not in the identifier.

I suspect the idea is to have a pseudonymous identifier that 
discloses nothing about the person using it other than the fact that 
they can assert the same ID each time they return to prevent 
correlation.


To further prevent correlation, the OP may wish to support users in 
authenticating as members of a group - *in such a way* that 
individual users cannot be distinguished from one another. If not for 
that, RP's could correlate information over time, establishing 
theoretical profiles of the users.


I think one compromise could be to use a traditional identifier, and 
then use AX to signal to the RP that the OP might vouch for more than 
one individual having that URI.


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[John Bradley]

Sorry I am playing catchup on this thread.

There may be use cases where you want to rotate the users PPID URI.
That is only practical if you have a per user salt.

Are you talking about letting groups of RP's in a close federation  
generate the same PPID?


We solved this two ways in info-card:
1 For RP's with Class 2 certificates the "Client Pseudonym" is based  
on a subset of the fields in the DN.
	Or, Locality, State/Prov, and Country.   This allows the CN for SSL  
to differ but generate the same PPID for sites within the same  
organization.
2. We have something called a RP/STS that allows multiple RPs that  
have a trust relationship say inside a company to proxy trust through  
a common authentication point.


2 would be difficult for openID but 1 is certainly worth considering.

If the RP has a cert the CN or other fields could be used to calculate  
the "Client Psyudonim" rather than the realm.


John Bradley

On 13-May-09, at 12:07 PM, specs-requ...@openid.net wrote:


Date: Wed, 13 May 2009 16:00:25 +0900
From: Nat Sakimura 
Subject: Re: Requiring Pseudonymous Identifier
To: Dick Hardt 
Cc: OpenID Specs Mailing List 
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their  
SmartCard.

Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat




smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[John Bradley]

I think encoding attributes into identifiers has proved to be a bad  
idea in the past.


Attributes like group membership belong in AX, not in the identifier.

I suspect the idea is to have a pseudonymous identifier that discloses  
nothing about the person using it other than the fact that they can  
assert the same ID each time they return to prevent correlation.


This was one of Kim Camerons laws of identity regarding minimal  
disclosure.


Info-card takes this approach with personal cards using a PPID +  
public key that allows a totally pseudonymous identity  to be asserted.


I think Google is on the right track using AX to assert identity  
information like email but keeping the openID itself non- 
correlatable.  It also leaves open a path for users moving between  
OP's if the important part of the assertion is not the URL itself.


I think users should have the option to use both correlatable and non- 
correlatable identities as appropriate,  and wish more OPs supported it.


John Bradley
On 13-May-09, at 12:07 PM, specs-requ...@openid.net wrote:


Date: Tue, 12 May 2009 23:13:01 -0700
From: Luke Shepard 
Subject: Re: Requiring Pseudonymous Identifier
To: Martin Atkins , OpenID Specs Mailing List

Message-ID: 
Content-Type: multipart/alternative;
boundary="_000_C62FB2FDBCEBlshepardfacebookcom_"

--_000_C62FB2FDBCEBlshepardfacebookcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Agreed. If all you want is a group, then I'd think that the response  
would =

just not include an identifier.

You could use an extension, perhaps AX, to request information about  
the gr=

oup a user belongs to.

For example, if you wanted to understand company membership, you  
could requ=

est and return only http://axschema.org/company/name.

On 5/12/09 11:08 PM, "Martin Atkins"  wrote:

Chris Messina wrote:


So, imagine I use directed identity in a school application... when  
I sig=

n
in to the OP, it will return something like schoolname.edu/student  
as the

identifier.



Overloading our existing concept of an identifier to support  
identifying

a group worries me. Most consumers expect an identifier to be for a
person and are designed around this principle.

I think if groups are useful their design should be different such  
that

consumers are able to distinguish between a user and a group.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs





smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Dirk Balfanz]

2009/5/13 RL 'Bob' Morgan :
>
> On Tue, 12 May 2009, Luke Shepard wrote:
>
>> Agreed. If all you want is a group, then I’d think that the response
>> would just not include an identifier.
>>
>> You could use an extension, perhaps AX, to request information about the
>> group a user belongs to.
>>
>> For example, if you wanted to understand company membership, you could
>> request and return only http://axschema.org/company/name.

How do you validate such a response? You need to make sure that the
party making the assertion is authorized to do so. That's what OpenID
discovery is for, and that requires an identifier.

> FWIW, this is consistent with years of practice in many technical domains,
> including Kerberos and SAML.

There, you don't have that problem. In those cases there is only one
party that is allowed to make such assertions.

Dirk.

>
>  - RL "Bob"
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Breno de Medeiros]

AX could fit the bill if you used an identifier-less request and
request a pseudonym attribute instead. (Interesting collision with a
different thread on OpenID without identifiers).

You would still have to provide support for discovery for unsolicited
assertions, and maybe PAPE policies have an advantage here.

On Wed, May 13, 2009 at 5:26 PM, Andrew Arnott  wrote:
> This scenario doesn't fit what I've always felt AX was for.  I don't expect
> a fetch request to change anything about the underlying openid transport
> other than prompting the user for information disclosure at the OP.
>
> PAPE fits better in my mind.  But again, if PAPE is the only way to get a
> psuedo-anonymous identifier, then unsolicited assertions can't get it
> right.  But if we allow PAPE requests to ask for one, and for it to also be
> discoverable via the RP return_to service in its XRDS, then both unsolicited
> assertion and RP-behind-firewall scenarios work.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Wed, May 13, 2009 at 4:58 PM, David Recordon  wrote:
>>
>> Does it make more sense to use a PAPE policy requesting a pseudonymous
>> identifier or an AX attribute requesting one?  Any of these approaches would
>> work, I just don't think we've mapped out the pros/cons of each.
>>
>> --David
>>
>> On May 13, 2009, at 8:44 AM, George Fletcher wrote:
>>
>>> I don't think OpenID should specify how pseudonymous identifiers are
>>> generated. That should be up to the OP. But I like the idea of using a fixed
>>> URI as the claimed_id value to specify the behavior desired by the RP. If,
>>> however, we need to grow this to cover anonymous based identifiers (i.e. the
>>> claims based models from earlier in this thread) then it might make sense to
>>> look at a PAPE extension that covers the type of identifier requested.
>>>
>>> Thanks,
>>> George
>>>
>>> Nat Sakimura wrote:

 Sorry for a slow response. This week is especially busy for me...

 I borrowed the notion from Austrian Citizen ID system.
 In there, the services are divided into "sectors."
 A sector may span several agencies.
 They call ID as PIN (Personal Identification Number).

 There is a secret PIN (sPIN) which is not used anywhere but in their
 SmartCard.
 Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

 SHA1(sPIN + SectorID)

 (Note, there is a bit more details but...)

 I have thrown OP secret into it.
 To avoid the analytic attack, I agree that it is better to use
 individual secret, as some of you
 points out.

 Regards,

 =nat

 On Tue, May 12, 2009 at 5:55 PM, Dick Hardt 
 wrote:

> On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>
>> Reason for using RP's Subject in XRD instead of simply using realm is
>> to allow for something like group identifier.
>>
> would you elaborate on the group identifier concept?
>
>
>> This is just one idea. Downside of this approach
>> is that we need to set up a WG.
>>
>> I am sure there are more ideas. It might be possible to utilize AX
>> so that it will only be a profile that does not require a WG.
>>
>> So shall we start discussing which direction we want to go forward?
>>
> sure!
>
>




>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

This scenario doesn't fit what I've always felt AX was for.  I don't expect
a fetch request to change anything about the underlying openid transport
other than prompting the user for information disclosure at the OP.

PAPE fits better in my mind.  But again, if PAPE is the only way to get a
psuedo-anonymous identifier, then unsolicited assertions can't get it
right.  But if we allow PAPE requests to ask for one, and for it to also be
discoverable via the RP return_to service in its XRDS, then both unsolicited
assertion and RP-behind-firewall scenarios work.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Wed, May 13, 2009 at 4:58 PM, David Recordon  wrote:

> Does it make more sense to use a PAPE policy requesting a pseudonymous
> identifier or an AX attribute requesting one?  Any of these approaches would
> work, I just don't think we've mapped out the pros/cons of each.
>
> --David
>
>
> On May 13, 2009, at 8:44 AM, George Fletcher wrote:
>
>  I don't think OpenID should specify how pseudonymous identifiers are
>> generated. That should be up to the OP. But I like the idea of using a fixed
>> URI as the claimed_id value to specify the behavior desired by the RP. If,
>> however, we need to grow this to cover anonymous based identifiers (i.e. the
>> claims based models from earlier in this thread) then it might make sense to
>> look at a PAPE extension that covers the type of identifier requested.
>>
>> Thanks,
>> George
>>
>> Nat Sakimura wrote:
>>
>>> Sorry for a slow response. This week is especially busy for me...
>>>
>>> I borrowed the notion from Austrian Citizen ID system.
>>> In there, the services are divided into "sectors."
>>> A sector may span several agencies.
>>> They call ID as PIN (Personal Identification Number).
>>>
>>> There is a secret PIN (sPIN) which is not used anywhere but in their
>>> SmartCard.
>>> Then, sector sepcific PIN (ssPIN) is calculated in the manner of :
>>>
>>> SHA1(sPIN + SectorID)
>>>
>>> (Note, there is a bit more details but...)
>>>
>>> I have thrown OP secret into it.
>>> To avoid the analytic attack, I agree that it is better to use
>>> individual secret, as some of you
>>> points out.
>>>
>>> Regards,
>>>
>>> =nat
>>>
>>> On Tue, May 12, 2009 at 5:55 PM, Dick Hardt 
>>> wrote:
>>>
>>>  On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

  Reason for using RP's Subject in XRD instead of simply using realm is
> to allow for something like group identifier.
>
>  would you elaborate on the group identifier concept?


  This is just one idea. Downside of this approach
> is that we need to set up a WG.
>
> I am sure there are more ideas. It might be possible to utilize AX
> so that it will only be a profile that does not require a WG.
>
> So shall we start discussing which direction we want to go forward?
>
>  sure!



>>>
>>>
>>>
>>>  ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[David Recordon]

Does it make more sense to use a PAPE policy requesting a pseudonymous  
identifier or an AX attribute requesting one?  Any of these approaches  
would work, I just don't think we've mapped out the pros/cons of each.


--David

On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous identifiers are  
generated. That should be up to the OP. But I like the idea of using  
a fixed URI as the claimed_id value to specify the behavior desired  
by the RP. If, however, we need to grow this to cover anonymous  
based identifiers (i.e. the claims based models from earlier in this  
thread) then it might make sense to look at a PAPE extension that  
covers the type of identifier requested.


Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in  
their SmartCard.

Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt   
wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

Reason for using RP's Subject in XRD instead of simply using  
realm is

to allow for something like group identifier.


would you elaborate on the group identifier concept?



This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


sure!








___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[David Recordon]

Agreed.  RP requests a pseudonymous identifier and it's up to the OP  
to figure out how to make one and ideally communicate back to the RP  
that it did so.


--David

On May 13, 2009, at 9:41 AM, Andrew Arnott wrote:

Agreed.  There is no reason for OpenID to mandate how pseudononymous  
identifiers are created.  That should be left up to the OP.


--
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:28 AM, George Fletcher   
wrote:
I'm perfectly fine with using RP discovery as a mechanism for the RP  
to specify what "policy" it requires. I believe that unsolicited  
assertions are going to become more common, so we need to support it.


What I don't want OpenID to do is specify the actual syntax of the  
pseudonymous identifier. I agree that the RP has to trust the OP (in  
some sense) or make it's own determination that the OP is not  
honoring the RP's wishes and then take some action.


For RP's behind firewalls, it would be nice to allow them some  
mechanism other than RP discovery to assert their requirements, but  
that should preclude the discover option.


Thanks,
George

Andrew Arnott wrote:
leaves out the scenario of unsolicited assertions.A new directed  
identity value that the RP passes to the OP to indicate it wants a  
psuedononymous identifier.  Consider this:


An OP needs to perform RP discovery (already), and probably does so  
before sending an unsolicited assertion in order to find out what  
the assertion receiving URI would be for a given realm.  DNOA does  
this already.  If that RP's XRDS document included a TypeURI element  
that had a special psuedononymous-identifier-only-please value the  
OP could pick up on this, and send the unsolicited assertion using  
the appropriate type of claimed_id.


Likewise, when an RP sends an ordinary directed identity request to  
an OP, the OP would again notice the RP's XRDS during RP discovery  
and see what kind of identifier the RP wants and assert accordingly.


Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP  
discovery at all.  Perhaps to help the RP detect whether the OP  
respected its wishes would be to send a PAPE extension or some other  
openid.* parameter to say "yes, this is a pseudo- identifier."  RPs  
have no way to analytically be certain that some identifier is  
psuedononymous anyway, so ultimately the RP has to trust the OP  
(whether implicitly or through a white list is up to the RP).


--
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 8:44 AM, George Fletcher mailto:gffle...@aol.com 
>> wrote:


   I don't think OpenID should specify how pseudonymous identifiers
   are generated. That should be up to the OP. But I like the idea of
   using a fixed URI as the claimed_id value to specify the behavior
   desired by the RP. If, however, we need to grow this to cover
   anonymous based identifiers (i.e. the claims based models from
   earlier in this thread) then it might make sense to look at a PAPE
   extension that covers the type of identifier requested.

   Thanks,
   George


   Nat Sakimura wrote:

   Sorry for a slow response. This week is especially busy for  
me...


   I borrowed the notion from Austrian Citizen ID system.
   In there, the services are divided into "sectors."
   A sector may span several agencies.
   They call ID as PIN (Personal Identification Number).

   There is a secret PIN (sPIN) which is not used anywhere but in
   their SmartCard.
   Then, sector sepcific PIN (ssPIN) is calculated in the manner  
of :


   SHA1(sPIN + SectorID)

   (Note, there is a bit more details but...)

   I have thrown OP secret into it.
   To avoid the analytic attack, I agree that it is better to use
   individual secret, as some of you
   points out.

   Regards,

   =nat

   On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
   mailto:dick.ha...@gmail.com>> wrote:

   On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

   Reason for using RP's Subject in XRD instead of simply
   using realm is
   to allow for something like group identifier.

   would you elaborate on the group identifier concept?


   This is just one idea. Downside of this approach
   is that we need to set up a WG.

   I am sure there are more ideas. It might be possible
   to utilize AX
   so that it will only be a profile that does not
   require a WG.

   So shall we start discussing which direction we want
   to go forward?

   sure!






   ___
   specs mailing list
   specs@openid.net 

   http://openid.net/mailman/listinfo/spe

Re: Requiring Pseudonymous Identifier

[RL 'Bob' Morgan]

On Tue, 12 May 2009, Luke Shepard wrote:


Agreed. If all you want is a group, then I’d think that the response
would just not include an identifier.

You could use an extension, perhaps AX, to request information about the
group a user belongs to.

For example, if you wanted to understand company membership, you could
request and return only http://axschema.org/company/name.


FWIW, this is consistent with years of practice in many technical domains, 
including Kerberos and SAML.


 - RL "Bob"
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

Yes, I think an RP may want different identifier types for different use
cases.  But the RP discovery XRDS can handle that just fine by having two
different return_to URIs in the XRDS, one that accepts each type of
identifier.  Each return_to URI, after validating the assertion, would
forward the user on to whatever use case consumes that kind of login.
--
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:41 AM, Nat Sakimura  wrote:

> I think RP discovery is needed anyways.
>
> For deciding whether RP wants psudonym for this transaction or not,
> I am not sure if RP discovery alone is enough, though.
> RP might want non-psudonym for a particular type of transaction.
> So, yes, RP's XRD would be able to specify the default behaviour,
> but it would also be useful to be able to override it per transaction.
>
> As a matter of fact, I do not strongly feel that we should bake the
> psudonym generation
> algorithm into the spec. However, thinking concretely would clarify the
> requirement to other portions, like what has to be written in the XRD, etc.
> so I think it is useful.
>
> To indicate the quality of the identifier and the assertion, we should
> utilize PAPE.
>
> =nat
>
> On Thu, May 14, 2009 at 1:28 AM, George Fletcher  wrote:
> > I'm perfectly fine with using RP discovery as a mechanism for the RP to
> > specify what "policy" it requires. I believe that unsolicited assertions
> are
> > going to become more common, so we need to support it.
> >
> > What I don't want OpenID to do is specify the actual syntax of the
> > pseudonymous identifier. I agree that the RP has to trust the OP (in some
> > sense) or make it's own determination that the OP is not honoring the
> RP's
> > wishes and then take some action.
> >
> > For RP's behind firewalls, it would be nice to allow them some mechanism
> > other than RP discovery to assert their requirements, but that should
> > preclude the discover option.
> >
> > Thanks,
> > George
> >
> > Andrew Arnott wrote:
> >>
> >> leaves out the scenario of unsolicited assertions.A new directed
> identity
> >> value that the RP passes to the OP to indicate it wants a psuedononymous
> >> identifier.  Consider this:
> >>
> >> An OP needs to perform RP discovery (already), and probably does so
> before
> >> sending an unsolicited assertion in order to find out what the assertion
> >> receiving URI would be for a given realm.  DNOA does this already.  If
> that
> >> RP's XRDS document included a TypeURI element that had a special
> >> psuedononymous-identifier-only-please value the OP could pick up on
> this,
> >> and send the unsolicited assertion using the appropriate type of
> claimed_id.
> >>
> >> Likewise, when an RP sends an ordinary directed identity request to an
> OP,
> >> the OP would again notice the RP's XRDS during RP discovery and see what
> >> kind of identifier the RP wants and assert accordingly.
> >>
> >> Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP
> >> discovery at all.  Perhaps to help the RP detect whether the OP
> respected
> >> its wishes would be to send a PAPE extension or some other openid.*
> >> parameter to say "yes, this is a pseudo- identifier."  RPs have no way
> to
> >> analytically be certain that some identifier is psuedononymous anyway,
> so
> >> ultimately the RP has to trust the OP (whether implicitly or through a
> white
> >> list is up to the RP).
> >>
> >> --
> >> 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 8:44 AM, George Fletcher  >> > wrote:
> >>
> >>I don't think OpenID should specify how pseudonymous identifiers
> >>are generated. That should be up to the OP. But I like the idea of
> >>using a fixed URI as the claimed_id value to specify the behavior
> >>desired by the RP. If, however, we need to grow this to cover
> >>anonymous based identifiers (i.e. the claims based models from
> >>earlier in this thread) then it might make sense to look at a PAPE
> >>extension that covers the type of identifier requested.
> >>
> >>Thanks,
> >>George
> >>
> >>
> >>Nat Sakimura wrote:
> >>
> >>Sorry for a slow response. This week is especially busy for me...
> >>
> >>I borrowed the notion from Austrian Citizen ID system.
> >>In there, the services are divided into "sectors."
> >>A sector may span several agencies.
> >>They call ID as PIN (Personal Identification Number).
> >>
> >>There is a secret PIN (sPIN) which is not used anywhere but in
> >>their SmartCard.
> >>Then, sector sepcific PIN (ssPIN) is calculated in the manner of
> :
> >>
> >>SHA1(sPIN + SectorID)
> >>
> >>(Note, there is a bit more details but...)
> >>
> >>I have thrown OP secret in

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

I think RP discovery is needed anyways.

For deciding whether RP wants psudonym for this transaction or not,
I am not sure if RP discovery alone is enough, though.
RP might want non-psudonym for a particular type of transaction.
So, yes, RP's XRD would be able to specify the default behaviour,
but it would also be useful to be able to override it per transaction.

As a matter of fact, I do not strongly feel that we should bake the
psudonym generation
algorithm into the spec. However, thinking concretely would clarify the
requirement to other portions, like what has to be written in the XRD, etc.
so I think it is useful.

To indicate the quality of the identifier and the assertion, we should
utilize PAPE.

=nat

On Thu, May 14, 2009 at 1:28 AM, George Fletcher  wrote:
> I'm perfectly fine with using RP discovery as a mechanism for the RP to
> specify what "policy" it requires. I believe that unsolicited assertions are
> going to become more common, so we need to support it.
>
> What I don't want OpenID to do is specify the actual syntax of the
> pseudonymous identifier. I agree that the RP has to trust the OP (in some
> sense) or make it's own determination that the OP is not honoring the RP's
> wishes and then take some action.
>
> For RP's behind firewalls, it would be nice to allow them some mechanism
> other than RP discovery to assert their requirements, but that should
> preclude the discover option.
>
> Thanks,
> George
>
> Andrew Arnott wrote:
>>
>> leaves out the scenario of unsolicited assertions.A new directed identity
>> value that the RP passes to the OP to indicate it wants a psuedononymous
>> identifier.  Consider this:
>>
>> An OP needs to perform RP discovery (already), and probably does so before
>> sending an unsolicited assertion in order to find out what the assertion
>> receiving URI would be for a given realm.  DNOA does this already.  If that
>> RP's XRDS document included a TypeURI element that had a special
>> psuedononymous-identifier-only-please value the OP could pick up on this,
>> and send the unsolicited assertion using the appropriate type of claimed_id.
>>
>> Likewise, when an RP sends an ordinary directed identity request to an OP,
>> the OP would again notice the RP's XRDS during RP discovery and see what
>> kind of identifier the RP wants and assert accordingly.
>>
>> Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP
>> discovery at all.  Perhaps to help the RP detect whether the OP respected
>> its wishes would be to send a PAPE extension or some other openid.*
>> parameter to say "yes, this is a pseudo- identifier."  RPs have no way to
>> analytically be certain that some identifier is psuedononymous anyway, so
>> ultimately the RP has to trust the OP (whether implicitly or through a white
>> list is up to the RP).
>>
>> --
>> 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 8:44 AM, George Fletcher > > wrote:
>>
>>    I don't think OpenID should specify how pseudonymous identifiers
>>    are generated. That should be up to the OP. But I like the idea of
>>    using a fixed URI as the claimed_id value to specify the behavior
>>    desired by the RP. If, however, we need to grow this to cover
>>    anonymous based identifiers (i.e. the claims based models from
>>    earlier in this thread) then it might make sense to look at a PAPE
>>    extension that covers the type of identifier requested.
>>
>>    Thanks,
>>    George
>>
>>
>>    Nat Sakimura wrote:
>>
>>        Sorry for a slow response. This week is especially busy for me...
>>
>>        I borrowed the notion from Austrian Citizen ID system.
>>        In there, the services are divided into "sectors."
>>        A sector may span several agencies.
>>        They call ID as PIN (Personal Identification Number).
>>
>>        There is a secret PIN (sPIN) which is not used anywhere but in
>>        their SmartCard.
>>        Then, sector sepcific PIN (ssPIN) is calculated in the manner of :
>>
>>        SHA1(sPIN + SectorID)
>>
>>        (Note, there is a bit more details but...)
>>
>>        I have thrown OP secret into it.
>>        To avoid the analytic attack, I agree that it is better to use
>>        individual secret, as some of you
>>        points out.
>>
>>        Regards,
>>
>>        =nat
>>
>>        On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
>>        mailto:dick.ha...@gmail.com>> wrote:
>>
>>            On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>>
>>                Reason for using RP's Subject in XRD instead of simply
>>                using realm is
>>                to allow for something like group identifier.
>>
>>            would you elaborate on the group identifier concept?
>>
>>
>>                This is just one idea. Downside of this approach
>>                is that we need to set up a WG.
>>
>>                I am sure there are mo

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

Agreed.  There is no reason for OpenID to mandate how pseudononymous
identifiers are created.  That should be left up to the OP.

--
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:28 AM, George Fletcher  wrote:

> I'm perfectly fine with using RP discovery as a mechanism for the RP to
> specify what "policy" it requires. I believe that unsolicited assertions are
> going to become more common, so we need to support it.
>
> What I don't want OpenID to do is specify the actual syntax of the
> pseudonymous identifier. I agree that the RP has to trust the OP (in some
> sense) or make it's own determination that the OP is not honoring the RP's
> wishes and then take some action.
>
> For RP's behind firewalls, it would be nice to allow them some mechanism
> other than RP discovery to assert their requirements, but that should
> preclude the discover option.
>
> Thanks,
> George
>
> Andrew Arnott wrote:
>
>> leaves out the scenario of unsolicited assertions.A new directed identity
>> value that the RP passes to the OP to indicate it wants a psuedononymous
>> identifier.  Consider this:
>>
>> An OP needs to perform RP discovery (already), and probably does so before
>> sending an unsolicited assertion in order to find out what the assertion
>> receiving URI would be for a given realm.  DNOA does this already.  If that
>> RP's XRDS document included a TypeURI element that had a special
>> psuedononymous-identifier-only-please value the OP could pick up on this,
>> and send the unsolicited assertion using the appropriate type of claimed_id.
>>
>> Likewise, when an RP sends an ordinary directed identity request to an OP,
>> the OP would again notice the RP's XRDS during RP discovery and see what
>> kind of identifier the RP wants and assert accordingly.
>>
>> Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP
>> discovery at all.  Perhaps to help the RP detect whether the OP respected
>> its wishes would be to send a PAPE extension or some other openid.*
>> parameter to say "yes, this is a pseudo- identifier."  RPs have no way to
>> analytically be certain that some identifier is psuedononymous anyway, so
>> ultimately the RP has to trust the OP (whether implicitly or through a white
>> list is up to the RP).
>>
>> --
>> 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 8:44 AM, George Fletcher > gffle...@aol.com>> wrote:
>>
>>I don't think OpenID should specify how pseudonymous identifiers
>>are generated. That should be up to the OP. But I like the idea of
>>using a fixed URI as the claimed_id value to specify the behavior
>>desired by the RP. If, however, we need to grow this to cover
>>anonymous based identifiers (i.e. the claims based models from
>>earlier in this thread) then it might make sense to look at a PAPE
>>extension that covers the type of identifier requested.
>>
>>Thanks,
>>George
>>
>>
>>Nat Sakimura wrote:
>>
>>Sorry for a slow response. This week is especially busy for me...
>>
>>I borrowed the notion from Austrian Citizen ID system.
>>In there, the services are divided into "sectors."
>>A sector may span several agencies.
>>They call ID as PIN (Personal Identification Number).
>>
>>There is a secret PIN (sPIN) which is not used anywhere but in
>>their SmartCard.
>>Then, sector sepcific PIN (ssPIN) is calculated in the manner of :
>>
>>SHA1(sPIN + SectorID)
>>
>>(Note, there is a bit more details but...)
>>
>>I have thrown OP secret into it.
>>To avoid the analytic attack, I agree that it is better to use
>>individual secret, as some of you
>>points out.
>>
>>Regards,
>>
>>=nat
>>
>>On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
>>mailto:dick.ha...@gmail.com>> wrote:
>>
>>On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>>
>>Reason for using RP's Subject in XRD instead of simply
>>using realm is
>>to allow for something like group identifier.
>>
>>would you elaborate on the group identifier concept?
>>
>>
>>This is just one idea. Downside of this approach
>>is that we need to set up a WG.
>>
>>I am sure there are more ideas. It might be possible
>>to utilize AX
>>so that it will only be a profile that does not
>>require a WG.
>>
>>So shall we start discussing which direction we want
>>to go forward?
>>
>>sure!
>>
>>
>>
>>
>>
>>
>>___
>>specs mailing list
>>specs@openid.net 
>>http://openid.net/mailman/li

Re: Requiring Pseudonymous Identifier

[George Fletcher]

I'm perfectly fine with using RP discovery as a mechanism for the RP to 
specify what "policy" it requires. I believe that unsolicited assertions 
are going to become more common, so we need to support it.


What I don't want OpenID to do is specify the actual syntax of the 
pseudonymous identifier. I agree that the RP has to trust the OP (in 
some sense) or make it's own determination that the OP is not honoring 
the RP's wishes and then take some action.


For RP's behind firewalls, it would be nice to allow them some mechanism 
other than RP discovery to assert their requirements, but that should 
preclude the discover option.


Thanks,
George

Andrew Arnott wrote:
leaves out the scenario of unsolicited assertions.A new directed 
identity value that the RP passes to the OP to indicate it wants a 
psuedononymous identifier.  Consider this:


An OP needs to perform RP discovery (already), and probably does so 
before sending an unsolicited assertion in order to find out what the 
assertion receiving URI would be for a given realm.  DNOA does this 
already.  If that RP's XRDS document included a TypeURI element that 
had a special psuedononymous-identifier-only-please value the OP could 
pick up on this, and send the unsolicited assertion using the 
appropriate type of claimed_id.


Likewise, when an RP sends an ordinary directed identity request to an 
OP, the OP would again notice the RP's XRDS during RP discovery and 
see what kind of identifier the RP wants and assert accordingly.


Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP 
discovery at all.  Perhaps to help the RP detect whether the OP 
respected its wishes would be to send a PAPE extension or some other 
openid.* parameter to say "yes, this is a pseudo- identifier."  RPs 
have no way to analytically be certain that some identifier is 
psuedononymous anyway, so ultimately the RP has to trust the OP 
(whether implicitly or through a white list is up to the RP).


--
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 8:44 AM, George Fletcher > wrote:


I don't think OpenID should specify how pseudonymous identifiers
are generated. That should be up to the OP. But I like the idea of
using a fixed URI as the claimed_id value to specify the behavior
desired by the RP. If, however, we need to grow this to cover
anonymous based identifiers (i.e. the claims based models from
earlier in this thread) then it might make sense to look at a PAPE
extension that covers the type of identifier requested.

Thanks,
George


Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in
their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
mailto:dick.ha...@gmail.com>> wrote:
 


On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
   


Reason for using RP's Subject in XRD instead of simply
using realm is
to allow for something like group identifier.
 


would you elaborate on the group identifier concept?

   


This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible
to utilize AX
so that it will only be a profile that does not
require a WG.

So shall we start discussing which direction we want
to go forward?
 


sure!

   





 


___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

On Thu, May 14, 2009 at 12:46 AM, SitG Admin
 wrote:
> Having two simultaneous threads on two closely related lists, with the same
> subject line, can be confusing.

Right.

The original that I raised is what I have explained copule of hours ago.
It is the identifier of the RP Service (which may span multiple domains).
This has impact onto the psudonymous identifier generation.
As I have explained in my previous post, there are some real
requirements for it, esp. in the government sector.

In contrast, identifier for group of individual while interesting is not
directly related to the psudonym issue. So, shall we separate this
topic into another thread with more appropriate subject?

=nat
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Andrew Arnott]

 leaves out the scenario of unsolicited assertions.A new directed identity
value that the RP passes to the OP to indicate it wants a psuedononymous
identifier.  Consider this:

An OP needs to perform RP discovery (already), and probably does so before
sending an unsolicited assertion in order to find out what the assertion
receiving URI would be for a given realm.  DNOA does this already.  If that
RP's XRDS document included a TypeURI element that had a special
psuedononymous-identifier-only-please value the OP could pick up on this,
and send the unsolicited assertion using the appropriate type of claimed_id.

Likewise, when an RP sends an ordinary directed identity request to an OP,
the OP would again notice the RP's XRDS during RP discovery and see what
kind of identifier the RP wants and assert accordingly.

Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP
discovery at all.  Perhaps to help the RP detect whether the OP respected
its wishes would be to send a PAPE extension or some other openid.*
parameter to say "yes, this is a pseudo- identifier."  RPs have no way to
analytically be certain that some identifier is psuedononymous anyway, so
ultimately the RP has to trust the OP (whether implicitly or through a white
list is up to the RP).

--
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 8:44 AM, George Fletcher  wrote:

> I don't think OpenID should specify how pseudonymous identifiers are
> generated. That should be up to the OP. But I like the idea of using a fixed
> URI as the claimed_id value to specify the behavior desired by the RP. If,
> however, we need to grow this to cover anonymous based identifiers (i.e. the
> claims based models from earlier in this thread) then it might make sense to
> look at a PAPE extension that covers the type of identifier requested.
>
> Thanks,
> George
>
>
> Nat Sakimura wrote:
>
>> Sorry for a slow response. This week is especially busy for me...
>>
>> I borrowed the notion from Austrian Citizen ID system.
>> In there, the services are divided into "sectors."
>> A sector may span several agencies.
>> They call ID as PIN (Personal Identification Number).
>>
>> There is a secret PIN (sPIN) which is not used anywhere but in their
>> SmartCard.
>> Then, sector sepcific PIN (ssPIN) is calculated in the manner of :
>>
>> SHA1(sPIN + SectorID)
>>
>> (Note, there is a bit more details but...)
>>
>> I have thrown OP secret into it.
>> To avoid the analytic attack, I agree that it is better to use
>> individual secret, as some of you
>> points out.
>>
>> Regards,
>>
>> =nat
>>
>> On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  wrote:
>>
>>
>>> On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>>>
>>>
 Reason for using RP's Subject in XRD instead of simply using realm is
 to allow for something like group identifier.


>>> would you elaborate on the group identifier concept?
>>>
>>>
>>>
 This is just one idea. Downside of this approach
 is that we need to set up a WG.

 I am sure there are more ideas. It might be possible to utilize AX
 so that it will only be a profile that does not require a WG.

 So shall we start discussing which direction we want to go forward?


>>> sure!
>>>
>>>
>>>
>>
>>
>>
>>
>>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[SitG Admin]

Having two simultaneous threads on two closely related lists, with 
the same subject line, can be confusing.


Overloading our existing concept of an identifier to support 
identifying a group worries me. Most consumers expect an identifier 
to be for a person and are designed around this principle.


This worries me; I think it's narrow-minded to expect that users will 
always be identified individually. Interpreting the larger concept of 
"identity" as the smaller subset of "individuals" limits Consumer's 
ability to understand (and interact with) real-life relationships.


I think if groups are useful their design should be different such 
that consumers are able to distinguish between a user and a group.


I'd like to see group identity right alongside individual identity, 
not relegated to an extension or otherwise consigned to optional 
implementation. If the RP doesn't need to distinguish between 
separate members of a group, it shouldn't have to work any harder 
technically to accept group logins.


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[George Fletcher]

I don't think OpenID should specify how pseudonymous identifiers are 
generated. That should be up to the OP. But I like the idea of using a 
fixed URI as the claimed_id value to specify the behavior desired by the 
RP. If, however, we need to grow this to cover anonymous based 
identifiers (i.e. the claims based models from earlier in this thread) 
then it might make sense to look at a PAPE extension that covers the 
type of identifier requested.


Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  wrote:
  

On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using realm is
to allow for something like group identifier.
  

would you elaborate on the group identifier concept?



This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?
  

sure!






  

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[George Fletcher]

+1 to using AX and the identity-less flow Andrew identified recently for 
claims/attribute based access to web sites.


There are some 3rd-party asserted issues in regards to the validity of 
the attribute value but that's a whole different discussion:)


Thanks,
George

Luke Shepard wrote:
Agreed. If all you want is a group, then I’d think that the response 
would just not include an identifier.


You could use an extension, perhaps AX, to request information about 
the group a user belongs to.


For example, if you wanted to understand company membership, you could 
request and return only http://axschema.org/company/name.


On 5/12/09 11:08 PM, "Martin Atkins"  wrote:

Chris Messina wrote:
>
> So, imagine I use directed identity in a school application...
when I sign
> in to the OP, it will return something like
schoolname.edu/student as the
> identifier.
>

Overloading our existing concept of an identifier to support
identifying
a group worries me. Most consumers expect an identifier to be for a
person and are designed around this principle.

I think if groups are useful their design should be different such
that
consumers are able to distinguish between a user and a group.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  wrote:
>
> On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>>
>> Reason for using RP's Subject in XRD instead of simply using realm is
>> to allow for something like group identifier.
>
> would you elaborate on the group identifier concept?
>
>>
>>
>> This is just one idea. Downside of this approach
>> is that we need to set up a WG.
>>
>> I am sure there are more ideas. It might be possible to utilize AX
>> so that it will only be a profile that does not require a WG.
>>
>> So shall we start discussing which direction we want to go forward?
>
> sure!
>



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

Re: Requiring Pseudonymous Identifier

[Luke Shepard]

Agreed. If all you want is a group, then I'd think that the response would just 
not include an identifier.

You could use an extension, perhaps AX, to request information about the group 
a user belongs to.

For example, if you wanted to understand company membership, you could request 
and return only http://axschema.org/company/name.

On 5/12/09 11:08 PM, "Martin Atkins"  wrote:

Chris Messina wrote:
>
> So, imagine I use directed identity in a school application... when I sign
> in to the OP, it will return something like schoolname.edu/student as the
> identifier.
>

Overloading our existing concept of an identifier to support identifying
a group worries me. Most consumers expect an identifier to be for a
person and are designed around this principle.

I think if groups are useful their design should be different such that
consumers are able to distinguish between a user and a group.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Martin Atkins]

Chris Messina wrote:


So, imagine I use directed identity in a school application... when I sign
in to the OP, it will return something like schoolname.edu/student as the
identifier.



Overloading our existing concept of an identifier to support identifying 
a group worries me. Most consumers expect an identifier to be for a 
person and are designed around this principle.


I think if groups are useful their design should be different such that 
consumers are able to distinguish between a user and a group.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Paul Madsen]

there are telco use cases where a family member, by dint only of  
'subscriber authentication' to the IDP/OP, is able to access shared 
resources (e.g. family calendar) at an SP/RP.


Unlike in Chris's academia case the OP/IDP is itself unable to 
distinguish a particular user from amongst other group members based on 
this sort of authentication.


To allow the SP to indicate  back to the IDP that it needed a user 
authenticated as an individual (to allow for instance the RP to show 
calendar events associated with the user and not shared amongst the 
group) in SAML we defined an extension to Authn Context to distinguish 
between such shared credentials and those that are unique to a single user.


http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-context-ext-sc-cd-03.pdf

paul

Chris Messina wrote:
On Tue, May 12, 2009 at 10:55 AM, Dick Hardt > wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using
realm is
to allow for something like group identifier.


would you elaborate on the group identifier concept?


I'm not sure what Nat is specifically referring to, but there was a US 
academic institution that provided OpenIDs for "classes" of people... 
i.e. students, teachers, etc.


When you signed in for certain application, the OP would respond with 
the appropriate identifier for a class of users.


So, imagine I use directed identity in a school application... when I 
sign in to the OP, it will return something like 
schoolname.edu/student  as the identifier.


You could imagine something similar where you could use authentication 
as a way to verify that someone comes from some geographic region or 
has previously registered for certain entitlements.


Chris

--
Chris Messina
Open Web Advocate

factoryjoe.com  // diso-project.org 
 // openid.net  // 
vidoop.com 

This email is:   [ ] bloggable[X] ask first   [ ] private


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Chris Messina]

On Tue, May 12, 2009 at 10:55 AM, Dick Hardt  wrote:

>
> On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>
>>
>> Reason for using RP's Subject in XRD instead of simply using realm is
>> to allow for something like group identifier.
>>
>
> would you elaborate on the group identifier concept?


I'm not sure what Nat is specifically referring to, but there was a US
academic institution that provided OpenIDs for "classes" of people... i.e.
students, teachers, etc.

When you signed in for certain application, the OP would respond with the
appropriate identifier for a class of users.

So, imagine I use directed identity in a school application... when I sign
in to the OP, it will return something like schoolname.edu/student as the
identifier.

You could imagine something similar where you could use authentication as a
way to verify that someone comes from some geographic region or has
previously registered for certain entitlements.

Chris

-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net // vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Dick Hardt]

On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using realm is
to allow for something like group identifier.


would you elaborate on the group identifier concept?




This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


sure!
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs