The spec should only directly enable extensibility where extensibility is a requirement/use case. For example, we know we are going to have more flows, so the spec should define the process to add new flows and register their 'type' value. Same with other HMAC algorithms.
However, making something extensible because it *might* be used in the future just makes the protocol more complicated for no gain. If someone has specific use cases around other client credentials, please share them so we can make sure they are either supported or enabled as an extension. But saying that we are sure to have other types of credentials so let's make sure the spec is ready for them is a no-starter. Also, it's not a bad thing that extending the protocol is a bit of a challenge. Extensions, by definition, hurt interop. There should be some burden in extending to make people reconsider and try to work with what they have. In other words, extensibility, like everything else, must be driven by use cases and requirements. We spent months discussing why we need signatures and ended up with good technical reasons and limited support to just those uses. And this is truly *not* aimed at anyone in particular: I'm getting tired of people lecturing the group about what makes a good standard. There are plenty of examples of simple and complex, successful and failed standards out there. What makes a standard successful is what makes fashion successful - influential people (or companies) start using it. If you have a *technical* argument for or against a feature, please make it, but enough with the lectures about why we are here, what makes standards successful, and other theories. EHL > -----Original Message----- > From: Prateek Mishra [mailto:[email protected]] > Sent: Wednesday, May 12, 2010 9:39 AM > To: Eran Hammer-Lahav > Cc: [email protected] > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > 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: [email protected] [mailto:[email protected]] On > >> Behalf Of Paul Madsen > >> Sent: Wednesday, May 12, 2010 3:57 AM > >> To: [email protected] > >> 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<[email protected]> 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: [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 > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
