[Openid-specs-ab] Attribute Exchange w/ OpenID Connect?

[John Bradley]

Pairwise pseudonymous allows the RP to recognize if the same user comes back, however it doesn't tell them who the user is in any way that they can correlate with other sites.

That seems to satisfy 90% of the privacy use cases.

The next step up would be to not allow them to recognize the same user between sessions.  The IdP would use some session counter as part of the identifier calculation to generate a new one with each new login.
You however want it to be stable enough to be useful for session management, (detecting if the user in the browser has changed and the claims are no longer valid.

It sort of depends on what you are trying to protect against.

John B.

On 2012-12-01, at 4:23 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> Do you mean there is effectively no difference between PPID and no user id since the RP can anyway recognize the user?
> 
> regards,
> Torsten.
> 
> 
> 
> John Bradley <ve7jtb at ve7jtb.com> schrieb:
> That could easily be done in the current spec.
> 
> I don't quite know why PPID won't work for you though.
> 
> 
> On 2012-12-01, at 2:35 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> 
> 
> 
> What sort of tracking are you trying to stop?
> 
> If it is give me an attribute for the current person without
> establishing a session that would be an ephemeral single use
> identifier.   (No session management)
> 
> That's what I want. Would this require a new user id type?
> 
> Setting this per client id is fine.
> 
> Regards,
> Torsten.
> 
> If you want to have a session with the person based on claims but not
> establish a persistent account then it would be per session ephemeral. 
> (session management/ change user is possible)
> 
> user_id_type in registration allows the identifier type to be set per
> client.
> 
> We talked about having it in the request object, but allowing a client
> to change it per request was seen as overkill.
> Most IdP will restrict what a client can ask for based on some privacy
> policy, so the discovery/registration mechanism was thought to be
> sufficient.
> 
> Nothing stops a site from having multiple client ID if it needs to get
> different identifier types.  Having the different client ID stops a
> client from asking for PPID and getting connect and then asking for a
> public identifier in a later call where the user is not
> notified.
> 
> John B.
> On 2012-11-30, at 1:19 PM, Torsten Lodderstedt
> <torsten at lodderstedt.net> wrote:
> 
> We don't want the RP to track the user. So we would need to issue
> different user_id for every request. But I don't think is fit into the
> Connect philosophy.
> 
> regards,
> Torsten.
> 
> Am 30.11.2012 17:11, schrieb Justin Richer:
> Would using pairwise identifiers make this work?
> 
> -- Justin
> 
> On 11/30/2012 11:09 AM, Torsten Lodderstedt wrote:
> Hi,
> 
> in some cases we want to provide RPs with attributes but no
> user_id, which is similar to AX. How can this be realized in Connect?
> The scope value "openid" activates the OpenID mode at the AS but it
> also requests access to the user_id Claim. If we do not want to
> disclose a user_id, does this mean we need to define a new, distinct
> scope for our use case, e.g. "attribute_x"?
> 
> regards,
> Torsten.
> 
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121202/90b5bd64/attachment.html>