diff --git a/draft-jones-oauth-rfc7523bis.xml b/draft-jones-oauth-rfc7523bis.xml
new file mode 100644
index 0000000..8b4d3b5
--- /dev/null
+++ b/draft-jones-oauth-rfc7523bis.xml
@@ -0,0 +1,697 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
+
+
+ Microsoft
+
+ mbj@microsoft.com
+ http://self-issued.info/
+
+
+
+
+ Ping Identity
+
+ brian.d.campbell@gmail.com
+
+
+
+
+ Salesforce
+
+ cmortimore@salesforce.com
+
+
+
+
+
+ Security
+ OAuth Working Group
+
+ OAuth
+ JWT
+ Assertion
+ Token
+ Security Token
+
+
+ This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for
+ requesting an OAuth 2.0 access token as well as for client authentication.
+
+
+
+
+
+
+
+ JSON Web Token (JWT)
+ is a JSON-based security token encoding
+ that enables
+ identity and security information to be shared across security
+ domains.
+ A security token is generally issued by an Identity Provider
+ and consumed by a Relying Party that relies on its content to
+ identify the token's subject for security-related purposes.
+
+
+
+ The OAuth 2.0 Authorization Framework provides
+ a method for making authenticated HTTP requests to a resource using an access token.
+ Access tokens are issued to third-party clients by an
+ authorization server (AS) with the (sometimes implicit) approval of the resource owner.
+ In OAuth, an authorization grant is an abstract term used to describe
+ intermediate credentials that represent the resource owner
+ authorization. An authorization grant is used by the client to obtain an access token.
+ Several authorization grant types are defined to support a wide range
+ of client types and user experiences.
+ OAuth also allows for the definition of new extension grant types
+ to support additional clients or to provide a bridge between OAuth and other trust frameworks.
+ Finally, OAuth allows the definition of additional authentication mechanisms to be used by clients when interacting with the authorization server.
+
+
+
+ "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants"
+
+ is an abstract extension to OAuth 2.0 that provides a general
+ framework for the use of assertions (a.k.a. security tokens) as client credentials and/or authorization grants with OAuth 2.0.
+ This specification profiles
+ the OAuth Assertion Framework
+
+ to define an extension grant type that uses a JWT Bearer Token to
+ request an OAuth 2.0 access token as well as for use as client credentials.
+ The format and processing rules for the JWT defined in this specification are intentionally similar,
+ though not identical, to those in the closely related specification "Security
+ Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication
+ and Authorization Grants"
+ .
+ The differences arise where the structure and semantics of JWTs differ from SAML Assertions.
+ JWTs, for example, have no direct equivalent to the <SubjectConfirmation> or <AuthnStatement> elements of SAML Assertions.
+
+
+ This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust
+ relationship, expressed through the semantics of
+ the JWT,
+ without a direct user-approval step at the authorization server. It also defines how a JWT can be used as a client authentication mechanism.
+ The use of a security token for client
+ authentication is orthogonal to and separable from using a security token as an
+ authorization grant. They can be used either in combination or separately.
+ Client authentication using a JWT is nothing more than an alternative way for a client to authenticate
+ to the token endpoint and must be used in conjunction with some grant type to form a complete and
+ meaningful protocol request. JWT authorization grants may be used with or without client authentication
+ or identification. Whether or not client authentication is needed in conjunction with a JWT authorization
+ grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.
+
+ The process by which the client obtains the JWT, prior to exchanging it with the authorization server or using it for client authentication, is out of scope.
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 .
+
+
+ Unless otherwise noted, all the protocol parameter names and values are case sensitive.
+
+
+
+
+
+ All terms are as defined in the following specifications:
+ "The OAuth 2.0 Authorization Framework" ,
+ the OAuth Assertion Framework
+ , and "JSON Web Token (JWT)" .
+
+
+
+
+
+
+
+ The OAuth Assertion Framework
+
+ defines generic HTTP parameters for transporting assertions (a.k.a. security tokens)
+ during interactions with a token endpoint.
+ This section defines specific parameters and treatments of those parameters
+ for use with JWT Bearer Tokens.
+
+
+
+ To use a Bearer JWT as an authorization grant, the client uses an access token request as defined in
+ Section 4 of
+ the OAuth Assertion Framework
+
+ with the following specific parameter values and encodings.
+
+ The value of the grant_type is
+ urn:ietf:params:oauth:grant-type:jwt-bearer.
+
+ The value of the assertion parameter
+ MUST contain a single JWT.
+
+
+ The scope parameter may be used, as defined in
+ the OAuth Assertion Framework
+ , to indicate the requested scope.
+
+ Authentication of the client is optional, as described in
+ Section 3.2.1 of OAuth 2.0 and
+ consequently, the client_id is only needed
+ when a form of client authentication that relies on the parameter is used.
+ The following example demonstrates an access token request with a JWT as an authorization grant
+ (with extra line breaks for display purposes only):
+
+
+
+
+
+
+
+ To use a JWT Bearer Token for client authentication, the client uses the following parameter values and encodings.
+ The value of the client_assertion_type is
+ urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
+
+ The value of the client_assertion parameter
+ contains a single JWT. It MUST NOT contain more than one JWT.
+
+
+ The following example demonstrates client
+ authentication using a JWT during the presentation of an authorization code grant in an
+ access token request
+ (with extra line breaks for display purposes only):
+
+
+
+
+
+
+
+
+
+
+ In order to issue an access token response as described in
+ OAuth 2.0
+ or to rely on a JWT for client authentication,
+ the authorization server MUST validate the JWT according to the criteria below.
+ Application of additional restrictions and policy are at the discretion of the authorization server.
+
+
+
+
+
+ The JWT MUST contain an iss
+ (issuer) claim that contains a unique identifier for the
+ entity that issued the JWT.
+ In the absence of an application profile specifying
+ otherwise, compliant applications MUST compare issuer
+ values using the Simple String Comparison method defined in Section
+ 6.2.1 of RFC 3986 .
+
+
+ The JWT MUST contain a sub
+ (subject) claim identifying the
+ principal that is the subject of the JWT. Two cases need to
+ be differentiated:
+
+ For the authorization grant, the subject typically identifies an authorized accessor for which the
+ access token is being requested (i.e., the resource owner or an authorized delegate), but
+ in some cases, may be a pseudonymous identifier or other value denoting an anonymous user.
+
+
+ For client authentication, the subject MUST be the
+ client_id of the OAuth client.
+
+
+
+
+ The JWT MUST contain an aud
+ (audience) claim containing a value that
+ identifies the authorization server as an intended audience.
+ The token endpoint URL of the authorization server MAY be used as a
+ value for an aud element to identify
+ the authorization server as an intended audience of the JWT.
+ The authorization server MUST reject any JWT that does not
+ contain its own identity as the intended audience.
+ In the absence of an application profile specifying
+ otherwise, compliant applications MUST compare the audience
+ values using the Simple String Comparison method defined in Section
+ 6.2.1 of RFC 3986 .
+ As noted in , the precise strings to be used
+ as the audience for a given authorization server must be configured out of band
+ by the authorization server and the issuer of the JWT.
+
+
+ The JWT MUST contain an exp
+ (expiration time) claim that limits the time window during
+ which the JWT can be used. The authorization server
+ MUST reject any JWT with an expiration time that has passed,
+ subject to allowable clock skew between systems.
+ Note that the
+ authorization server may reject JWTs with an exp claim value that is
+ unreasonably far in the future.
+
+
+ The JWT MAY contain an nbf
+ (not before) claim that identifies the time before which
+ the token MUST NOT be accepted for processing.
+
+
+ The JWT MAY contain an iat
+ (issued at) claim that identifies the time at which the
+ JWT was issued. Note that the authorization server may reject JWTs
+ with an iat claim value that is
+ unreasonably far in the past.
+
+
+ The JWT MAY contain a jti
+ (JWT ID) claim that provides a unique identifier for
+ the token.
+ The authorization server MAY ensure that JWTs are not
+ replayed by maintaining the set of used
+ jti values for the length of
+ time for which the JWT would be considered valid based
+ on the applicable exp instant.
+
+
+
+ The JWT MAY contain other claims.
+
+
+ The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied
+ by the issuer. The authorization server
+ MUST reject JWTs with an invalid signature or MAC.
+
+
+ The authorization server MUST reject a JWT that is not
+ valid in all other respects per
+ "JSON Web Token (JWT)" .
+
+
+
+
+
+
+
+ JWT authorization grants may be used with or without client authentication
+ or identification. Whether or not client authentication is needed in
+ conjunction with a JWT authorization grant, as well as the supported types
+ of client authentication, are policy decisions at the discretion of the
+ authorization server. However, if client credentials are present in
+ the request, the authorization server MUST validate them.
+
+
+ If the JWT is not valid, or the current time is not within the token's valid time window for use, the
+ authorization server constructs an error response as defined in
+ OAuth 2.0 .
+ The value of the error parameter MUST be the
+ invalid_grant error code. The authorization server
+ MAY include additional information regarding the reasons the JWT was considered invalid using the
+ error_description or error_uri parameters.
+
+ For example:
+
+
+
+
+
+
+
+ If the client JWT is not valid, the
+ authorization server constructs an error response as defined in
+ OAuth 2.0 .
+ The value of the error parameter MUST be the
+ invalid_client error code. The authorization server
+ MAY include additional information regarding the reasons the JWT was considered invalid using the
+ error_description or error_uri parameters.
+
+
+
+
+
+ The following examples illustrate what a conforming JWT and an access token request would look like.
+
+
+ The example shows a JWT issued and signed by the system entity identified as
+ https://jwt-idp.example.com.
+ The subject of the JWT is identified by email address as mike@example.com.
+ The intended audience of the JWT is https://jwt-rp.example.net,
+ which is an identifier with which the authorization server identifies itself.
+ The JWT is sent as part of an access token request to the authorization server's
+ token endpoint at https://authz.example.net/token.oauth2.
+
+
+
+ Below is an example JSON object that could be encoded to
+ produce the JWT Claims Set for a JWT:
+
+
+
+
+
+
+ The following example JSON object, used as the header of a
+ JWT, declares that the JWT is signed with the Elliptic Curve
+ Digital Signature Algorithm (ECDSA) P-256
+ SHA-256 using a key identified by the kid value 16.
+
+
+
+
+
+
+ To present the JWT with the claims and header shown in the previous example as part of an access token request, for example,
+ the client might make the following HTTPS request
+ (with extra line breaks for display purposes only):
+
+
+
+
+
+
+
+
+ Agreement between system entities regarding identifiers,
+ keys, and endpoints is required in order to achieve interoperable
+ deployments of this profile. Specific items that require agreement are as follows:
+ values for the issuer and audience identifiers, the location of the token endpoint, the key used to
+ apply and verify the digital signature or MAC over the JWT, one-time use restrictions on the JWT,
+ maximum JWT lifetime allowed, and the specific subject and claim requirements of the JWT.
+ The exchange of such information is explicitly out of scope for this specification.
+ In some cases, additional profiles may be created that constrain or prescribe these values or specify
+ how they are to be exchanged.
+ Examples of such profiles include
+ the OAuth 2.0 Dynamic Client Registration Core Protocol ,
+ OpenID Connect Dynamic Client Registration 1.0 ,
+ and OpenID Connect Discovery 1.0 .
+
+
+ The RS256 algorithm, from , is a mandatory-to-implement JSON Web
+ Signature algorithm for this profile.
+
+
+
+
+
+
+
+ The security considerations described within the following specifications are all applicable
+ to this document:
+ "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants"
+ ,
+ "The OAuth 2.0 Authorization Framework" , and "JSON Web Token (JWT)" .
+
+
+ The specification does not mandate replay protection for the JWT
+ usage for either the authorization grant or for client
+ authentication. It is an optional feature, which implementations may employ at their own discretion.
+
+
+
+
+
+
+ A JWT may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties,
+ should only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure
+ of certain information to the client, the JWT should be encrypted to the authorization server.
+
+
+ Deployments should determine the minimum amount of information necessary to complete the exchange and include
+ only such claims in the JWT. In some cases, the sub (subject) claim can be a value representing an anonymous
+ or pseudonymous user, as described in Section 6.3.1 of
+ the OAuth Assertion Framework
+ .
+
+
+
+
+
+ This section registers the value
+ grant-type:jwt-bearer in the
+ IANA "OAuth URI" registry established by
+ "An IETF URN Sub-Namespace for OAuth" .
+
+
+ URN: urn:ietf:params:oauth:grant-type:jwt-bearer
+ Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0
+ Change Controller: IESG
+ Specification Document: RFC 7523
+
+
+
+
+
+ This section registers the value
+ client-assertion-type:jwt-bearer in the
+ IANA "OAuth URI" registry established by
+ "An IETF URN Sub-Namespace for OAuth" .
+
+
+ URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
+ Common Name: JWT Bearer Token Profile for OAuth 2.0 Client Authentication
+ Change Controller: IESG
+ Specification Document: RFC 7523
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ JSON Web Algorithms (JWA)
+
+ Microsoft
+
+ mbj@microsoft.com
+ http://self-issued.info/
+
+
+
+
+
+
+
+
+
+
+ Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
+
+ Ping Identity
+
+
+ Salesforce.com
+
+
+ Microsoft
+
+
+ Microsoft
+
+
+
+
+
+
+
+
+
+ JSON Web Token (JWT)
+
+ Microsoft
+
+ mbj@microsoft.com
+ http://self-issued.info/
+
+
+
+ Ping Identity
+
+ ve7jtb@ve7jtb.com
+
+
+
+ Nomura Research Institute
+
+ n-sakimura@nri.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+OAuth 2.0 Dynamic Client Registration Protocol
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Security Assertion
+ Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
+
+ Ping Identity
+
+
+ Salesforce.com
+
+
+ Microsoft
+
+
+
+
+
+
+
+
+ OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1
+
+ Nomura Research Institute, Ltd.
+
+
+ Ping Identity
+
+
+ Microsoft
+
+
+
+
+
+
+
+ OpenID Connect Discovery 1.0 incorporating errata set 1
+
+ Nomura Research Institute, Ltd.
+
+
+ Ping Identity
+
+
+ Microsoft
+
+
+ Illumila
+
+
+
+
+
+
+
+
+
+ This profile was derived from
+ "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants"
+ ,
+ which has the same authors as this document.
+
+
+
+
diff --git a/draft-todo-yourname-protocol.md b/draft-todo-yourname-protocol.md
deleted file mode 100644
index fa51372..0000000
--- a/draft-todo-yourname-protocol.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-###
-# Internet-Draft Markdown Template
-#
-# Rename this file from draft-todo-yourname-protocol.md to get started.
-# Draft name format is "draft---.md".
-#
-# For initial setup, you only need to edit the first block of fields.
-# Only "title" needs to be changed; delete "abbrev" if your title is short.
-# Any other content can be edited, but be careful not to introduce errors.
-# Some fields will be set automatically during setup if they are unchanged.
-#
-# Don't include "-00" or "-latest" in the filename.
-# Labels in the form draft----latest are used by
-# the tools to refer to the current version; see "docname" for example.
-#
-# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
-# You can replace the entire file if you prefer a different format.
-# Change the file extension to match the format (.xml for XML, etc...)
-#
-###
-title: "TODO - Your title"
-abbrev: "TODO - Abbreviation"
-category: info
-
-docname: draft-todo-yourname-protocol-latest
-submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF"
-number:
-date:
-consensus: true
-v: 3
-area: AREA
-workgroup: WG Working Group
-keyword:
- - next generation
- - unicorn
- - sparkling distributed ledger
-venue:
- group: WG
- type: Working Group
- mail: WG@example.com
- arch: https://example.com/WG
- github: USER/REPO
- latest: https://example.com/LATEST
-
-author:
- -
- fullname: Your Name Here
- organization: Your Organization Here
- email: your.email@example.com
-
-normative:
-
-informative:
-
-
---- abstract
-
-TODO Abstract
-
-
---- middle
-
-# Introduction
-
-TODO Introduction
-
-
-# Conventions and Definitions
-
-{::boilerplate bcp14-tagged}
-
-
-# Security Considerations
-
-TODO Security
-
-
-# IANA Considerations
-
-This document has no IANA actions.
-
-
---- back
-
-# Acknowledgments
-{:numbered="false"}
-
-TODO acknowledge.