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

[Dick Hardt <[e-mail]>]

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
> ᐧ
>
>
>