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

Sun Mar 15 17:03:11 UTC 2015

Hi Eve, Nat,

thanks for your advice.

Our current implementation uses a constant "identifier" with a value of 
"anonymous".

kind regards,
Torsten.

Am 11.03.2015 um 14:06 schrieb Nat Sakimura:
> Hi Torsten,
>
> 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 
> identifier.
> That's how an attribute based credential should be created using 
> OpenID Connect.
>
> Perhaps we should write a mini-spec / I-D so that we can register the 
> value "anonymous" to the registry.
>
> Nat
>
> On Wed, Mar 11, 2015 at 9:57 PM Eve Maler <eve at xmlgrrl.com 
> <mailto: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 <mailto:bob+rp1 at gmail.com>, bob+rp2 at gmail.com
>     <mailto: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 correlation.
>
>     FWIW,
>
>     Eve
>
>     On 1 Dec 2012, at 7:26 AM, Torsten Lodderstedt
>     <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>>     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.
>>
>>     regards,
>>     Torsten.
>>
>>
>>
>>     Eve Maler <eve at xmlgrrl.com <mailto: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.
>>
>>           Eve
>>
>>         On 30 Nov 2012, at 8:19 AM, Torsten Lodderstedt <torsten at lodderstedt.net  <mailto: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
>>                     <mailto: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
>>             <mailto:Openid-specs-ab at lists.openid.net>
>>             http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>         Eve Malerhttp://www.xmlgrrl.com/blog
>>         +1 425 345 6756http://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
>     <mailto: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/20150315/0e7d6ed9/attachment.html>