Specify a dedicated DPoP-bound ID Token

[JonasPrimbs]

I really appreciate the draft, because it is a solution for many of my use cases.

However, I'm not sure whether it is a good idea to mix the DPoP binding into the ID token for the following reasons:

1. Privacy: Depending on the OP, multiple user-specific claims (e.g., sub, name, ...) might be placed inside the ID Token without the client being able to control them via requested scopes. When sharing this token with other users or services, it may leak internal information (e.g., sub identifier) or personal information to third-party RPs that the user is willing to disclose only to their local RP (e.g., name, gender, ...).
2. Dual Use: Many RPs may still need a classic ID Token in addition to the DPoP-bound ID Token. I can also assume that the claims of the classic ID Token should not be equal to the claims of the DPoP-bound ID Token, e.g., a classic ID Token with name and email claim to display these information in the UI to the user, but sharing only the name claim with a consuming RP (e.g., a video conference communication partner) via the DPoP-bound ID Token.

Therefore, my recommendation is that if the bound_key scope is requested and granted, an additional token will be returned in the token request, e.g., something like dpop_id_token.
In addition, claims of this ID Token should be a subset of the classic ID Token, which can be reduced by the end-user (who is required to consent to the AS explicitly, allowing this information to be shared with third parties) and the relying party (which can further reduce the requested claims for data minimization).

[dickhardt]

I don't think the complexity is warranted. If an RP needs ID Tokens with different claims, including the cnf claim, it can make two requests. Per the spec, the ID Token should only be presented to other components of the RP -- it should not be shared with third-party RPs.

[JonasPrimbs]

Yes, that's exactly why this DPoP ID Token should be a dedicated token with the purpose of presenting it to third parties outside the RP. This would highly increase the applicability.

For example, in the described video conferencing use case, this ID token does not hold high value if it is shared only with other RP components within the user's video conferencing client. It would be much better if the ID token could be shared with conversation partners and combined with a DPoP proof so that other participants of the video call can verify the user's OIDC identity.