Brian,
> There are actually a bunch of fundamentally conflicting requirements
> for signatures from the various folks contributing to this working
> group.
> ...
> For the record, I think *every single one* of those requirements makes
> sense in certain contexts.
I agree.
>... we're going to have to split out profiles to deal with the
> different key distribution challenges.
Instead of starting with profiles, I think a key to addressing this issue is to
make the token response format richer. It should tell the client app all it
needs to know to authenticate its calls to protected resources. From a token
response, a client app should know this particular service’s requirements:
bearer token / client secret / token secret; shared secret / public key;
short-term / permanent; ....
My mental model of the token response has it performing two tasks:
1. Indicating how to authenticate requests to protected resources -- much like
a WWW-Authenticate response header for a "normal" authentication scheme
(without user delegation).
2. Provide all or some of the values necessary to make those authenticated
requests.
The token response should include the name of the HTTP authentication scheme
that will be used to access protected resources.
Example: { "scheme":"BASIC" ...} or {"scheme":"Token" ...}
It makes it fairly obvious how to integrate other auth schemes with OAuth: just
include the parameters from that scheme’s WWW-Authenticate header in a token
response.
I quite like the idea of indicating whether subsequent requests are signed with
the client’s secret or a token secret by simply omitting or including such a
secret in the token response.
[This does assume that knowing the "scheme" is sufficient to determine if a
secret is required, which is one more reason why reusing "Token" for bearer,
MAC and public-key operations is a poor design.]
A (less desirable) alternative is a specific "client_auth":[TRUE|FALSE]
parameter in a token response.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
