Skip to content

Commit

Permalink
incorporated second round of RFC editor edits
Browse files Browse the repository at this point in the history
  • Loading branch information
@jricher
jricher committed Jul 1, 2015
1 parent 0ee8b4d commit 9f871bb
Show file tree
Hide file tree
Showing 2 changed files with 38 additions and 74 deletions.
58 changes: 14 additions & 44 deletions rfc7591.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -708,11 +708,11 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
<t/>

<t>The software statement is typically distributed with all instances
of a client application.The means by which a client or developer
of a client application. The means by which a client or developer
obtains a software statement are outside the scope of this
specification. Some common methods could include a client developer
generating a client-specific JWT by registering with a software
API publisher to obtain a software statement for a class of clients. </t>
API publisher to obtain a software statement for a class of clients.</t>

<t>The criteria by which authorization servers determine whether to
trust and utilize the information in a software statement are outside
Expand Down Expand Up @@ -827,9 +827,9 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method":"client_secret_basic",
"token_endpoint_auth_method": "client_secret_basic",
"policy_uri": "https://client.example.org/policy.html",
"jwks":{"keys": [{
"jwks": {"keys": [{
"e": "AQAB",
"n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
Expand Down Expand Up @@ -1102,10 +1102,6 @@ IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
</section>
</section>

<!--[rfced] We recall that M. Jones had a preference for using Designated
Experts (plural) in previous documents in this cluster. We have updated
the IANA section accordingly: please let us know any objections.
-->

<section anchor="IANA" title="IANA Considerations">
<section anchor="MetadataRegistry"
Expand All @@ -1132,36 +1128,6 @@ the IANA section accordingly: please let us know any objections.
and, if applicable, suggestions as to how to make the request
successful.</t>

<!--[rfced] We note that the text in the OAuth Dynamic Client Registration
Metadata Registry section (and the OAuth Token Endpoint Authentication
Methods Registry section) is very similar to the text in the IANA
Considerations section of RFC 7518. However, the following text appears
in RFC 7518 and not in this document. Please consider if similar text
would be beneficial to the reader.
From RFC 7518:
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
[email protected] mailing list) for resolution.
Criteria that should be applied by the Designated Experts include
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
useful only for a single application, and whether the registration
description is clear.
...
It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other
Experts.
-->

<t>IANA must only accept registry updates from the Designated
Experts and should direct all requests for registration to the
review mailing list.</t>
Expand Down Expand Up @@ -1443,8 +1409,12 @@ to match the minor changes made in the descriptions below.

<section anchor="TEAMTemplate" title="Registration Template">
<t><list style="hanging">

<!--[rfced] Note that the update from "Authorization" to "Authentication" throughout Sections 4.2.1 and 4.2.2 will be communicated to IANA prior to publication.
-->
<t
hangText="Token Endpoint Authorization Method Name:"><vspace/>
hangText="Token Endpoint Authentication Method Name:"><vspace/>
The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case-insensitive manner SHOULD NOT be accepted.</t>

Expand All @@ -1466,7 +1436,7 @@ to match the minor changes made in the descriptions below.
Methods Registry are:</t>

<t><?rfc subcompact="yes"?> <list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
<t>Token Endpoint Authentication Method Name: <spanx
style="verb">none</spanx></t>

<t>Change Controller: IESG</t>
Expand All @@ -1475,7 +1445,7 @@ to match the minor changes made in the descriptions below.
</list></t>

<t><list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
<t>Token Endpoint Authentication Method Name: <spanx
style="verb">client_secret_post</spanx></t>

<t>Change Controller: IESG</t>
Expand All @@ -1484,7 +1454,7 @@ to match the minor changes made in the descriptions below.
</list></t>

<t><list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
<t>Token Endpoint Authentication Method Name: <spanx
style="verb">client_secret_basic</spanx></t>

<t>Change Controller: IESG</t>
Expand All @@ -1504,7 +1474,7 @@ to match the minor changes made in the descriptions below.
transport-layer security mechanism when sending requests to the
registration endpoint. The server MUST support TLS 1.2 <xref
target="RFC5246"></xref> and MAY support additional
transport-layer mechanisms meeting its security requirements. When using
transport-layer security mechanisms meeting its security requirements. When using
TLS, the client MUST perform a TLS/SSL server certificate check, per
<xref target="RFC6125">RFC 6125</xref>. Implementation security
considerations can be found in <xref target="BCP195">Recommendations
Expand Down Expand Up @@ -1569,7 +1539,7 @@ NEW:
to the browser alongside the code.</t>

<t>Since different OAuth 2.0 grant types have different security and
usage aspects, an authorization server MAY require separate
usage properties, an authorization server MAY require separate
registrations for a piece of software to support multiple grant types.
For instance, an authorization server might require that all clients
using the <spanx style="verb">authorization_code</spanx> grant type make
Expand Down
54 changes: 24 additions & 30 deletions rfc7592.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -64,15 +64,11 @@ the title) for use on http://www.rfc-editor.org/search.

<keyword>example</keyword>

<!--[rfced] We note that RFC 6750 uses "bearer token" and RFC 7523 uses
"Bearer Token". We went with initial caps to match RFC 7523 as it is
another document in this cluster. Please let us know if you prefer
otherwise.
-->


<abstract>
<t>This specification defines methods for management of dynamic OAuth
2.0 client registrations for use cases in which the properties of a
<t>This specification defines methods for management of OAuth
2.0 dynamic client registrations for use cases in which the properties of a
registered client may need to be changed during the lifetime of the
client. Not all authorization servers supporting dynamic client
registration will support these management methods.</t>
Expand Down Expand Up @@ -283,7 +279,7 @@ otherwise.
<t>Upon successful read of the information for a currently active
client, the authorization server responds with an HTTP 200 OK with
content type of <spanx style="verb">application/json</spanx> and a
payload, as described in <xref target="ClientInfoResponse"/>. Some
payload as described in <xref target="ClientInfoResponse"/>. Some
values in the response, including the <spanx style="verb">client_secret</spanx>
and <spanx style="verb">registration_access_token</spanx>, MAY be
different from those in the initial registration response. If the
Expand All @@ -306,7 +302,7 @@ otherwise.
</section>

<section anchor="UpdateRequest" title="Client Update Request">
<t>To update previously registered client's registration with an
<t>To update a previously registered client's registration with an
authorization server, the client makes an HTTP PUT request to the
client configuration endpoint with a content type of <spanx
style="verb">application/json</spanx>. The HTTP entity payload is a
Expand Down Expand Up @@ -357,18 +353,18 @@ otherwise.
Authorization: Bearer reg-23410913-abewfq.123483
{
"client_id":"s6BhdRkqt3",
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"redirect_uris":[
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/alt"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"client_name":"My New Example",
"client_name#fr":"Mon Nouvel Exemple",
"logo_uri":"https://client.example.org/newlogo.png",
"logo_uri#fr":"https://client.example.org/fr/newlogo.png"
"client_name": "My New Example",
"client_name#fr": "Mon Nouvel Exemple",
"logo_uri": "https://client.example.org/newlogo.png",
"logo_uri#fr": "https://client.example.org/fr/newlogo.png"
}
]]></artwork>

Expand All @@ -380,7 +376,7 @@ otherwise.

<t>Upon successful update, the authorization server responds with an
HTTP 200 OK message with content type <spanx style="verb">application/json</spanx>
and a payload, as described in <xref target="ClientInfoResponse"/>.
and a payload as described in <xref target="ClientInfoResponse"/>.
Some values in the response, including the <spanx style="verb">client_secret</spanx>
and <spanx style="verb">registration_access_token</spanx>, MAY be
different from those in the initial registration response. If the
Expand Down Expand Up @@ -411,7 +407,7 @@ otherwise.
<t>To deprovision itself on the authorization server, the client makes
an HTTP DELETE request to the client configuration endpoint. This
request is authenticated by the registration access token issued to
the client as described in <xref target="RFC6749"/>.</t>
the client.</t>

<figure>
<preamble>The following is a non-normative example request (with line
Expand Down Expand Up @@ -479,13 +475,14 @@ otherwise.
subsequent operations at the client configuration endpoint.</t>

<t><list style="hanging">
<t hangText="registration_access_token"><vspace/> REQUIRED. Access
token string used at the client configuration endpoint to perform
subsequent operations upon the client registration.</t>

<t hangText="registration_client_uri"><vspace/> REQUIRED. Fully
qualified URL string of the client configuration endpoint for this
client.</t>

<t hangText="registration_access_token"><vspace/> REQUIRED. Access
token string used at the client configuration endpoint to perform
subsequent operations upon the client registration.</t>
</list></t>

<t>Additionally, the authorization server MUST return all registered
Expand All @@ -512,14 +509,14 @@ otherwise.
"registration_access_token": "reg-23410913-abewfq.123483",
"registration_client_uri":
"https://server.example.com/register/s6BhdRkqt3",
"client_id":"s6BhdRkqt3",
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at":2893256800,
"client_secret_expires_at":2893276800,
"client_name":"My Example Client",
"client_id_issued_at": 2893256800,
"client_secret_expires_at": 2893276800,
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"redirect_uris":[
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
Expand All @@ -536,10 +533,7 @@ otherwise.
descriptions in the OAuth Dynamic Client Registration Metadata Registry
established by <xref target="RFC7591"/>:</t>

<!-- [rfced] FYI, we will send a request to IANA to update the registry
to match the minor change made in the description below. (Text was updated
to 'Bearer Token' as mentioned above.)
-->


<t><list style="symbols">
<t>Client Metadata Name: <spanx style="verb">registration_access_token</spanx></t>
Expand Down Expand Up @@ -583,7 +577,7 @@ to 'Bearer Token' as mentioned above.)
transmission of clear-text credentials (in the HTTP request and
response), the authorization server MUST require the use of a
transport-layer security mechanism when sending requests to the
endpoint. The server MUST support TLS 1.2 <xref target="RFC5246"></xref> and MAY support additional transport-layer mechanisms
endpoint. The server MUST support TLS 1.2 <xref target="RFC5246"></xref> and MAY support additional transport-layer security mechanisms
meeting its security requirements. When using TLS, the client MUST
perform a TLS/SSL server certificate check, per <xref
target="RFC6125">RFC 6125</xref>. Implementation security considerations
Expand Down

0 comments on commit 9f871bb

Please sign in to comment.