Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

[David Recordon <[e-mail]>]

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-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of [e-mail]
>> Sent: Tuesday, May 11, 2010 11:22 PM
>> To: [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of [e-mail]
>> Sent: Monday, May 10, 2010 7:45 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>