I challenge the claim that the spec gets harder to read. In fact the spec becomes cleaner if we move from one special case to a general description. Implementing other authn schemes while keeping the spec hardwired to shared-secrets might be trivial but those implementations will always be hacks.
I think that the proposed changes (client_secret -> client_credential, secret_type -> credential_type) are simple and clear as can be. Whether other autn schemes are proposed or not is not that relevant. I think that hardwiring "things" (authn schemes, digest algorithms) is always a bad idea. A standard should be simple to implement while beeing extensible without "hacks". -Axel -----Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, May 12, 2010 8:47 AM To: Nennker, Axel; oauth@ietf.org Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt I wouldn't. The fact is that the current spec provides a symmetric secret for authenticating clients. Extending this to use something else is trivial. Since this will be the majority of implementation (based on current deployment), I see no reason to make the spec harder to read and implement for something that is not even proposed. EHL > -----Original Message----- > From: axel.nenn...@telekom.de [mailto:axel.nenn...@telekom.de] > Sent: Tuesday, May 11, 2010 11:43 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > I would rename "client_secret" to "client_credential" and "secret_type" > to "credential_type". > The client_credential might be a shared secret denoted by e.g. > "credential_type=shared_secret". > > -Axel > > -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Wednesday, May 12, 2010 8:25 AM > To: Nennker, Axel; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > 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
