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

[Marcus H. <ha...@ki...>]

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.

-- 
Marcus.