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:[email protected]] Sent: Wednesday, May 12, 2010 8:25 AM To: Nennker, Axel; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf > Of [email protected] > Sent: Tuesday, May 11, 2010 11:22 PM > To: [email protected] > 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: [email protected] [mailto:[email protected]] On Behalf > Of [email protected] > Sent: Monday, May 10, 2010 7:45 AM > To: [email protected] > Cc: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
