There is a bit of confusion here. We had clear consensus that the client credentials are only used to obtain a token, not to access protected resources. Some flows use just the client identifier, while others use both the identifier and shared secret. The assertion flow doesn't use it at all.
We had clear consensus that an asymmetric secret solution, whether it was for tokens or client credentials is out of scope. Adding support for a symmetric token secret using HMAC was the compromise, since many people consider the bearer token approach to be the most likely one to win wide adoption (I'm representing consensus, not necessarily agreeing with it). Extensions are not hacks (unless they are poorly written). Profiles are not hacks. An extension saying: "instead of including the 'client_secret', include a 'signature' parameter with your request" isn't a hack. We are still likely to see a PK-based solution in the form of an extension flow (for example, the client makes a request where the client identifier is a domain name and the request is signed using the client's private key; the server verifies the request by getting the client's public key from its host-meta document for the domain used in the client identifier). Such a PK solution can be a new flow or an extension to existing flows. Either way, it will be in a separate document. We are also likely to see a PK-based solution for token secrets, similar to the OAuth RSA approach. However, it is far from clear which private key will be used to sign protected resources requests. The client's? A token-specific PK? Is this going to be a combination of a token flow and protected resource extension? I don't know because I don't have any actual use cases in mind right now. But the spec was written to make sure It will not prevent this from being added later on. The current client identifier and client secret are what we have wide consensus on. We are still discussing how to send these, but from the answers so far, there is enough support to keep the parameters in (with or without support for sending them using Basic as an alternative method). EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Paul Madsen > Sent: Wednesday, May 12, 2010 3:57 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > But client_secret is not defined specific to a given flow - its used by the > web > server, user name, and client credentials flows. > > I can find no mention of the client using the client_secret for crypto > authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to > clients authenticating their resource requests, not their requests to the AS. > > Is the client_secret limited to be a bearer token? > > This earlier message [1] of Eran's suggests that a crypto authentication was > in > scope at one point > > "We are still very likely to have a PK-based method for obtaining > *authorization* (a token)" > > [1] - http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html > > On 5/12/2010 2:29 AM, David Recordon wrote: > > Yes, the Client authenticating using a RSA key pair seems like it > > should be a different flow. > > > > On Tue, May 11, 2010 at 11:25 PM, Eran Hammer- > Lahav<e...@hueniverse.com> wrote: > > > >> But it is not beyond the scope. We define a parameter just for that called > client_secret. If you want to use something else, you need to define an > extension that replaces that with something else. > >> > >> EHL > >> > >> > >>> -----Original Message----- > >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>> Behalf Of axel.nenn...@telekom.de > >>> Sent: Tuesday, May 11, 2010 11:22 PM > >>> To: oauth@ietf.org > >>> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>> > >>> I suggest a change to > >>> > >>> "3.4. Client Credentials > >>> > >>> When requesting access from the authorization server, the client > >>> identifies itself using a set of client credentials. The client > >>> credentials include a client identifier and an OPTIONAL symmetric > >>> shared secret. The means through which the client obtains these > >>> credentials are beyond the scope of this specification, but usually > >>> involve registration with the authorization server." > >>> > >>> I don't like the "symmetric shared secret" and would like this to be > >>> "beyond the scope of this spec". > >>> > >>> I suggest to change that paragraph e.g. to: > >>> > >>> "3.4. Client Credentials > >>> > >>> When requesting access from the authorization server, the client > >>> authenticates itself using its credentials. The type of credentials > >>> is beyond the scope of this specification. The means through which > >>> the client obtains these credentials are beyond the scope of this > >>> specification, but usually involve registration with the > >>> authorization server." > >>> > >>> -Axel > >>> > >>> Ps. > >>> If the client has an e.g. RSA-keypair then it could use the private > >>> key to sign the request and thereby authenticate itself. > >>> The public key would need to be exchanged before out-of-band. Or it > >>> could be a certificate that is e.g. issued by the authorization > >>> server or a party that the authorization server trusts. > >>> > >>> -----Original Message----- > >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>> Behalf Of internet-dra...@ietf.org > >>> Sent: Monday, May 10, 2010 7:45 AM > >>> To: i-d-annou...@ietf.org > >>> Cc: oauth@ietf.org > >>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>> This draft is a work item of the Open Authentication Protocol > >>> Working Group of the IETF. > >>> > >>> > >>> Title : The OAuth 2.0 Protocol > >>> Author(s) : E. Hammer-Lahav, et al. > >>> Filename : draft-ietf-oauth-v2-04.txt > >>> Pages : 51 > >>> Date : 2010-05-09 > >>> > >>> This specification describes the OAuth 2.0 protocol. OAuth provides > >>> a method for making authenticated HTTP requests using a token - an > >>> identifier used to denote an access grant with specific scope, > >>> duration, and other attributes. Tokens are issued to third-party > >>> clients by an authorization server with the approval of the resource > >>> owner. OAuth defines multiple flows for obtaining a token to > >>> support a wide range of client types and user experience. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet- Draft. > >>> _______________________________________________ > >>> 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 > >> > >> > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
