Re: [Unity-idm-discuss] Addition to OAuth2/OIDC tokens

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

Hi Sander,

let me ask for few clarifications.

W dniu 15.02.2022 o 15:26, Sander Apweiler pisze:
> Hello Krzysztof,
> hello Roman,
>
> since our connected SPs are growing we do get further feature request,
> which I want to share with you.
>
> The first one is a possibility to change the aud of a registered
> client. At the moment unity uses the registered username of the OIDC
> client, which is fine according to the RFC. But there are connected
> services which does the audience use, too. In this specific use-case
> the token was generated by the user using the oidc-agent tool [1]. The
> generated token was send via an API to dCache which validates the
> token. dCache is also checking the audience and rejects all token
> having an unsupported audience. The OIDC agent has an option the
> request a specific aud value for the token and forwards this request to
> the AS. Together with the request users showed us examples where Indigo
> IAM do support this. Would it possible to implement this unity, too?

So for the support of multiple audiences per client - certainly that's 
possible. I understand that this is just a configuration of allowed 
additional audiences. Each of such audience should have its identifier 
and have to be returned. Easy.

Can you tell more what is the purpose of "requesting" of a specific 
audience by the client? I think it is some proprietary feature of Indigo 
IAM. We can have it, but sounds like a bigger work, and I need to 
understand the purpose and details of the use case. Also, technically, 
would that be just narrowing of the allowed audiences of the client? 
Shall that be then also presented on consent screen?


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

Best,
Krzysztof