[Openid-specs-ab] Attribute Exchange w/ OpenID Connect?
John Bradley
ve7jtb at ve7jtb.com
Sat Dec 1 15:52:06 UTC 2012
We have pairwise pseudonymous identifiers to prevent correlation now.
Are you looking for an identifier that is ephemeral and would change for each login. Or change for each request.
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)
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
More information about the Openid-specs-ab
mailing list