[Kelley] add sender constraints #90
Conversation
| This specification does not define authorization server discovery. A client MAY maintain a static mapping or use other means to identify the authorization server. The `authorization_servers` property in {{I-D.ietf-oauth-resource-metadata}} MAY be used. | ||
|
|
||
| ## Sender Constrained Tokens | ||
|
|
||
| The authorization server MAY issue sender constrained tokens. There are currently two options for sender constrained tokens: Mutually Authenticated TLS (mTLS) {{RFC8705}} and Demonstrating Proof of Possessions (DPoP) {{RFC9449}}. |
There was a problem hiding this comment.
Is this in regards to authorization server in Domain A or B or both?
| : REQUIRED if resource is not set. Well known/logical name of authorization server of targeting domain (domain B). | ||
|
|
||
| "chained_id" |
There was a problem hiding this comment.
RFC8693 does not specify a chained_in parameter. Do I understand correctly that this is rather a claim within the JWT assertion used to transfer cnf information from Authorization Server in domain A to Authorization Server in domain B?
There was a problem hiding this comment.
I invented "chained_id" to carry the "cnf" claim. And yes, you understand correctly
There was a problem hiding this comment.
I think I don't understand. This is in a list of token request parameters but is supposed to be a JWT claim?
| @@ -224,6 +238,7 @@ The authorization server MUST validate the JWT authorization grant as specified | |||
| * The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 {{RFC7523}} or the issuer identifier as defined in Section 2 of {{RFC8414}}. | |||
| * The authorization server SHOULD deny the request if it is not able to identify the subject. | |||
| * Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed). | |||
| * If the authorization server issues sender constrained tokens, the authorization server MUST check the binding on inbound assertion of the Access Token Request. Additionally, the authorization server MUST verify the "cnf" claim. | |||
There was a problem hiding this comment.
Does this work if the resource server acts as a client? Thinking out loud:
T0: AS1 issues AT to Alice.
T1: Alice presents AT to R1. R1 needs to call R2 (in domain 2).
T2: performs token exchange to AS1 (fails as AT is bound).
There was a problem hiding this comment.
In the related issue #86 I'd left a comment with a number of things that'd need to be accounted for or a least considered in adding support for sender constraining to this draft, which I don't believe have been addressed in this PR. That aforementioned comment copied below for ease of access.
A rough sketch of things that likely need to be accounted for or a least considered in this effort:
- checking the binding on inbound token of Token Exchange request. No standard defined here. Might not even be feasible or make sense depending on deployment (i.e. the RS acting as the client doesn't have access to the bound key)
- binding the token returned from Token Exchange. The request could be MTLS or have a DPoP header, which is kinda implied per standards. And the returned JWT could be bound with the respective
cnfclaim and method, which is maybe implied by standards but not explicitly written down anywhere (that I know of).- checking the binding on inbound token/assertion of the Access Token Request. The request could be MTLS or have a DPoP header, which is kinda implied per standards but kinda leaves much to the imagination, and checked against the
cnfclaim of the JWT authz grant. The presence of thecnfclaim might be sufficient to say the thing is bound and suggest/require checking it (implementations I know about would just ignore it, however). But maybe a new grant type would make sense to clearly convey the intent (also usingurn:ietf:params:oauth:grant-type:jwt-bearerfor a non-bearer thing is awkward).- binding the resultant access token. The request could be MTLS or have a DPoP header and I think this is covered/implied by the existing specs to say that the issued access token should/could be bound a la DPoP Access Token Request and Mutual-TLS Client Certificate-Bound Access Tokens.
The Authorization server acting as client flips around nearly all of the pieces above to make them unworkable. I guess it'd need separate treatment with the definition of something like a proxied "trust me" this is the cnf I need in the final access token. IIRC Kelley had some prior work toward this end somewhere but I can't seem to find it at the moment. Or maybe sender constraining is just out of scope in the AS as client proxy case.
| ### Processing rules | ||
|
|
||
| * If the request itself is not valid or if the given resource or audience are unknown, or are unacceptable based on policy, the authorization server MUST deny the request. | ||
| * The authorization server MAY add, remove or change claims. See [Claims transcription](#claims-transcription). | ||
| * If the inbound token is sender constrained, the authorization server MUST check the binding on the inbound token. |
There was a problem hiding this comment.
I think this would preclude the RS acting as the client case
No description provided.