Re: [OAUTH-WG] Preliminary OAuth Core draft -29

[Justin Richer <[e-mail]>]

Implicit grant makes perfect sense when the user agent and client are 
collapsed into a single entity. In other words, if your client is inside 
the user agent then doing a code flow doesn't actually buy you any extra 
security. This is the driving design decision behind having it in there, 
and from my perspective that's clear from the current text.

In a similar manner, the client credentials flow came about from 
collapsing the client with the resource owner, effectively putting the 
resource owner inside the client. In this case the authorization step 
doesn't make any sense and doing a code flow doesn't buy you any greater 
security, either.

  -- Justin

On 07/09/2012 01:31 PM, Dick Hardt wrote:
> Hi Mike
>
> Reading over the spec, I think some more color in 4.2 on the risks of 
> the Implicit Grant and where it makes sense and where it does not is 
> in order.
> Also, this should be in Section 9.
>
> Thoughts?
>
> -- Dick
>
> On Jul 9, 2012, at 12:08 AM, Mike Jones wrote:
>
>> A preliminary version of OAuth core draft -29 is attached for the 
>> working group's consideration and discussion on today's call.  I 
>> believe that this addresses all issues that have been raised, 
>> including Julian's issues about the ABNF, character sets, and form 
>> encoding.  Changes are:
>>
>>   * Added "MUST" to "A public client that was not issued a client
>>     password MUST use theclient_idrequest parameter to identify
>>     itself when sending requests to the token endpoint" and added
>>     text explaining why this must be so.
>>   * Added that the authorization server MUST "ensure the
>>     authorization code was issued to the authenticated confidential
>>     client or to the public client identified by theclient_idin the
>>     request".
>>   * Added Security Considerations section "Misuse of Access Token to
>>     Impersonate Resource Owner at Public Client".
>>   * Deleted ";charset=UTF-8" from examples formerly using
>>     "Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
>>   * Added the phrase "and a character encoding of UTF-8" when
>>     describing how to send requests using the HTTP request
>>     entity-body, per Julian Reschke's suggestion.
>>   * Added "The ABNF below is defined in terms of Unicode code points
>>     [UNICODE5]; these characters are typically encoded in UTF-8".
>>   * For symmetry when using HTTP Basic authentication, also apply
>>     theapplication/x-www-form-urlencodedencoding to the client
>>     password, just as was already done for the client identifier.
>>   * Reduced multiple blank lines around artwork elements to single
>>     blank lines.
>>   * Removed Eran Hammer's name from the author list, at his request.
>>     Dick Hardt is now listed as the editor.
>>
>> Best wishes,
>> -- Mike
>> <draft-ietf-oauth-v2-29 preliminary.txt><draft-ietf-oauth-v2-29 
>> preliminary.html><draft-ietf-oauth-v2-29 
>> preliminary.pdf><draft-ietf-oauth-v2-29 
>> preliminary.xml>_______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth