[Openid-specs-ab] Attribute Exchange w/ OpenID Connect?
sakimura at gmail.com
Wed Mar 11 13:06:32 UTC 2015
Not sure how it went but like I said before, ephemeral identifier is
perfectly legal in OpenID Connect.
It is just the matter of asking for it, and I suggested using ACR for it.
The resulting sub/user_id is going to be one time only - anonymous
That's how an attribute based credential should be created using OpenID
Perhaps we should write a mini-spec / I-D so that we can register the value
"anonymous" to the registry.
On Wed, Mar 11, 2015 at 9:57 PM Eve Maler <eve at xmlgrrl.com> wrote:
> Hi Torsten-- N.B.: I don't think I have posting privileges on this list;
> not sure if the moderator let my previous note through, or if you'll see it
> simply because I'm sending it directly to you as well...
> As long as the identifier coming from the IdP is "directed" (in
> OpenID-speak), meaning it makes a different federated identifier for each
> RP so that multiple RPs can't collude to identify the user on the basis of
> the IDs they've been given, then that's one issue taken care of. The next
> issue is whether the identifier itself reveals anything about the user.
> It's possible to create "directed identities" that are revealing -- e.g.,
> bob+rp1 at gmail.com, bob+rp2 at gmail.com... But the usual intent with
> federated identifiers is to make them non-revealing, e.g.
> "randomstring6234sdfd345" for RP1, etc. Making them explicitly transient as
> well as pseudonymous also limits the temporal scope of their usefulness,
> which helps avoid the trap of internal correlation at the RP or collusion
> with others over time as the pseudonym ages. In SAML, the assumption is
> that the temporal scope limitation is session-length, to at least allow for
> things like single logout while protecting against cross-session
> On 1 Dec 2012, at 7:26 AM, Torsten Lodderstedt <torsten at lodderstedt.net>
> Hi Eve,
> thanks for pointing this out. At first glance it seems to be feasable
> although I honestly don't know whether such an identifier would conflict
> with the OIDC semantics.
> To give you more context: I'm looking for a way to "just" assert a boolean
> claim to the RP. The use case, I'm currently investigating, is age
> verification. The RP wants the OP to attest whether the user is above 18.
> There is no session between RP and OP and the OP will typically not
> disclose any further data. I would prefer to realize this without the need
> to make up an identifier just to fulfill the protocol requirements.
> Eve Maler <eve at xmlgrrl.com> schrieb:
>> This sounds just like the justification for SAML's transient pseudonyms -- good only for the current session, handy for cases where the RP needs some sort of unique "handle" for internal user/session management, and useful for session timeouts or single logout a bit later on.
>> On 30 Nov 2012, at 8:19 AM, 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.
>>> Am 30.11.2012 17:11, schrieb Justin Richer:
>>>> using pairwise identifiers make this work?
>>>> -- Justin
>>>> On 11/30/2012 11:09 AM, Torsten Lodderstedt wrote:
>>>>> 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"?
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>> Eve Maler http://www.xmlgrrl.com/blog
>> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab