> -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Monday, May 10, 2010 12:12 PM
> >> 3.6.1.1. End-user Grants Authorization > >> > >> Why not call the "code" Parameter "verification_code"? It's called > >> verification code in the text. > >> > > Longer for no reason. > > > > for the sake of clarity? Anyone with thoughts on this? > >> 3.6.2. Client Requests Access Token > >> > >> client_secret > >> REQUIRED if the client identifier has a matching secret. The > >> client secret as described in Section 3.4. > >> > >> 1) I'm having trouble to understand the meaning of "if the client > >> identifier has a matching secret". Is the assumption underneath that > >> authorization servers require this secrets from all clients they have > >> issued > a secret to? Yes. > >> What about client w/o a secret? Are they also allowed to use this flow? > >> Or is there envisioned a dependency > >> between the client type, clients credentials and the flows a > >> particular client is authorized to use? Yes, they are (I think this is the compromise on native apps). > >> I would have expected a clear policy which flows require > >> authentication and which not. Suggest text. > >> 3.7.2. Client Requests Access Token > >> > >> "authorization_declined" > >> > >> Why does the spec interpret a request as bad request if the user just > >> has declined the authorization? According to rfc2616 the semantics of > >> 400 is: "The request could not be understood by the server due to > >> malformed syntax". > >> > >> The calling client did not sent a malformed request, it cannot > >> foresee or influence this outcome. I would suggest to either use > >> status 403 or to return status code 200 for all syntactically correct > >> and authorized request and to use another return codes in the response > body to detail the requests outcome. > >> > > Did you miss this question? No. Just ignored it because I need to go over all the HTTP status codes and error messages and clean it all up. Its incomplete at best right now. > >> 7. Refreshing an Access Token > >> > >> I would suggest to add an optional "scope" parameter to this request. > >> This could be used to downgrade the scope associated with a token. > >> > > That would be the wrong way to do it given that people will expect to also > be able to upgrade scope. > > > > What would be the right way? Allow the client to include an access token when asking for additional scope (via a normal flow) so that resulting token will include the scope of both new and old scopes. > >> 8.1. The Authorization Request Header > >> > >> I consider the name "Token" of the authentication schema much to > generic. > >> That was also the feedback of all colleagues I talked to about the > >> upcoming standard. Why not call it "OAuth2"? > >> > > It is meant to be generic. I consider OAuth to be the part of the protocol > dealing with getting a token. There will be many new ways to get a token in > the future. > > > > That's interesting! I consider the authentication scheme the major > contribution of OAuth since it allows for a standardized way of service > interaction. So 3rd party software components can be integrated into a > companies infrastructure (incl. AS) w/o customization. Moreover, as you > pointed out, there will be many other ways to get tokens in the future. I'm not married to the name. I dislike 'OAuth2' because it is wrong to put a version number in the name. We can potentially reuse 'OAuth' but I'm opposed to using the 'oauth_version=2.0' parameter specified in OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note that 1.0 uses the oauth_ prefix for parameters and deprecate the oauth_version parameter. Or something like that. I'm also open to new suggestions. But I think 'Token' is very descriptive (but I agree it does depend on your view of what is OAuth - I think it is really just the collection of flows). > > > >> 8.2.2. Form-Encoded Body Parameter > >> > >> I would suggest to drop this section/feature. > >> > >> General note: Would it make sense to add explicit format handling to > >> the OAuth API? If we envision authorization servers supporting more > >> than one token format (e.g. SAML, SWT, ...), the client should given > >> the option to request a certain format and responses returning access > >> tokens should indicate the format of this token. The OAuth > >> authorization header could also have an optional format attribute for the > same purpose. > >> > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. > > > > I dont't mean OAuth shall define token formats. I just ask for a way to > request tokens in a particular format and pass such meta data from AS to > resource server via the client. Why is that counter-productive? > Otherwise the resource server has to implement some token format > discovery. Yes it does. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
