Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))

[Denis <[e-mail]>]

Justin,

Since the "sub" claim has been "diverted" from it original semantics, we 
will need to define four types of identifiers for a user,whether it is:

    (1) temporarily unique,
    (2) unique to the resource server,
    (3) unique to the authorization server (this was the original
    semantics of the "sub" claim) or
    (4) globally unique (e.g. a distinguished name or an email address).

In terms of privacy, for each of them, the consequences are quite different.

Denis

> I am saying that GNAP, it its definition within this working group, 
> should be limited to identifier claims. Other claims can come from 
> other protocols properly layered on top of GNAP. GNAP shouldn’t stop 
> them from being built, but in my opinion we shouldn’t be defining 
> those here. See the discussion below on the extensibility avenues of 
> this approach.
>
>  — Justin
>
>> On Jul 13, 2020, at 2:12 PM, Dick Hardt <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> I agree that an API to return claims is useful. I think we have 
>> agreed on that.
>>
>> Using the SubjectIdentifiers schema is another schema that would be 
>> useful for GNAP to support.
>>
>> I disagree that GNAP should be limited to identifier claims.
>>
>> ᐧ
>>
>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     One thing I think we should learn from OIDC is that returning
>>     claims from an API, and not just an assertion or direct response,
>>     is a powerful and useful pattern. We have an opportunity to
>>     separate these cleanly, where OIDC didn’t have the opportunity in
>>     defining the “claims” request parameter.
>>
>>     As an alternative to the current XYZ and XAuth syntaxes, over the
>>     weekend I’ve been playing with something that would look like
>>     this strawman in the request:
>>
>>
>>         {
>>            subject: {
>>               id: [ “account”, “email”, “iss-sub”],
>>               assertion: [ “odic_id_token”, “verifiable_credential”,
>>         “saml" ]
>>            }
>>         }
>>
>>
>>     This request says that I’d like some subset of these identifiers
>>     (as plain text in the response) and some subset of signed
>>     assertions in the given formats. Each one would have an
>>     associated space in the return. I’m not picturing that the “id”
>>     field values would affect the contents of the assertions: so I
>>     could ask for an email address identifier but get back an ID
>>     token that had only the subject identifier. Maybe that’s not the
>>     right model? But it’s at least simple and deterministic this way,
>>     and it’s something to play with.
>>
>>     Note: The “id” names are taken from
>>     https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html,
>>     the “assertion” names are made up as I didn’t see a source that
>>     collected them. If you wanted specific bundles of claims about
>>     the user from a UserInfoEndpoint, for example, you’d have
>>     something like:
>>
>>         {
>>            subject: {
>>               id: [ “account”, “email”, “iss-sub”],
>>               assertion: [ “odic_id_token”, “verifiable_credential”,
>>         “saml" ]
>>            },
>>            resources: [{
>>                type: “userinfo”,
>>                datatypes: [ “openid”, “profile”, “phone”, “email” ]
>>           }]
>>         }
>>
>>
>>     This is an example for a specific kind of resource, and I don’t
>>     think that GNAP should define the “userinfo” schema here, or the
>>     datatype values therein. That should be work outside of GNAP,
>>     probably for the OIDF.
>>
>>     This approach is extensible in several ways, each of them for a
>>     specific reason that I think is clear:
>>
>>      - new values in the “id” field to give new identifiers
>>      - new values in the “assertion” field to give new assertion formats
>>      - new fields under the “subject” heading
>>      - new resource types besides “userinfo” (like “scim-v1” or
>>     “facebook-profile” for instance)
>>      - new datatypes within the “userinfo” resource type
>>      - new top-level request parameters
>>
>>     As per the other thread, if you wanted to use the OIDC query
>>     language, you’d package it separately as a top-level request
>>     parameter since it can include both the ID token response and the
>>     access token response and we shouldn’t be encouraging mixing
>>     these things together.
>>
>>      — Justin
>>
>>>     On Jul 10, 2020, at 5:00 PM, Dick Hardt <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>     It looks to me that our different views of what is in scope for
>>>     GNAP are the differences below.
>>>
>>>     Per the subject line, I'm looking at how the client acquires
>>>     claims about the user. You don't think that is in scope, and
>>>     that a different layer will solve that.
>>>
>>>     I think we should learn from OIDC being on top of OAuth, and
>>>     GNAP should be able return ANY claim, not just identifier
>>>     claims. There are use cases that may be difficult to support if
>>>     we do not have that functionality in scope, such as some of the
>>>     ones I list below, and it seems pretty straightforward to
>>>     support ANY claim if we are supporting identifiers.
>>>
>>>     /Dick
>>>
>>>
>>>     On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>>>         On Jul 10, 2020, at 2:15 PM, Dick Hardt
>>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>         inline ...
>>>>
>>>>         On Thu, Jul 9, 2020 at 5:44 PM Justin Richer
>>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>             Yes, the core idea is to not have to parse an assertion
>>>>             to get back the core authentication information, which
>>>>             consists of an identifier (iss/sub pair in OIDC, but
>>>>             could be a number of things). Sometimes the client is
>>>>             going to want the rest of the identity information,
>>>>             but If the user’s logged into the client before, the
>>>>             client has likely cached that info and probably won’t
>>>>             need it, and sending it would be a violation of privacy
>>>>             principles.. The client would want the info pretty much
>>>>             just in these cases:
>>>>
>>>>              1. The client has never seen the user before.
>>>>              2. The user’s information has been updated since the
>>>>             last time the client saw it.
>>>>
>>>>
>>>>         Agreed
>>>>
>>>>
>>>>             Now for case (1), how would the client know if it wants
>>>>             to request the user’s profile info or not, since it
>>>>             doesn’t know who the user is?
>>>>
>>>>
>>>>         But the client could know who the user is. The client may
>>>>         have used a different AS to authenticate the user.
>>>
>>>         In these cases, the client is not going to be requesting
>>>         identity information from the AS to log the user in, so it’s
>>>         not relevant to the use case. The client will have an
>>>         opportunity to push that information to the AS.
>>>
>>>>         The User may have self identified to the client. The client
>>>>         may have a cookie saying who the user was and the user said
>>>>         that was them. While the latter cases are really a strong
>>>>         hint, they are likely right most of the time and can lead
>>>>         to a user experience basde on that hint
>>>
>>>         In these cases, the AS might be able to guess if the client
>>>         has info about the user already, but probably not. And the
>>>         assumptions fall apart if it’s in fact a different user that
>>>         ends up logging in, which is of course possible (the hint
>>>         you gave doesn’t match the identity of the current user
>>>         after the AS validates them). This possibility leads to
>>>         clients always asking for everything every time and the
>>>         server providing everything every time. That’s a pattern I
>>>         think we should avoid in an ultimate solution — but
>>>         ultimately, I don’t think that this kind of protocol
>>>         decision is inside of GNAP.
>>>
>>>>             And the AS won’t know if client is going to want the
>>>>             profile info, since the AS won’t know if the client has
>>>>             the user’s info or not. Sure, the AS might have seen
>>>>             that client and that user combo previously, but it
>>>>             doesn’t know if the client needs an update.
>>>>
>>>>
>>>>         The client can share with the AS the user it knows or
>>>>         thinks it is dealing with, which could let the AS respond
>>>>         if the information was new. This could be the case for an
>>>>         AS that is providing claims, but not authentication, and
>>>>         could happen silently. The user would only interact if the
>>>>         user information had changed, and the client wanted the
>>>>         updated information.
>>>
>>>         See above.
>>>
>>>>
>>>>             And for (2), the client won’t know if the user’s info
>>>>             has been updated or not because it doesn’t know who the
>>>>             user is yet. If the AS can provide some time of updated
>>>>             stamp to the client, the client can pull the new info
>>>>             when it needs it.
>>>>
>>>>
>>>>         See above.
>>>
>>>         See above.
>>>
>>>>
>>>>             If you ignore both of these cases and put all the user
>>>>             information inline with the main request/response, you
>>>>             end up in a situation where the client always requests
>>>>             everything and the server always provides everything,
>>>>             since you can’t be sure you’re not in situation (1) or
>>>>             (2) ahead of time.
>>>>
>>>>
>>>>         See above. There are a number of other states the client
>>>>         could be in.
>>>>
>>>>         For example, the client could be stateless about user
>>>>         information, so it knows it is ALWAYS in state 1.
>>>
>>>         A stateless client would need to fetch appropriate user
>>>         information every time, then. But that’s an optimization for
>>>         a very specific case.
>>>
>>>>
>>>>             This is really what I mean about the two-stage identity
>>>>             protocol.
>>>>
>>>>
>>>>         I know what it is. Per above, GNAP lets us support a wider
>>>>         set of use cases. Why limit ourselves to what OIDC supported?
>>>
>>>         We aren’t limiting the protocol, but instead limiting the
>>>         scope of what we define internal to the GNAP protocol.
>>>         There’s a lot of room for innovation on top of it.
>>>
>>>>             In the first stage, you push the bare minimum of what
>>>>             you need to get the user known to the client. In the
>>>>             second stage, the client uses its access token to call
>>>>             an API to get whatever else it needs to know about the
>>>>             user.
>>>>
>>>>
>>>>         From a privacy perspective in non-enterprise use cases, I
>>>>         think the user should give consent to any updated personal
>>>>         information to a client. In general, the client should not
>>>>         be able to get the latest information about a user whenever
>>>>         it wants.
>>>
>>>         This is about the rights associated with the access token,
>>>         then. And an access token doesn’t have to keep working if
>>>         the AS has a policy that says it won’t. The AS/RS could
>>>         easily decide that a particular access token will only
>>>         return data that hasn’t been changed. Maybe it stops working
>>>         after the data changes, or it just returns old data, or any
>>>         number of things. This is for the AS/RS to decide and this
>>>         is pretty standard interpretation of the token, nothing
>>>         special here because we’re dealing with identity.
>>>
>>>          — Justin
>>>
>>>>         /Dick
>>>>         ᐧ
>>>
>>
>
>