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