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

[John Bradley]

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
>