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
