[Openid-specs-ab] JWT Header for signed id tokens

[Karl McGuinness]

Hi George,

They are related in the fact that they share the same set of identity
claims about a user & signed by the same issuer.  A developer for example
who implemented JIT provisioning with an ID Token would process the same
claims in a "maintain" command token and validate the token using the same
trust root & signing keys.  In other words, the Claim Registration for ID
Tokens is reused for Command Tokens.

The RP discovers what claims an OP could issue for a user that could be
sent via an ID Token or Command Token.   The idea is that the OP only
publishes 1 view of the user to the RP.  A developer doesn't need to handle
schema/mappings/etc differently if they get the claims via UserInfo, and ID
token, or a Command Token it's all the same OP identity for the RP

-Karl

On Fri, Mar 14, 2025 at 7:53 AM george--- via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Joseph,
>
> I agree. My point was more that OP Commands should NOT try and relate
> itself to id_tokens at all. Instead, define the OP Command JWT using
> current best practice and then make the point that the keys used to sign
> the OP Command are the same as those used to sign an ID Token. Otherwise,
> I’m not sure there need to be any mention of ID Tokens at in the context of
> OP Commands.
>
> George Fletcher
> Identity Standards Architect
> Practical Identity LLC
>
>
>
> > On Mar 13, 2025, at 8:46 PM, Joseph Heenan <joseph at authlete.com> wrote:
> >
> > Hi George
> >
> > As others said, the OP Commands is required to be explicitly typed, at
> least in the current draft.
> >
> > However explicitly typing the OP Command is not sufficient to avoid
> confusion attacks with an id_token, as checking typ is not part of the
> id_token processing rules in Connect Core.
> >
> > Thanks
> >
> > Joseph
> >
> >
> >> On 14 Mar 2025, at 01:57, george--- via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >>
> >> Hi,
> >>
> >> As part of OP Commands, a design goal is to re-use the signing
> mechanisms of the id_tokens in the ecosystem (at least that is my
> understanding). In looking at the OpenID Connect core spec, it’s not very
> clear what should be present in the JWT Header object of a signed (JWS)
> id_token. The examples in the appendix include the ‘kid’ and ‘alg’ claims.
> >>
> >> I’m wondering if it’s possible for the OP Command to be an explicitly
> typed JWT to make it very clear it is NOT an id_token (rather than relying
> on presence or absence of a nonce claim) and still use the same keys for
> signing. It seems to me that the keys used for signing are not in any way
> bound to only being used for id_tokens and hence could be used for other
> JWT based structures.
> >>
> >> That might make some of this simpler and allow OP Commands to be
> extended in a cleaner way than trying to maintain some compatibility to
> id_tokens.
> >>
> >> Thoughts?
> >>
> >> George Fletcher
> >> Identity Standards Architect
> >> Practical Identity LLC
> >>
> >>
> >>
> >> _______________________________________________
> >> Openid-specs-ab mailing list
> >> Openid-specs-ab at lists.openid.net
> >> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250314/e6243d0b/attachment-0001.htm>