On 6/11/10 1:47 PM, "Marius Scurtescu" <[email protected]> wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <[email protected]>
> wrote:
>> 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.
>
> It would be really useful if each request had a unique type, now we
> are back to guessing what is requested, like in WRAP.
You are always requesting an access token. What you probably mean is what
kind of authorization grant the client is presenting, which I think is
pretty obvious from, well, what the client is presenting...
> One small error that I noticed: section "5.1.4. Refresh Token" is not
> listing client_id and client_secret as optional parameters.
This is because client authentication is now handled in a separate section.
This is required (I still have a lot of work in this one) to separate the
client credentials from the flows which was a much requested change during
the meeting. Previous drafts made it very hard to specify client credentials
other than basic (i.e. Username and password like).
I plan to actually name the client identifier and password 'basic client
credentials' (which I think I already did in one spot), and say that if the
client was issued such basic credentials, this is how to use them (basic
auth or client_id/client_password parameters). Otherwise, this can be
extended to other credential types such as client identifier with PKI.
> In general I found previous versions much easier to read and
> understand, but maybe I just need more time...
This new structure requires much more clarity in the introduction and in the
client flows section. But it I think it makes implementation easier because
it gives all the technical details of the two endpoints in one place,
listing all the parameters and error codes.
Also, there is something to be said about dropping 20 pages.
What would be really useful is to get specific feedback about which new
sections are confusing, based on information not yet explained, etc.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
