Eran,
I want to support the idea of a minimal specification, that supports the
basic use-case with no frills. Successful standards are usually small
and with strong focus on a few key use-cases
But the specification does need to point to or document some
extensibilty points. Otherwise, implementations will hard-wire the exact
form of credential described in the specification and profiles will be
viewed as alternatives not as variants. Instead, it would be good if
implementations were somewhat "pluggable" with respect to the security
credential exchanges between
1) client (SP) and authorization service
2) client (SP) and resource server
I realize this creates more work for the folks actually writing the
specification (versus us lurkers) but it does increase the value of this
effort by an order of magnitude.
I guess I should take an action to explain how this might be
accomplished in the present draft.
- prateek
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
