diff --git a/draft-bradley-stateless-oauth-client.xml b/draft-bradley-stateless-oauth-client.xml index e01609b..c52fdd0 100644 --- a/draft-bradley-stateless-oauth-client.xml +++ b/draft-bradley-stateless-oauth-client.xml @@ -1,186 +1,186 @@ - - - - - - - - - - - - - - - Stateless Client Identifier for OAuth - 2 - - - - -
- - - - - -
- - - - - - - - - - - - - - - - - - - -
- - - - - - This draft provides a method for communicating information about an - OAuth client through its client identifier allowing for fully stateless - operation. - - - - 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. - - - - -
- In the OAuth 2.0 Authorization protocol, the Client must provide a - Client Identifier that the Authorization Server recognizes. - Additionally, an Autorization Server needs to know about a client's - details, such as its name and redirect URIs. Traditionally, this is - handled through a registration process, which may be either manual or - automated, where the authorization server maintains a stateful - relationship between the Client Identifier and its associated metadata. - This draft proposes a mechanism whereby the essential metadata can be - encoded into the Client Identifier itself, signed by the issuer, and - validated by the authorization server, thus allowing the authorization - server to be stateless in regard to client information. -
- -
- The stateless client identifier consists of a [JWT], optionally - signed with [JWS], whose payload contains claims as defined here. - - - REQUIRED. URL identifying the party that issued - this client identifier. - - REQUIRED. Identifier of the client, locally unique - to the issuer. - - OPTIONAL. Timestamp of when this client identifier - was issued. - - OPTIONAL. Timestamp of when this client identifier - will expire. - - RECOMMENDED if signed. Identifier of the key used - to sign this client identifier at the issuer. - - REQUIRED. JSON Object containing a set of metadata - claims of client information such as its redirect URIs, display - name, and other items as defined in [Dyn Reg] and its - extensions. - - - The issuer SHOULD sign the JWT with JWS in such a way that the - signature can be verified by the authorization server. - - The issuer MAY encrypt the JWT with JWE. -
- -
- Upon receiving a stateless client identifier at either the - authorization endpoint or the token endpoint, the authorization server - parses it as a JWT. It first checks the iss field to determine if it - trusts identifiers issued by the party represented. It then verifies the - signature if the JWT (if signed) using JWS. The key used to sign the JWT - MAY be indicated by the kid field. The authorization server MAY use - other means to validate the JWT and determine its authenticity. - - The authorization server then reads the fields inside the reg claim - and uses these to configure the user experience and security parameters - of the authorization. -
- -
- The client identifier is intended to be opaque to the client, and as - such a stateless client identifier is intended to be obtained and used - in exactly the same way as a stateful client identifer would be for any - OAuth client. - - - Manual registration: a developer uses an out-of-band - adminstrative process to generate the client identifier and related - credentials. - - Dynamic registration: a developer or client uses the process - described in [Dyn Reg] to generate the client identifier and related - credentials. - - Self assertion: a developer or client generates the client - identifier on their own, often signing it with their own public - key. - - - It is completely up to the purview of particular authorization - servers which generation methods, and which client identifiers, they - will accept. -
- -
- [ maybe we register the "reg" claim above? ] - - This document makes no request of IANA. - - Note to RFC Editor: this section may be removed on publication as an - RFC. -
- -
- Since many OAuth systems assume that a change in the client - identifier indicates a change in the client itself, systems using - stateless client identifiers SHOULD NOT allow clients to update their - information post registration. - - Since the client identifier is passed through the browser to the - authorization endpoint, it MUST NOT contain any sensitive information. - Additionally, as in standard OAuth, posession of the client identifier - itself MUST NOT be assumed to be sufficient authentication [in many - cases? except implicit mode?]. -
- -
- -
- - - - - - - - + + + + + + + + + + + + + + + Stateless Client Identifier for OAuth + 2 + + + + +
+ + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ + + + + + This draft provides a method for communicating information about an + OAuth client through its client identifier allowing for fully stateless + operation. + + + + 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. + + + + +
+ In the OAuth 2.0 Authorization protocol, the Client must provide a + Client Identifier that the Authorization Server recognizes. + Additionally, an Autorization Server needs to know about a client's + details, such as its name and redirect URIs. Traditionally, this is + handled through a registration process, which may be either manual or + automated, where the authorization server maintains a stateful + relationship between the Client Identifier and its associated metadata. + This draft proposes a mechanism whereby the essential metadata can be + encoded into the Client Identifier itself, signed by the issuer, and + validated by the authorization server, thus allowing the authorization + server to be stateless in regard to client information. +
+ +
+ The stateless client identifier consists of a [JWT], optionally + signed with [JWS], whose payload contains claims as defined here. + + + REQUIRED. URL identifying the party that issued + this client identifier. + + REQUIRED. Identifier of the client, locally unique + to the issuer. + + OPTIONAL. Timestamp of when this client identifier + was issued. + + OPTIONAL. Timestamp of when this client identifier + will expire. + + RECOMMENDED if signed. Identifier of the key used + to sign this client identifier at the issuer. + + REQUIRED. JSON Object containing a set of metadata + claims of client information such as its redirect URIs, display + name, and other items as defined in [Dyn Reg] and its + extensions. + + + The issuer SHOULD sign the JWT with JWS in such a way that the + signature can be verified by the authorization server. + + The issuer MAY encrypt the JWT with JWE. +
+ +
+ Upon receiving a stateless client identifier at either the + authorization endpoint or the token endpoint, the authorization server + parses it as a JWT. It first checks the iss field to determine if it + trusts identifiers issued by the party represented. It then verifies the + signature if the JWT (if signed) using JWS. The key used to sign the JWT + MAY be indicated by the kid field. The authorization server MAY use + other means to validate the JWT and determine its authenticity. + + The authorization server then reads the fields inside the reg claim + and uses these to configure the user experience and security parameters + of the authorization. +
+ +
+ The client identifier is intended to be opaque to the client, and as + such a stateless client identifier is intended to be obtained and used + in exactly the same way as a stateful client identifer would be for any + OAuth client. + + + Manual registration: a developer uses an out-of-band + adminstrative process to generate the client identifier and related + credentials. + + Dynamic registration: a developer or client uses the process + described in [Dyn Reg] to generate the client identifier and related + credentials. + + Self assertion: a developer or client generates the client + identifier on their own, often signing it with their own public + key. + + + It is completely up to the purview of particular authorization + servers which generation methods, and which client identifiers, they + will accept. +
+ +
+ [ maybe we register the "reg" claim above? ] + + This document makes no request of IANA. + + Note to RFC Editor: this section may be removed on publication as an + RFC. +
+ +
+ Since many OAuth systems assume that a change in the client + identifier indicates a change in the client itself, systems using + stateless client identifiers SHOULD NOT allow clients to update their + information post registration. + + Since the client identifier is passed through the browser to the + authorization endpoint, it MUST NOT contain any sensitive information. + Additionally, as in standard OAuth, posession of the client identifier + itself MUST NOT be assumed to be sufficient authentication [in many + cases? except implicit mode?]. +
+ +
+ +
+ + + + + + + +