Internet DRAFT - draft-schwenkschuster-oauth-identity-chaining

draft-schwenkschuster-oauth-identity-chaining







oauth                                                 A. Schwenkschuster
Internet-Draft                                             P. Kasselmann
Intended status: Informational                                 Microsoft
Expires: 25 April 2024                                         K. Burgin
                                                                        
                                                              M. Jenkins
                                                                NSA-CCSS
                                                             B. Campbell
                                                           Ping Identity
                                                         23 October 2023


                 Identity Chaining across Trust Domains
            draft-schwenkschuster-oauth-identity-chaining-00

Abstract

   This specification defines a mechanism to preserve identity and call
   chain information across trust domains that use the OAuth 2.0
   Framework.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 April 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Schwenkschuster, et al.   Expires 25 April 2024                 [Page 1]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Identity Chaining Across Trust Domains  . . . . . . . . . . .   3
     2.1.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Preserve User Context across Multi-cloud, Multi-Hybrid
               environments  . . . . . . . . . . . . . . . . . . . .   3
       2.1.2.  API Security Use Case . . . . . . . . . . . . . . . .   4
     2.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Authorization Server Discovery  . . . . . . . . . . . . .   6
     2.4.  Token Exchange  . . . . . . . . . . . . . . . . . . . . .   6
       2.4.1.  Request . . . . . . . . . . . . . . . . . . . . . . .   6
       2.4.2.  Processing rules  . . . . . . . . . . . . . . . . . .   7
       2.4.3.  Authorization grant type  . . . . . . . . . . . . . .   7
       2.4.4.  Response  . . . . . . . . . . . . . . . . . . . . . .   7
       2.4.5.  Example . . . . . . . . . . . . . . . . . . . . . . .   8
     2.5.  Authorization Grant . . . . . . . . . . . . . . . . . . .   9
       2.5.1.  Request . . . . . . . . . . . . . . . . . . . . . . .   9
       2.5.2.  Processing rules  . . . . . . . . . . . . . . . . . .  10
       2.5.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  10
       2.5.4.  Example . . . . . . . . . . . . . . . . . . . . . . .  10
     2.6.  Claims transcription  . . . . . . . . . . . . . . . . . .  11
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     4.1.  Client Authentication . . . . . . . . . . . . . . . . . .  12
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  13
     A.1.  Resource server acting as client  . . . . . . . . . . . .  13
     A.2.  Authorization server acting as client . . . . . . . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Applications often require access to resources that are distributed
   across multiple trust domains where each trust domain has its own
   OAuth 2.0 authorization server.  As a result, developers are often
   faced with the situation that a protected resource is located in a
   different trust domain and thus protected by a different
   authorization server.  A request may transverse multiple resource



Schwenkschuster, et al.   Expires 25 April 2024                 [Page 2]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   servers in multiple trust domains before completing.  All protected
   resources involved in such a request need to know on whose behalf the
   request was originally initiated (i.e. the user), what authorization
   was granted and optionally which other resource servers were called
   prior to making an authorization decision.  This information needs to
   be preserved, even when a request crosses one or more trust domains.
   Preserving this information is referred to as identity chaining.
   This document defines a mechanism for preserving identity chaining
   information across trust domains using a combination of OAuth 2.0
   Token Exchange [RFC8693] and Assertion Framework for OAuth 2.0 Client
   Authentication and Authorization Grants [RFC7521].

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Identity Chaining Across Trust Domains

   This specification describes a combination of OAuth 2.0 Token
   Exchange [RFC8693] and Assertion Framework for OAuth 2.0 Client
   Authentication and Authorization Grants [RFC7521] to achieve identity
   chaining across trust domains.

   A client in trust domain A that needs to access a resource server in
   trust domain B requests an authorization grant from the authorization
   server for trust domain A via a token exchange.  The client in trust
   domain A presents the received grant as an assertion to the
   authorization server in domain B in order to obtain an access token
   for the protected resource in domain B.  The client in domain A may
   be a resource server, or it may be the authorization server itself.

2.1.  Use Case

   This section describes two use cases addressed in this specification.

2.1.1.  Preserve User Context across Multi-cloud, Multi-Hybrid
        environments

   A user attempts to access a service that is implemented as a number
   of on-premise and cloud-based microservices.  Both the on-premise and
   cloud-based services are segmented by multiple trust boundaries that
   span one or more on-premise or cloud service environments.  Every
   microservice can apply an authorization policy that takes the context
   of the original user, as well as intermediary microservices into



Schwenkschuster, et al.   Expires 25 April 2024                 [Page 3]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   account, irrespective of where the microservices are running and even
   when a microservice in one trust domain calls another service in
   another trust domain.

2.1.2.  API Security Use Case

   A home devices company provides a “Camera API” to enable access to
   home cameras.  Partner companies use this Camera API to integrate the
   camera feeds into their security dashboards.  Using OAuth between the
   partner and the Camera API, a partner can request the feed from a
   home camera to be displayed in their dashboard.  The user has an
   account with the camera provider.  The user may be logged in to view
   the partner provided dashboard, or they may authorize emergency
   access to the camera.  The home devices company must be able to
   independently verify that the request originated and was authorized
   by a user who is authorized to view the feed of the requested home
   camera.

2.2.  Overview

   The Identity Chaining flow outlined below describes how a combination
   of OAuth 2.0 Token Exchange [RFC8693] and Assertion Framework for
   OAuth 2.0 Client Authentication and Authorization Grants [RFC7521]
   are used to address the use cases identified.  The appendix include
   two additional examples that describe how this flow is used.  In one
   example, the resource server acts as the client and in the other, the
   authorization server acts as the client.
























Schwenkschuster, et al.   Expires 25 April 2024                 [Page 4]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


  +-------------+                            +-------------+ +---------+
  |Authorization|         +--------+         |Authorization| |Protected|
  |Server       |         |Client  |         |Server       | |Resource |
  |Domain A     |         |Domain A|         |Domain B     | |Domain B |
  +-------------+         +--------+         +-------------+ +---------+
         |                    |                     |             |
         |                    |----+                |             |
         |                    |    | (A) discover   |             |
         |                    |<---+ Authorization  |             |
         |                    |      Server         |             |
         |                    |      Domain B       |             |
         |                    |                     |             |
         |                    |                     |             |
         | (B) exchange token |                     |             |
         |   [RFC 8693]       |                     |             |
         |<-------------------|                     |             |
         |                    |                     |             |
         | (C) <authorization |                     |             |
         |       grant>       |                     |             |
         | - - - - - - - - - >|                     |             |
         |                    |                     |             |
         |                    | (D) present         |             |
         |                    | authorization grant |             |
         |                    | [RFC 7521]          |             |
         |                    | ------------------->|             |
         |                    |                     |             |
         |                    | (E) <access token>  |             |
         |                    | <- - - - - - - - - -|             |
         |                    |                     |             |
         |                    |               (F) access          |
         |                    | --------------------------------->|
         |                    |                     |             |
         |                    |                     |             |

                     Figure 1: Identity Chaining Flow

   The flow illustrated in Figure 1 shows the steps the client in trust
   Domain A needs to perform to access a protected resource in trust
   domain B.  In this flow, the client has a way to discover the
   authorization server in Domain B and a trust relationship exists
   between Domain A and Domain B (e.g., through federation).  It
   includes the following:

   *  (A) The client of Domain A needs to discover the authorization
      server of Domain B.  See Authorization Server Discovery
      (Section 2.3).





Schwenkschuster, et al.   Expires 25 April 2024                 [Page 5]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   *  (B) The client exchanges its token at the authorization server of
      its own domain (Domain A) for an authorization grant that can be
      used at the authorization server in Domain B.  See Token Exchange
      (Section 2.4).

   *  (C) The authorization server of Domain A processes the request and
      returns an authorization grant that the client can use with the
      authorization server of Domain B.  This requires a trust
      relationship between Domain A and Domain B (e.g., through
      federation).

   *  (D) The client presents the authorization grant to the
      authorization server of Domain B.  See Authorization Grant
      (Section 2.5).

   *  (E) Authorization server of Domain B validates the authorization
      grant and returns an access token.

   *  (F) The client now possesses an access token to access the
      protected resource in Domain B.

2.3.  Authorization Server Discovery

   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.

