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

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

And here the remaining part of the original thread, related to extra 
claims in id/access tokens.

W dniu 21.02.2022 o 11:42, Sander Apweiler pisze:
>>>> The second request we got is about user attributes within the
>>>> token.
>>>> The user, who made the request told us that the targeted software
>>>> does
>>>> not support requests to userinfo endpoint and does not keep
>>>> consistent
>>>> information about the user. For this they need information about
>>>> the
>>>> user in the token itself. I got the friendly hint that WLCG does
>>>> it in
>>>> this way. We already talked in the past about the possibility to
>>>> add
>>>> own claims. Maybe the better solution would be supporting the
>>>> request
>>>> parameter to allow SPs to request the needed claims itself
>>>> instead of
>>>> adding some claims in general. Would this be an option for unity?
>>> We have a ticket on that already recorded, and is on the top of
>>> open source
>>> queue.
>>>
>>> Although we understand this bit differently. We were thinking about
>>> server-side controlled setting to include some of the claims
>>> (attributes) in
>>> the id token (applies to oidc mode only). Perhaps configured per
>>> scope (as
>>> we have attributes bound to scopes).
>>>
>>> Putting client in control of that sounds as a bit of an overkill.
>>> Especially
>>> if you want to allow client to pick and choose which individual
>>> attributesshould go into id token. Is there a strong use case for
>>> that?
>> I guess this goes a bit like the scopes clients can request to be
>> available in the userinfo endpoint.
>>
>> The current headache this brings up for the AccessTokens is that we
>> have
>> two compeing use cases. One would like to have all authorisation
>> statements inside the token, so it never ever needs to contact the
>> OP,
>> while the other needs tokens below the 1k limit.
>>
>> Both of these use cases can be asked to work around this. I don't
>> have a
>> strong opinion here.
> I guess the first ticket was also initiated by me. The first Idea was
> to have it under server control, because it was "only" groupmembership
> information which was needed by some services. In meantime other
> services requests other attributes in the access token.
>
> Putting more information in the AT, the large size of it creates
> problems for some other service. For this reason we do not want to put
> to many additional attributes in the AT. In the best case only the
> attributes which are needed by the specific service. For this the
> services need a way to signal it to unity. Of course the unity
> administrators must be able to limit/configure which attributes could
> be released within the AT.
>
> I don't know if the specification contains something about this. If not
> hinting the needed attributes in the token via specific scopes might be
> a way.

Well, so it seems we have a small confusion. Id token, or JWT access token?

For the other part of the question, i.e. how to request and or configure 
it seems that this is strongly client-specific. So why not tho have this 
switch per-client? Sounds as the easiest way forward.

Configuration with scopes would also work, but would require more dev 
work, and then more configuration (admin would need to double number of 
scopes, to have variants with a thin token, or fully packed.

WDYT?

Krzysztof