From 8f917bb2130c371707f002c19c8f0796ec48a943 Mon Sep 17 00:00:00 2001 From: Justin Richer Date: Thu, 2 Jul 2015 16:49:10 -0400 Subject: [PATCH] incorporated another round of RFC editor edits --- rfc7591.xml | 159 ++++++++++++++++++++++++++-------------------------- rfc7592.xml | 39 +++++-------- 2 files changed, 94 insertions(+), 104 deletions(-) diff --git a/rfc7591.xml b/rfc7591.xml index 3abbab3..133ffa4 100644 --- a/rfc7591.xml +++ b/rfc7591.xml @@ -66,9 +66,13 @@ OAuth Working Group - +Dynamic Registration +Dynamic Client Registration OpenID Connect OpenID Connect Dynamic Client Registration +OIDC +User Managed Access +UMA This specification defines mechanisms for dynamically registering @@ -232,15 +236,12 @@ | Developer |<-(D)- Client Information Response ---| Endpoint | | | or Client Error Response +---------------+ +-----------+ - ]]> Figure 1: Abstract Dynamic Client Registration Flow - - The abstract OAuth 2.0 client dynamic registration flow illustrated in Figure 1 describes the interaction between the client or developer and the endpoint defined in this specification. This figure does not @@ -323,8 +324,8 @@ client_secret_basic: The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1. - Additional values can be defined via the IANA OAuth Token - Endpoint Authentication Methods Registry established in Additional values can be defined via the IANA "OAuth Token + Endpoint Authentication Methods" registry established in . Absolute URIs can also be used as values for this parameter without being registered. If unspecified or omitted, the default is client_secret_basic, @@ -336,20 +337,20 @@ types are defined as follows: authorization_code: The - authorization code grant type described in OAuth 2.0, Section 4.1. + authorization code grant type defined in OAuth 2.0, Section 4.1. implicit: The implicit grant type - described in OAuth 2.0, Section 4.2. + defined in OAuth 2.0, Section 4.2. password: The resource owner - password credentials grant type described in OAuth 2.0, Section + password credentials grant type defined in OAuth 2.0, Section 4.3. client_credentials: The client - credentials grant type described in OAuth 2.0, Section 4.4. + credentials grant type defined in OAuth 2.0, Section 4.4. refresh_token: The refresh token - grant type described in OAuth 2.0, Section 6. + grant type defined in OAuth 2.0, Section 6. urn:ietf:params:oauth:grant-type:jwt-bearer: The JWT Bearer Token Grant Type defined in OAuth JWT @@ -373,10 +374,10 @@ endpoint. These response types are defined as follows: code: The authorization code - response described in OAuth 2.0, Section 4.1. + response type defined in OAuth 2.0, Section 4.1. - token: The implicit response - described in OAuth 2.0, Section 4.2. + token: The implicit response type + defined in OAuth 2.0, Section 4.2. If the authorization endpoint is used by the grant type, the value of this parameter MUST be the same as the value of the response_type parameter passed to the @@ -457,7 +458,7 @@ Client's JSON Web Key Set document value, which contains the client's public keys. The value of this field MUST be a JSON object - containing a valid JWK Set. These keys can be used by higher-level + containing a valid JWK Set. These keys can be used by higher-level protocols that use signing or encryption. This parameter is intended to be used by clients that cannot use the jwks_uri parameter, such as native clients that cannot host public URLs. The @@ -593,7 +594,7 @@ target="RFC7159">JSON member names are case sensitive, it is RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the IANA Language Subtag Registry. In + target="IANA.Language">"IANA Language Subtag" registry. In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and languages are spelled with mixed-case characters. However, since BCP 47 @@ -677,36 +678,34 @@ NEW: claims:
- +
- - - The following non-normative example JWT includes these claims and - has been asymmetrically signed using RS256: -
- (Line breaks are for display purposes only) + The following non-normative example JWT includes these claims and + has been asymmetrically signed using RS256 + (with line breaks for display purposes only): -
- - The software statement is typically distributed with all instances of a client application. The means by which a client or developer obtains a software statement are outside the scope of this @@ -734,7 +733,8 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA the authorization server. The client registration endpoint MUST accept HTTP POST messages with request parameters encoded in the entity body using the application/json format. The - client registration endpoint MUST be protected by a tranport-layer security mechanism, as described in . + client registration endpoint MUST be protected by a transport-layer + security mechanism, as described in . The client registration endpoint MAY be an OAuth 2.0 protected @@ -776,8 +776,7 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
The following is a non-normative example request not using - an initial access token (with line wraps within values for display - purposes only): + an initial access token: The following is a non-normative example request using an initial access token and registering a JWK Set by value (with line - wraps within values for display purposes only): + breaks within values for display purposes only): , while some values specific to the client instance are conveyed as regular parameters (with line - wraps within values for display purposes only): + breaks within values for display purposes only): client_id and SHOULD be unique for multiple instances of a client using the same client_id. This value is used by confidential clients to authenticate to - the token endpoint as described in OAuth + the token endpoint, as described in OAuth 2.0, Section 2.3.1. OPTIONAL. Time at which the client identifier was issued. The @@ -1060,7 +1059,7 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
The following is a non-normative example of an error response resulting from a redirection URI that has been - blacklisted by the authorization server (with line wraps within + blacklisted by the authorization server (with line breaks within values for display purposes only):
- Following is a non-normative example of an error + The following is a non-normative example of an error response resulting from an inconsistent combination of response_types and grant_types - values (with line wraps within values for display purposes + values (with line breaks within values for display purposes only):
- This specification establishes the OAuth Dynamic Client - Registration Metadata Registry. + This specification establishes the "OAuth Dynamic Client + Registration Metadata" registry. OAuth registration client metadata names and descriptions are registered with a Specification Required () @@ -1157,8 +1156,8 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
- The initial contents of the OAuth Dynamic Client Registration - Metadata Registry are: + The initial contents of the "OAuth Dynamic Client Registration + Metadata" registry are: - -example - - +Dynamic Registration +Dynamic Client Registration +OpenID Connect +OpenID Connect Dynamic Client Registration +OIDC +User Managed Access +UMA This specification defines methods for management of OAuth @@ -263,8 +263,7 @@ the title) for use on http://www.rfc-editor.org/search. access token.
- The following is a non-normative example request (with line - wraps for display purposes only): + The following is a non-normative example request:
- - Upon successful read of the information for a currently active client, the authorization server responds with an HTTP 200 OK with content type of application/json and a @@ -343,8 +340,7 @@ the title) for use on http://www.rfc-editor.org/search. above example with new information:
- The following is a non-normative example request (with line - wraps for display purposes only): + The following is a non-normative example request: .
- - Upon successful update, the authorization server responds with an HTTP 200 OK message with content type application/json and a payload as described in . @@ -410,8 +404,7 @@ the title) for use on http://www.rfc-editor.org/search. the client.
- The following is a non-normative example request (with line - wraps for display purposes only): + The following is a non-normative example request:
- - A successful delete action will invalidate the client_id, client_secret, and registration_access_token for this client, thereby preventing the client_id @@ -477,11 +468,11 @@ the title) for use on http://www.rfc-editor.org/search. REQUIRED. Fully - qualified URL string of the client configuration endpoint for this + qualified URL of the client configuration endpoint for this client. REQUIRED. Access - token string used at the client configuration endpoint to perform + token used at the client configuration endpoint to perform subsequent operations upon the client registration. @@ -530,7 +521,7 @@ the title) for use on http://www.rfc-editor.org/search.
This specification registers the following client metadata names and - descriptions in the OAuth Dynamic Client Registration Metadata Registry + descriptions in the "OAuth Dynamic Client Registration Metadata" registry established by : @@ -543,7 +534,7 @@ the title) for use on http://www.rfc-editor.org/search. Change Controller: IESG - Specification Document(s): this document (RFC 7592) + Specification Document(s): RFC 7592 Client Metadata Name: registration_client_uri @@ -552,7 +543,7 @@ the title) for use on http://www.rfc-editor.org/search. Change Controller: IESG - Specification Document(s): this document (RFC 7592) + Specification Document(s): RFC 7592