-1 to including a signature mechanism in OAuth2 core +1 to OAuth2 being clear about how it can deliver a secret key (and algorithm id etc) that can be used by a signature mechanism
Firstly -- a mechanism to sign HTTP requests would be great, but should not be dependent on methods for users to delegate authority to apps, or on methods for apps to get temporary, less-privileged credentials. That is, don't make it OAuth-specific. Defining a request signing mechanism in OAuth2 core will cripple it with OAuth-specific quirks. The OAuth1 signing mechanism, for instance: uses names with "oauth_" prefixes; uses 2 keys (an apps long-term key, and the delegation-specific token key) whereas generic signing mechanisms invariable work with a single signing key; and overloads a single HTTP authentication scheme name with multiple purposes (indicating a server supports delegation, and conveying a request signature). Secondly -- there isn't just one sensible signing mechanism, so how do we pick which one is specified in OAuth2 core. An enveloping-style signature (eg magic signatures?); an OAuth1-style signature using 2 keys; a signature covering HTTP method/URI/body but not other headers; a signature covering any HTTP headers; a signature that can be encoded in a URI; a signature that also works on non-HTTP systems; a signature scheme that is efficient when the client app already has its own long-term public/private key pair... -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