2.4.  Token Exchange

   The client performs token exchange as defined in [RFC8693] with the
   authorization server for its own domain (e.g., Domain A) in order to
   obtain an authorization grant that can be used with the authorization
   server of a different domain (e.g., Domain B) as specified in section
   1.3 of [RFC6749].

2.4.1.  Request

   The parameters described in section 2.1 of [RFC8693] apply here with
   the following restrictions:

   requested_token_type
      OPTIONAL according to [RFC8693].  In the context of this
      specification this parameter SHOULD NOT be used.  See
      Authorization grant type (Section 2.4.3).

   scope




Schwenkschuster, et al.   Expires 25 April 2024                 [Page 6]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


      OPTIONAL.  Additional scopes to indicate scopes included in
      returned authorization grant.  See Claims transcription
      (Section 2.6).

   resource
      REQUIRED if audience is not set.  URI of authorization server of
      targeting domain (domain B).

   audience
      REQUIRED if resource is not set.  Well known/logical name of
      authorization server of targeting domain (domain B).

2.4.2.  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 (Section 2.6).

2.4.3.  Authorization grant type

   The authorization grant format and content is part of a contract
   between the authorization servers.  To achieve a maintainable and
   flexible systems clients SHOULD NOT request a specific
   requested_token_type during the token exchange and SHOULD NOT require
   a certain format or parse the authorization grant (e.g., if the token
   is encoded as a JWT).  The issued_token_type parameter in the
   response indicates the type and SHOULD be passed into the assertion
   request.  This allows flexibility for authorization servers to change
   format and content.

   Authorization servers MAY use an existing grant type such us
   urn:ietf:params:oauth:grant-type:jwt-bearer to indicate a JWT or
   urn:ietf:params:oauth:grant-type:saml2-bearer to indicate SAML.
   Other grant types MAY be used to indicate other formats.

2.4.4.  Response

   All of section 2.2 of [RFC8693] applies.  In addition, the following
   applies to implementations that conform to this specification.









