Looking at the .txt version:
1. Line 260 s/authentication/authenticate
OAuth defines two client types, based on their ability to maintain
the confidentiality of their client credential, used to
authentication with the authorization server:
2. Line 274 s/with with/with
Before initiating the protocol, the client registers with with the
3. Line 508 s/denote/denotes
the client. The token denote an identifier used to retrieve the
4. In section 1.6, I still find it misleading to say:
The refresh token is bound to the client it was issued to, and its usage
requires client authentication.
This still implies "public clients" can't use refresh tokens by way of the
authentication requirement. I now understand the language in section 3
regarding an authorization server's discretion with client authentication,
but I would propose either dropping ", and it's usage requires client
authentication" above, or changing it to:
The refresh token is bound to the client it was issued to.
Authorization servers should require client authentication for private
clients when a refresh token is presented.
5. Is section 3.1 still [[Pending Consensus]] ?
6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization
Request
To protect against CSRF I believe the state parameter should be REQUIRED,
unless someone can demonstrate a scenario where it is not used and CSRF is
avoided by other means.
Regards,
Shane.
From: Eran Hammer-Lahav <e...@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: 05-07-11 03:13 PM
Subject: [OAUTH-WG] Timely review request: pre-draft-17
Sent by: oauth-boun...@ietf.org
I have started sharing my planned changes for 17:
https://github.com/hueniverse/draft-ietf-oauth
Change log:
https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028
f66708427961a1bc102#diff-3
My main focus right now is to clarify client types, registration, and
identification, as well as tweak the registration requirements for
redirection URIs. This is still very raw. However, I would very much like
to get feedback about the following sections:
1.1.1. Client Types
1.2. Client Registration
2.1.1. Redirection URI
In section 2.1.1, please note that it includes many new normative
requirements, but in practice, they mostly boil down to the requirement to
register a redirection URI for using the implicit grant type as well as
using the authorization code with a public client (new term for describing
client incapable of keeping secrets).
I have turned the spec around, making registered redirection URIs the
default, and using the parameter as an optional feature.
Feedback is very much appreciated as we only have a few more days before I
have to push out -17 and would like a few more eyes looking at the new
text before published.
I am still not ready to share changes to section 3. Also, I have a long
list of additional changes raised on the list.
Thanks,
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
