We merged the state verification in with this rather than forcing people to 
also look at the JWT encoded State draft.  
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.  

While JWT encoded state is how I would do state in a client and at-least one 
client I know of uses it, it is not the only way to manage state, and I am 
hesitant that developers might be scared away by thinking they need to encode 
state as a JWT.

I decided that cross referencing them is better.   This made sending much 
simpler to describe.   

I also removed the hashing from state.   That cut the text by about 2/3 by not 
having to describe character set normalization so that both the client and the 
AS could calculate the same hash.
That also achieved the goal of not requiring a simple OAuth client doing the 
code flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we need to defend why we don’t have crypto 
agility eg support for SHA3 etc.  We would be forced by the IESG to add another 
parameter to the request to specify the hash alg if we went that direction.

Given that we assume state to be public info in the request that an attacker 
can see, hashing state provides not much value for a lot of complexity that 
people may get wrong or not implement.

I appreciate why from a theory point of view hashing it would have been better.

If people really want it I can add it back.

John B.

> On Jan 21, 2016, at 3:28 AM, Mike Jones <michael.jo...@microsoft.com> wrote:
> 
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up 
> Mitigation draft.  Changes were:
> ·       Simplified by no longer specifying the signed JWT method for 
> returning the mitigation information.
> ·       Simplified by no longer depending upon publication of a discovery 
> metadata document.
> ·       Added the “state” token request parameter.
> ·       Added examples.
> ·       Added John Bradley as an editor.
>  
> The specification is available at:
> ·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 
> <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01>
>  
> An HTML-formatted version is also available at:
> ·       
> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html 
> <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html>
>  
>                                                           -- Mike
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1526 
> <http://self-issued.info/?p=1526> and as @selfissued 
> <https://twitter.com/selfissued>.
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to