Comments:
Introduction, first sentence is awkward. Change from
In some use-case scenarios, it is desirable or necessary to allow OAuth
clients to obtain authorization from an OAuth authorization server without
the two parties having previously interacted.
To
In some scenarios, it is desirable or necessary to allow OAuth clients
to
obtain authorization from an OAuth authorization server without requiring
the two parties to interact beforehand in order to register the client.
Section 2:
* definition of token_endpoint_auth_method values, definition of
"client_secret_jwt" has "semetric secret" which should be "symmetric
secret".
* definition of jwk_url says that it is OPTIONAL but that if
jwk_encryption_url is not provided, the key at jwk_url will be used for
both encryption and signing. If this is optional, then what happens if
neither of these parameters are defined? Should that be explicitly called
out, if the "jwk but no jwk encryption" case is?
* definition of x509_url - same comment as above. Calls out one specific
case (x509 but no x509 encryption) but does not call out what happens if
x509_url is not specified.
Section 3:
Reorder the following paragraphs so that the 3rd (describing a potential
initial access token) is first, the 2nd stays where it is, and the first
is 3rd.
From:
------
In order to facilitate registered clients updating their information,
the Client Registration Endpoint issues a request_access_token for
clients to securely identify themselves in future connections. As
such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens
[RFC6750] for these operations.
In order to support open registration and facilitate wider
interoperability, the Client Registration Endpoint SHOULD allow
client_register requests with no further authentication. These
requests MAY be rate-limited to prevent a denial-of-service attack on
the Client Registration Endpoint.
In addition, the Client Registration Endpoint MAY accept an initial
authorization credential in the form of an OAuth 2.0 [RFC6749] access
token in order to limit registration to only previously authorized
parties. The method by which this access token is obtained by the
registrant is generally out-of-band and is out of scope of this
Specification.
-------
To:
-------
The Client Registration Endpoint MAY accept an initial
authorization credential in the form of an OAuth 2.0 [RFC6749] access
token in order to limit registration to only previously authorized
parties. The method by which this access token is obtained by the
registrant is generally out-of-band and is out of scope of this
Specification.
In order to support open registration and facilitate wider
interoperability, the Client Registration Endpoint SHOULD allow
client_register requests with no further authentication. These
requests MAY be rate-limited to prevent a denial-of-service attack on
the Client Registration Endpoint.
In order to facilitate registered clients updating their information,
the Client Registration Endpoint issues a request_access_token for
clients to securely identify themselves in future connections. As
such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens
[RFC6750] for these operations.
-------
That way they are in chronological request order, which flows better.
Section 3.4 editor's note: I think it would make sense for the response to
contain the entire client metadata listing.
Section 3.5 access token definition - use same wording as in 3.3. Wording
here is slightly different, wording in 3.3 is better.
Section 5 paragraph 4, last sentence reads: "...especially if they're
dynamically registered, have not been trusted by any users at the
Authorization Server before", should be "Šespecially if they're
dynamically registered and have not been trusted by any users at the
Authorization Server before".
--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
[email protected]
From: <Richer>, Justin Richer <[email protected]>
Date: Tuesday, November 27, 2012 6:00 PM
To: "[email protected]" <[email protected]>
Subject: [OAUTH-WG] Fwd: New Version Notification
for draft-ietf-oauth-dyn-reg-02.txt
Updated dynamic registration draft, thanks to everyone for the comments so
far. Keep them coming, I think we've still got a little ways to go.
-- Justin
Begin forwarded message:
From:
<[email protected]>
Subject:
New Version Notification for draft-ietf-oauth-dyn-reg-02.txt
Date:
November 27, 2012 5:58:43 PM EST
To:
<[email protected]>
Cc:
<[email protected]>, <[email protected]>, <[email protected]>
A new version of I-D, draft-ietf-oauth-dyn-reg-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename: draft-ietf-oauth-dyn-reg
Revision: 02
Title: OAuth Dynamic Client Registration Protocol
Creation date: 2012-11-27
WG ID: oauth
Number of pages: 19
URL:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-reg-02.txt
Status: http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
Htmlized: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-02
Abstract:
This specification defines an endpoint and protocol for dynamic
registration of OAuth Clients at an Authorizaiton Server.
The IETF Secretariat
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
