OAuth 1.0a solves ordering problems there but not additional data being added
to the specific headers. It specifically requires the library to break apart,
sort, and reassemble in a alphabetical order by name the query string
parameters and oauth_* parameters. One of the less popular things about it.
________________________________
From: Prateek Mishra <prateek.mis...@oracle.com>
To: oauth@ietf.org; William Mills <wmills_92...@yahoo.com>
Sent: Monday, February 4, 2013 1:28 PM
Subject: Re: [OAUTH-WG] conf call follow up from today
Bill -
How does OAuth 1.0a deal with the problem of HTTP URL and header
mutability? Header order may get re-arranged and URLs modified in
transit from client to server. As a result, the signature/HMAC
might not validate at the final destination.
Isn't that a foundational problem with the OAuth 1.0a model? I
thought that was one of the concerns expressed at the meeting today.
- prateek
1) I think that we need to focus on specific solutions, as I said on the call,
and solve the OAuth 1.0a/MAC use case. There's significant installed base of
OAuth 1.0a and we need a path for those installations into OAuth 2.0. I may
well pursue MAC in the interim to do this, but a full HOK solution woul work
too.
>
>
>2) I think the discussion we were having about "which authenticator to use"
>falls squarely into the endpoint discovery discussion and we should put that
>energy into endpoint discovery as distinct from HOK.
>
>
>3) We haven't talked yet about how a client will be able to specify a token
>type if it wants a specific one. OAuth 2 core will need to be extended to
>support this.
>
>
>4) We should leave the key distribution/discovery mechanism either out of
>scope or define it explicitly per HOK token type profile. This will have to
>work with the extensions for #3 above.
>
>
>5) I want to avoid the problem in OAuth 1.0a of having to support and accept
>every possible signing mode. Being force to accept PLAINTEXT sucks. We need
>a way for the discovery endpoint to mandate a specific set of allowed
>signature methods.
>
>
>Regards,
>
>
>-bill
>
>
>
>
>_______________________________________________
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
