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