Schwenkschuster, et al.   Expires 25 April 2024                 [Page 7]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   *  The "aud" claim in the returned authorization grant MUST identify
      the requested authorization server.  This corresponds with RFC
      7523 Section 3, Point 3 (https://datatracker.ietf.org/doc/html/
      rfc7523#section-3) and is there to reduce missuse and to prevent
      clients from presenting access tokens as an authorization grant to
      an authorization server in a different domain.

   *  The "aud" claim included in the returned authorization grant MAY
      identify multiple authorization servers, provided that trust
      relationships exist with them (e.g. through federation).  It is
      RECOMMENDED that the "aud" claim is restricted to a single
      authorization server to prevent an authorization server in one
      domain from presenting the client's authorization grant to an
      authorization server in a different trust domain.  For example,
      this will prevent the authorization server in Domain B from
      presenting the authorization grant it received from the client in
      Domain A to the authorization server for Domain C.

2.4.5.  Example

   The example belows shows the message invoked by the client in trust
   domain A to perform token exchange with the authorization server in
   domain A (https://as.a.org/auth) to receive an authorization grant
   for the authorization server in trust domain B (https://as.b.org/
   auth).

POST /auth/token HTTP/1.1
Host: as.a.org
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fas.b.org%2Fauth
&subject_token=ey...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

                   Figure 2: Token exchange request















Schwenkschuster, et al.   Expires 25 April 2024                 [Page 8]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-cache, no-store

   {
     "access_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJo
     dHRwczovL2FzLmEub3JnL2F1dGgiLCJleHAiOjE2OTUyODQwOTIsImlhdCI6MTY5N
     TI4NzY5Miwic3ViIjoiam9obl9kb2VAYS5vcmciLCJhdWQiOiJodHRwczovL2FzLm
     Iub3JnL2F1dGgifQ.304Pv9e6PnzcQPzz14z-k2ZyZvDtP5WIRkYPScwdHW4",
     "token_type":"Bearer",
     "expires_in":60
   }

                     Figure 3: Token exchange response

2.5.  Authorization Grant

   The client presents the authorization grant it received from the
   authorization server in its own domain and presents it to the
   authorization server in the domain of the resources server it wants
   to access as defined in the "Assertion Framework for OAuth 2.0 Client
   Authentication and Authorization Grants" [RFC7521].

2.5.1.  Request

   If the authorization grant is in the form of a JWT bearer token, the
   client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0
   Client Authentication and Authorization Grants" as defined in
   [RFC7523].  Otherwise, the client SHOULD request an access token
   using the "Assertion Framework for OAuth 2.0 Client Authentication
   and Authorization Grants" as defined in [RFC7521] (Section 4.1).  For
   the purpose of this specification the following descriptions apply:

   grant_type
      REQUIRED.  In context of this specification clients SHOULD use the
      type identifier returned by the token exchange (issued_token_type
      response).  See authorization grant type (Section 2.4.3) for more
      details.

   assertion
      REQUIRED.  Authorization grant returned by the token exchange
      (access_token response).

   scope
      OPTIONAL.

   The client MAY indicate the audience it is trying to access through
   the scope parameter or the resource parameter defined in [RFC8707].



Schwenkschuster, et al.   Expires 25 April 2024                 [Page 9]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


2.5.2.  Processing rules

   All of Section 5.2 [RFC7521] applies, in addition to the following
   processing rules:

   *  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).

2.5.3.  Response

   The authorization server responds with an access token as described
   in section 5.1 of [RFC6749].

2.5.4.  Example

   The example belows shows how the client in trust domain A presents an
   authorization grant to the authorization server in trust domain B
   (https://as.b.org/auth) to receive an access token for a protected
   resource in trust domain B.

   POST /auth/token HTTP/1.1
   Host: as.b.org
   Content-Type: application/x-www-form-urlencoded

   grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
   &assertion=ey...

                        Figure 4: Assertion request















Schwenkschuster, et al.   Expires 25 April 2024                [Page 10]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-cache, no-store

   {
     "access_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJo
     dHRwczovL2FzLmIub3JnL2F1dGgiLCJleHAiOjE2OTUyODQwOTIsImlhdCI6MTY5N
     TI4NzY5Miwic3ViIjoiam9obi5kb2UuMTIzIiwiYXVkIjoiaHR0cHM6Ly9iLm9yZy
     9hcGkifQ.CJBuv6sr6Snj9in5T8f7g1uB61Ql8btJiR0IXv5oeJg",
     "token_type":"Bearer",
     "expires_in":60
   }

                        Figure 5: Assertion response

2.6.  Claims transcription

   Authorization servers MAY transcribe claims when either producing
   authorization grants in the token exchange flow or access tokens in
   the assertion flow.

   *  *Transcribing the subject identifier*: Subject identifier can
      differ between the parties involved.  For instance: A user is
      known at domain A by "johndoe@a.org" but in domain B by
      "doe.john@b.org".  The mapping from one identifier to the other
      MAY either happen in the token exchange step and the updated
      identifer is reflected in returned authorization grant or in the
      assertion step where the updated identifier would be reflected in
      the access token.  To support this both authorization servers MAY
      add, change or remove claims as described above.

   *  *Selective disclosure*: Authorization servers MAY remove or hide
      certain claims due to privacy requirements or reduced trust
      towards the targeting trust domain.  To hide and enclose claims
      [I-D.ietf-oauth-selective-disclosure-jwt] MAY be used.

   *  *Controlling scope*: Clients MAY use the scope parameter to
      control transcribed claims (e.g. downscoping).  Authorization
      Servers SHOULD verify that requested scopes are not higher
      priveleged than the scopes of presented subject_token.

   *  *Including authorization grant claims*: The authorization server
      performing the assertion flow MAY leverage claims from the
      presented authorization grant and include them in the returned
      access token.  The populated claims SHOULD be namespaced or
      validated to prevent the injection of invalid claims.





Schwenkschuster, et al.   Expires 25 April 2024                [Page 11]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   The representation of transcribed claims and their format is not
   defined in this specification.

3.  IANA Considerations

   To be added.

4.  Security Considerations

4.1.  Client Authentication

   Authorization Servers SHOULD follow the OAuth 2.0 Security Best
   Current Practice [I-D.ietf-oauth-security-topics] for client
   authentication.

5.  References

5.1.  Normative References

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [RFC7521]  Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0 Client Authentication
              and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
              May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.

   [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
              2015, <https://www.rfc-editor.org/rfc/rfc7523>.

   [RFC8707]  Campbell, B., Bradley, J., and H. Tschofenig, "Resource
              Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
              February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/rfc/rfc8414>.





Schwenkschuster, et al.   Expires 25 April 2024                [Page 12]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

5.2.  Informative References

   [I-D.ietf-oauth-selective-disclosure-jwt]
              Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
              Draft, draft-ietf-oauth-selective-disclosure-jwt-05, 30
              June 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-oauth-selective-disclosure-jwt-05>.

   [I-D.ietf-oauth-security-topics]
              Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
              "OAuth 2.0 Security Best Current Practice", Work in
              Progress, Internet-Draft, draft-ietf-oauth-security-
              topics-23, 5 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              security-topics-23>.

   [I-D.ietf-oauth-resource-metadata]
              Jones, M. B., Hunt, P., and A. Parecki, "OAuth 2.0
              Protected Resource Metadata", Work in Progress, Internet-
              Draft, draft-ietf-oauth-resource-metadata-01, 20 October
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              oauth-resource-metadata-01>.

Appendix A.  Examples

   This section contains two examples, demonstrating how this
   specification may be used in different environments with specific
   requirements.  The first example shows the resource server acting as
   the client and the second example shows the authorization server
   acting as the client.

A.1.  Resource server acting as client

   Resources servers may act as clients if the following is true:

   *  Authorization Server B is reachable by the resource server by
      network and is able to perform the appropiate client
      authentication (if required).



Schwenkschuster, et al.   Expires 25 April 2024                [Page 13]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   *  The resource server has the ability to determine the authorization
      server of the protected resource outside its trust domain.

   The flow would look like this:

 +-------------+          +--------+         +-------------+ +---------+
 |Authorization|          |Resource|         |Authorization| |Protected|
 |Server       |          |Server  |         |Server       | |Resource |
 |Domain A     |          |Domain A|         |Domain B     | |Domain B |
 +-------------+          +--------+         +-------------+ +---------+
        |                     |                     |             |
        |                     |   (A) request protected resource  |
        |                     |      metadata                     |
        |                     | --------------------------------->|
        |                     | <- - - - - - - - - - - - - - - - -|
        |                     |                     |             |
        | (C) exchange token  |                     |             |
        |   [RFC 8693]        |                     |             |
        |<--------------------|                     |             |
        |                     |                     |             |
        | (D) <authorization  |                     |             |
        |        grant>       |                     |             |
        | - - - - - - - - - ->|                     |             |
        |                     |                     |             |
        |                     | (E) present         |             |
        |                     |  authorization      |             |
        |                     |  grant [RFC 7521]   |             |
        |                     | ------------------->|             |
        |                     |                     |             |
        |                     | (F) <access token>  |             |
        |                     | <- - - - - - - - - -|             |
        |                     |                     |             |
        |                     |               (G) access          |
        |                     | --------------------------------->|
        |                     |                     |             |
        |                     |                     |             |

               Figure 6: Resource server acting as client

   The flow contains the following steps:











Schwenkschuster, et al.   Expires 25 April 2024                [Page 14]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   (A) The resource server of domain A needs to access protected
   resource in Domain B.  It requires an access token to do so which it
   does not possess.  In this example [I-D.ietf-oauth-resource-metadata]
   is used to receive information about the authorization server which
   protects the resource in domain B.  This step MAY be skipped if
   discovery is not needed and other means of discovery MAY be used.
   The protected resource returns its metadata along with the
   authorization server information.

   (B) Now, after the resource server has identified the authorization
   server for Domain B, the resource server requests an authorization
   grant for the authorization server in Domain B from its own
   authorization server (Domain A).  This happens via the token exchange
   protocol.

   (C) If successful, the authorization server returns an authorization
   grant to the resource server.

   (D) The resource server presents the authorization grant to the
   authorization server of Domain B.

   (E) The authorization server of Domain B uses claims from the
   authorization grant to identify the user and its access.  If access
   is granted an access token is returned.

   (F) The resource server uses the access token to access the protected
   resource at Domain B.

A.2.  Authorization server acting as client

   Authorization servers may act as clients too.  This can be necessary
   because of following reasons:

   *  Resource servers may not have knowledge of authorization servers.

   *  Resource servers may not have network access to other
      authorization servers.

   *  A strict access control on resources outside the trust domain is
      required and enforced by authorization servers.

   *  Authorization servers require client authentication.  Managing
      clients for resource servers outside of the trust domain is not
      intended.

   The flow when authorization servers act as client would look like
   this:




Schwenkschuster, et al.   Expires 25 April 2024                [Page 15]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


 +--------+          +-------------+         +-------------+ +---------+
 |Resource|          |Authorization|         |Authorization| |Protected|
 |Server  |          |Server       |         |Server       | |Resource |
 |Domain A|          |Domain A     |         |Domain B     | |Domain B |
 +--------+          +-------------+         +-------------+ +---------+
     |                      |                       |             |
     | (A) request or       |                       |             |
     | exchange token for   |                       |             |
     | protected resource   |                       |             |
     | in domain B.         |                       |             |
     | -------------------->|                       |             |
     |                      |                       |             |
     |                      |----+                  |             |
     |                      |    | (B) determine    |             |
     |                      |<---+ authorization    |             |
     |                      |      server B         |             |
     |                      |                       |             |
     |                      |                       |             |
     |                      |----+                  |             |
     |                      |    | (C) issue        |             |
     |                      |<---+ authorization    |             |
     |                      |      grant ("internal |             |
     |                      |      token exchange") |             |
     |                      |                       |             |
     |                      |                       |             |
     |                      | (D) present           |             |
     |                      |   authorization grant |             |
     |                      |   [RFC 7521]          |             |
     |                      | --------------------->|             |
     |                      |                       |             |
     |                      | (E) <access token>    |             |
     |                      | <- - - - - - - - - - -|             |
     |                      |                       |             |
     |  (F) <access token>  |                       |             |
     | <- - - - - - - - - - |                       |             |
     |                      |                       |             |
     |                      |           (G) access  |             |
     | ---------------------------------------------------------->|
     |                      |                       |             |
     |                      |                       |             |

            Figure 7: Authorization server acting as client

   The flow contains the following steps:







Schwenkschuster, et al.   Expires 25 April 2024                [Page 16]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   (A) The resource server of Domain A requests a token for the
   protected resource in Domain B from the authorization server in
   Domain A.  This specification does not cover this step.  A profile of
   Token Exchange [RFC8693] may be used.

   (B) The authorization server (of Domain A) determines the
   authorization server (of Domain B).  This could have been passed by
   the client, is statically maintained or dynamically resolved.

   (C) Once the authorization server is determined an authorization
   grant is issued internally.  This reflects to Token exchange
   (Section 2.4) of this specification and can be seen as an "internal
   token exchange".

   (D) The issued authorization grant is presented to the authorization
   server of Domain B.  This presentation happens between the
   authorization servers and authorization server A may be required to
   perform client authentication while doing so.

   (E) The authorization server of Domain B returns an access token for
   access to the protected resource in Domain B to the authorization
   server in Domain A.

   (F) The authorization server of Domain A returns that access token to
   the resource server in Domain A.

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

Acknowledgements

   Joe Jubinski, Justin Richer

Contributors

   Atul Tulshibagwale
   SGNL
   Email: atuls@sgnl.ai


   George Fletcher
   Capital One
   Email: george.fletcher@capitalone.com


   Rifaat Shekh-Yusef
   EY
   Email: rifaat.shekh-yusef@ca.ey.com



Schwenkschuster, et al.   Expires 25 April 2024                [Page 17]

Internet-Draft   Identity Chaining across Trust Domains     October 2023


   Hannes Tschofenig
   Email: hannes.tschofenig@gmx.net


Authors' Addresses

   Arndt Schwenkschuster
   Microsoft
   Email: arndts@microsoft.com


   Pieter Kasselmann
   Microsoft
   Email: pieter.kasselman@microsoft.com


   Kelley Burgin
   Email: kelley.burgin@gmail.com


   Mike Jenkins
   NSA-CCSS
   Email: mjjenki@cyber.nsa.gov


   Brian Campbell
   Ping Identity
   Email: bcampbell@pingidentity.com























Schwenkschuster, et al.   Expires 25 April 2024                [Page 18]