Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added delegated key binding #124

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Added delegated key binding #124

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1490cc1
Added delegated key binding
kburgin3 Jan 10, 2025
198933f
Fixed white space error
kburgin3 Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions draft-ietf-oauth-identity-chaining.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -438,6 +438,14 @@ The flow contains the following steps:

(G) The client in Domain A uses the received access token to access the protected resource in Domain B.

## Delegated Key Binding

In some environments, there is a need to bind the final access token to a private key held by the Resource Server in Domain A. This is so that the Resource Server in Domain B can verify the proof of possession of the private key of the Resource Server in Domain A on the final access token when the Resource Server in Domain A presents the token to the Resource Server in Domain B.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some environments, there is a need to bind the final access token to a private key held by the Resource Server in Domain A. This is so that the Resource Server in Domain B can verify the proof of possession of the private key of the Resource Server in Domain A. The proof of possession is sent when the Resource Server in Domain A makes a request of the Resource Server in Domain B using the issued access token.

I'm not sure that's better but maybe it will be useful :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of observations:

  1. instead of "final token" be explicit that this is the access token issued by the authorization server in Domain B.
  2. instead of the resource server sending the token, talk about the resource server acting as a client in domain B. alternatively talk about the application that is acting as a resource server, or as a client.

Some suggestions below:

In some environments, there is a need to bind the access token issued by the authorization server in Domain B to a private key held by the Resource Server in Domain A. This is so that the Resource Server in Domain B can verify the proof of possession of the private key of the client in Domain A when the client in Domain A presents the token to the Resource Server in Domain B. Any application in Domain A may act as a client, including applications that are resource servers in Domain A and need to access resource servers in Domain B in order to complete a request.


The case where the Resource Server is acting as the client, this is straight forward.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change to "For the case..." or "In the case..."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case where the Resource Server is acting as the client, the access token may be constrained using existing techniques as described in Security Considerations (add reference once it is merged)


However, the case where the Authorization Server is acting as a client is more complicated, but can be accomplished as follows. The Authorization Server in Domain A includes the "cnf" claim of the Resource Server in Domain A in the token request sent to the Authorization Server in Domain B. This can, for example, be accomplished by including a "requested_cnf" claim, that contains the "cnf" claim of the Resource Server in Domain A, in the assertion authorization grant sent to the Authorization Server in Domain B The Authorization Server in Domain B then includes the requested "cnf" claim of the Resource Server in Domain A in the returned, final access token.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case where the Authorization Server is acting as a client is more complicated since the authorisation server in domain A acting as client does not have access to the key material of the client on whose behalf the access token is being requested.

However, the trust relationship between the authorisation server in domain A and the authorization server in domain B can be leveraged to sender constrain the access token issued by the authorisation server in domain B. This can be achieved as follows. The Authorization Server in Domain A verifies proof of posession of the key presented by the client. It then includes the "cnf" claim of the client in Domain A in the token request sent to the Authorization Server in Domain B. This can, for example, be accomplished by including a "requested_cnf" claim, that contains the "cnf" claim of the Resource Server in Domain A, in the assertion authorization grant sent to the Authorization Server in Domain B The Authorization Server in Domain B then includes a "cnf" claim that matches the value of the "requested_cnf" claim in the authorization grant in the returned access token. The client in domain A that presents the access token must use the key matching the "cnf" claim to generate a DPoP proof or setup a MTLS session when presenting the access token to a resource server in Domain B.


# Acknowledgements {#Acknowledgements}
The editors would like to thank Joe Jubinski, Justin Richer, Aaron Parecki, Dean H. Saxe, and others (please let us know, if you've been mistakenly omitted) for their valuable input, feedback and general support of this work.

Expand Down
Loading