Re: [Unity-idm-discuss] Claims in id token

[Krzysztof B. <kb...@un...>]

Marcus,

W dniu 28.02.2022 o 12:34, Marcus Hardt pisze:
> On 28. Feb 2022 12:11, Krzysztof Benedyczak wrote:
>> Hi Marcus,
>>
>> W dniu 23.02.2022 o 18:06, Marcus Hardt pisze:
>>> Hi Krzysztof,
>>>
>>>
>>> On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote:
>>>> Hi,
>>>>
>>>> I'm leaving the longer thread below for reference, however the main open
>>>> point is how to specify what should land in JWT-style access token.
>>>> I see no security implications here, so that's not a problem.
>>>>
>>>>   From what you wrote configuring that via scopes is not great as would make
>>>> it hard for the clients.
>>> I'm not sure I understand. Requesting specific scopes is in the standard.
>>> I understand that the problem is which claims go into jwt AT and which
>>> ones are in the userinfo-endpoint, right?
>> Requesting scopes is in the standard, that's no problem. But as I understood
>> Sander (and also can imagine on my own) that's bit of an organizational
>> problem.
>>
>> Let's assume Unity allows admin to configure per scope, whether attributes
>> of that scope should go to AT or not. Now, if you have clients that require
>> no extra claims in AT and some with opposite requirement, then you will need
>> to create a duplicate of each scope in Unity:
>>
>> profile; profile_in_at
>>
>> job_info; job_info_in_at
>>
>> ... which will differ only with that setting. Clunky, both from server side
>> and client side.
>   
> Hmm. Another clarification (that isn't 100% clear, maybe): I think this
> problem mostly relates to a single client-id: oidc-agent, as this is the
> one used in many use-cases that involving delegation.
>   
>> Also a small clarification: user-info endpoint will always return all
>> claims. The only problem to decide is which claims also are put into JWT AT.
> Ok;
>
> After thinking a bit, I think it might be best to keep both sets equal.
> One (the main showstopper?) for AT<1K is our own application, and we do
> have an inimplemented workaround.  I think we'll have that done in like 4
> months (because there is more pressing stuff around).
>
>>>> Configuring per client is not acceptable as the same client may operate in
>>>> different contexts and in some it is using some dumb services which have a
>>>> limit on access token size.
>>> Yes. Fully agree.
>>>> So what are the proposals here? Use some proprietary request parameter for
>>>> it?
>>> I really don't know. If this is really about which scopes go into which
>>> place (JWT vs userinfo), then something proprietary might not be so
>>> harmful. I'm sure this question will bother others, too.
>>>
>>>
>>> One way out, could be to live with the long ATs.
>>>
>>> I'll check with our OIDC expert, but this won't turn around before monday.
>>
>> OK, let us know.
>>
>> If thinking about proprietary solution, I think we can have it. However I'd
>> keep it dead simple: just a flag "uy_put_claims_in_access_token", which
>> would put all claims in AT.
> He suggested using the same mechanism as in the "claims" place, but using
> a different keyword.
>
> He sends this reference: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
>
> Maybe just calling it "claims_at" would be all it takes.
>
The claims parameter which in OIDC spec governs what should be put in id 
token or user info fits nicely after adding claims_at. Agreed. But from 
client side it is quite a complex parameter - you operate not on "all 
claims", not on "claims related to scopes" but on individual claims. You 
need to know them, there is no "*". Also this is complementary to claims 
resulting from scopes, what dramatically increases complexity (e.g. 
asking user to accepts some well defined scopes is easy, but about each 
individual attribute/claim is not).

It sounds to me 10x more complex than what you need.

Best,

Krzysztof