Added delegated key binding

[kburgin3]

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.

[gffletch]

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

[PieterKas]

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)

[gffletch]

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 :)

[PieterKas]

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.

[PieterKas]

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.