some comments on the new draft from my side.
In my opinion, the raised abstraction level makes the spec harder to
read but more elegant :-) Rearranging conceptual statements and
endpoint/request descriptions would probably further improve
readability. For example, the end-user authorization endpoint is one of
the two interfaces exposed by the OAuth authz server. Thus it's
specification is very important for AS and client implementors. Why not
making 4.1.1 a first level section or a second level section underneath
an "endpoints" section? The same holds for ยง5.1.
You decoupled flows (==use cases) from request types, a change a welcome
very much. But why do you stick to flow types in 4.1.1? From my point of
view, the parameter "type" is only used to control the way the authz
server responds to the authorization request. There are currently two
options: (1) verification code as URI query parameter and (2) access
token as URI fragment. Why not rename "type" to "response_type" and use
values like "code" and "fragment"? This would also allow to add other
response types for web server clients, like "token as encrypted URI
parameter".
Minor notes:
1 . Introduction
I would propose to extend the sentence
Instead, she authenticates directly with
the photo sharing service (authorization server) which issues the
printing service delegation-specific credentials (token).
to also mention the option of a dedicated authorization server, e.g.
Instead, she authenticates directly with the photo sharing service, or an OAuth
authorization server the photo sharing service trusts for that purpose, ...
section 5.1.6.
Status code 400 is not appropriate from my point of view for all error
situations. I would propose to use 401 and 403 for unauthenticated and
unauthorized requests, respectively.
regards,
Torsten.
Am 11.06.2010 22:11, schrieb Eran Hammer-Lahav:
Draft -07 represents a major rearrangement of the document. I still have a lot
of work to do but wanted to share my progress and get some general feedback.
The draft includes a few normative language changes but the main focus is on
the document structure and how the architecture is explained.
Changes include:
o Removed device profile.
o Added verification code support to user-agent flow.
o Removed multiple formats support, leaving JSON as the only format.
o Changed assertion "assertion_format" parameter to "assertion_type".
o Removed "type" parameter from token endpoint.
The spec is now 36 pages, 19 pages shorter than -05.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
