From 1490cc137e1dc1c39940dd58ebce27f5ed6e313c Mon Sep 17 00:00:00 2001 From: Kelley Burgin <59735641+kburgin3@users.noreply.github.com> Date: Fri, 10 Jan 2025 09:13:21 -0500 Subject: [PATCH 1/2] Added delegated key binding Added a section to the examples section in the appendix that describes how to perform delegated key binding when the AS in Domain A is acting as the client. --- draft-ietf-oauth-identity-chaining.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-oauth-identity-chaining.md b/draft-ietf-oauth-identity-chaining.md index 9764465..d31581e 100644 --- a/draft-ietf-oauth-identity-chaining.md +++ b/draft-ietf-oauth-identity-chaining.md @@ -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. + +The case where the Resource Server is acting as the client, this is straight forward. + +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. + # 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. From 198933ffdbe84808ac8289a4e39cb99c05967fd5 Mon Sep 17 00:00:00 2001 From: Kelley Burgin <59735641+kburgin3@users.noreply.github.com> Date: Fri, 10 Jan 2025 10:17:25 -0500 Subject: [PATCH 2/2] Fixed white space error --- draft-ietf-oauth-identity-chaining.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-identity-chaining.md b/draft-ietf-oauth-identity-chaining.md index d31581e..20e51e1 100644 --- a/draft-ietf-oauth-identity-chaining.md +++ b/draft-ietf-oauth-identity-chaining.md @@ -442,7 +442,7 @@ The flow contains the following steps: 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. -The case where the Resource Server is acting as the client, this is straight forward. +The case where the Resource Server is acting as the client, this is straight forward. 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.