initial attempt to add DPoP support for ID-JAG #67
Conversation
| } | ||
| } | ||
|
|
||
| 3. The token exchange response does not indicate whether key binding was performed (since `token_type` is fixed to `N_A`). The client must inspect the ID-JAG to determine if a `cnf` claim is present. |
There was a problem hiding this comment.
Open question is whether we should register a new response parameter to indicate to client whether the issued token was a bearer or DPoP? I don't like having the client cracking open the issued token to know this. Since an Authorization Server may ignore the DPoP proof header, I don't think we can leverage an error code.
There was a problem hiding this comment.
Alternatively we can revisit whether N/A was the right choice and have this apply to the issued_token_type even though its not strictly an access token but has the same use case of indicating to the client how the token should be used.
|
@mcguinness can you shed some light into the decision process for using |
Based it on https://datatracker.ietf.org/doc/html/draft-parecki-oauth-jwt-dpop-grant-00. I can make that clearer that this it inheriting the processing rules. I know you raised this question on the mailing list and was going to use whatever approach had consensus. |
|
Ah, I still need to write up my feedback for that particular draft then. Thanks. |
|
@panva Should this draft accept either jwk or jwt in the proof with the Token Exchange request? @aaronpk draft only specifies ID-JAG processing part of the flow for the Resource AS. The IdP Authorization Server would need to convert a jkt to jwk confirmation. The Token Exchange processing rules will also get more complicated when I add support for https://openid.net/specs/openid-connect-key-binding-1_0-00.html. I was hoping to break that into its own PR after we got this merged. |
This PR attempts to resolve #28 by adding processing rules for DPoP to security considerations