update draft name (#76)

* update draft name

closes #67

* Update draft-ietf-oauth-identity-chaining.md

Co-authored-by: Brian Campbell <[email protected]>

* Incorporate Arndt's suggestion into the Introduction

---------

Co-authored-by: Brian Campbell <[email protected]>
Co-authored-by: Brian Campbell <[email protected]>

Author: aaronpk

draft-ietf-oauth-identity-chaining.md

@@ -8,7 +8,7 @@ wg: oauth
 
 docname: draft-ietf-oauth-identity-chaining-latest
 
-title: Identity Chaining across Trust Domains
+title: OAuth Identity and Authorization Chaining Across Domains
 abbrev:
 lang: en
 kw: []
@@ -58,26 +58,26 @@ informative:
 
 --- abstract
 
-This specification defines a mechanism to preserve identity and call chain information across trust domains that use the OAuth 2.0 Framework.
+This specification defines a mechanism to preserve identity information and federate authorization across trust domains that use the OAuth 2.0 Framework.
 
 --- middle
 
 # 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 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 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}}.
+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 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. This document referrers to this as "chaining" and defines a mechanism for preserving identity and authorization information across domains using a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}}.
 
 ## Requirements Language
 
 {::boilerplate bcp14-tagged}
 
-# Identity Chaining Across Trust Domains
+# Identity and Authorization Chaining Across Domains
 
-This specification describes a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} to achieve identity chaining across trust domains.
+This specification describes a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} to achieve identity and authorization chaining across domains.
 
 A client in trust domain A that needs to access a resource server in trust domain B requests a JWT 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.
 
 ## Overview
 
-The Identity Chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} 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.
+The identity and authorization chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange {{RFC8693}} and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants {{RFC7523}} 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.
 
 ~~~~
 +-------------+                            +-------------+ +---------+
@@ -114,7 +114,7 @@ The Identity Chaining flow outlined below describes how a combination of OAuth 2
        |                    |                     |             |
        |                    |                     |             |
 ~~~~
-{: title='Identity Chaining Flow'}
+{: title='Identity and Authorization 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:
 
@@ -445,6 +445,7 @@ The editors would like to thank Joe Jubinski, Justin Richer, Aaron Parecki  and
 * added Aaron Parecki to acknowledgements
 * renamed section headers to be more explicit
 * use more specific term "JWT authorization grant"
+* changed name to "OAuth Identity and Authorization Chaining Across Domains"
 * move use cases to appendix and add continuous integration use case
 
 -00