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

[Dick Hardt <[e-mail]>]

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]> 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]> 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]> wrote:
>
>>
>>
>> On Jul 10, 2020, at 2:15 PM, Dick Hardt <[e-mail]> wrote:
>>
>>
>> inline ...
>>
>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <[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
>> ᐧ
>>
>>
>>
>