No thanks. I much prefer posts on this list. I would be best if people didn't sent one email with a long list of issues, but instead posted each issue separately to help manage the discussion.
EHL > -----Original Message----- > From: William Mills [mailto:[email protected]] > Sent: Tuesday, June 15, 2010 9:48 AM > To: Eran Hammer-Lahav; [email protected] > Subject: RE: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > Recordon had a fantastic idea at the interim meeting, using G Wave for > comments on the draft, which would have been far superior to the > whiteboard. Perhaps when your ready for another major round of > comments the text version can get posted to a wave and folks can annotate. > > -bill > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, June 14, 2010 11:35 PM > > To: OAuth WG ([email protected]) > > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > > > During the OAuth WG interim meeting, the group spent a considerable > > amount of time going over draft -05 and listing issues with the text > > and protocol. Since the draft is now significantly different, I want > > to go over this and identify the issues resolved and those still open > > (before it is too late). > > > > These comments are based on Brian Eaton's detailed notes > > (thanks!) with my edits. I removed comments that were not actionable. > > I kept the names next to comments where additional clarifications are > > needed. If the notes are wrong, blame me for messing with the Brian's > > copy. > > > > Action items are marked with ***. > > > > Overall, I think by -09 we will be done with most of the comments > > (ready for another batch). > > > > EHL > > > > --- > > > > > Introduction: > > > > > > - Add purposes / use cases > > > - Describe how it relates to other authentication schemes (OpenID, > > > HTTP Auth) > > > - Move requirements out of the introduction > > > - Describe goals and possibilities > > > - Clarify that the listed requirements are not the only ones > > > > I'm generally happy with the current outline for the introduction. > > Those looking to address these points should submit text proposals. > > > > > Terminology: > > > > > > - Define client secret > > > > Client secret isn't a term but a detail of the client authentication > > process, especially with the way it is defined now. > > > > > - Describe relationship between terms > > > > The section has been restructured to add two levels of terms to show > > relationships. > > > > > - Add verification code > > > > The verification code was renamed to authorization code and added. > > > > > - Remove terminology references to HTTP terms > > > > Removed reliance on HTTP terminology. > > > > > - Add cryptographic terms > > > - User the term 'capability' when talking about bearer tokens > > > > Since the signature and cryptography was removed, these comments are > > no longer relevant for this draft. > > > > > Overview: > > > > > > - Does not related to the introduction (confusing) > > > > The overview section was written from scratch so hopefully it is less > > confusing. > > > > > - Standardization of tokens should be called out as defined > > elsewhere > > > - Explain that the separation between the authorization server and > > > resource server is out of scope > > > > Both will be clarified in -09. > > > > > - Flow grouping is confusing > > > > Since the flows have been incorporated into the introduction, and the > > grouping removed, the confusion should be resolved. > > > > > 3.2 End-user endpoint: > > > > > > - Rename 'end-user endpoint' to 'approval url' > > > > Renamed to 'end-user authorization endpoint'. > > > > > - No mandatory to implement language - interop problem (Peter St. > > > Andre) > > > > *** Please clarify what should be required. > > > > > - Does not mention user identity (how to verify) > > > > User identity is out of scope. Should be addressed by the proposed > > OpenID Connect work. > > > > > - When using TLS, make sure it's server authentication, not client > > > certificates (Eve Maler) > > > > *** Please propose language. > > > > > - 'user-uri' attribute is too experimental to be included > > > > Moved to discovery draft. > > > > > - Explain that the end-user endpoint is only relevant to some flows > > > > I think -08 makes this clear. > > > > > - Should standardize existing service provider specific > > parameters for > > > UI, e.g. language, display type, user hint > > > > Published in a separate UX draft. > > > > > 3.3 Token endpoint: > > > > > > - First sentence ("After obtaining authorization from the resource > > > owner") is not true for all flows > > > > I think the same issue exists in -08 but I'm not sure how to address > > it. Is it really a problem? > > > > > - Maybe change name to 'Token issuing endpoint' > > > > I think token endpoint is nice and short. > > > > > - MUST use SSL? > > > > Changed to "Servers MUST support TLS 1.2" and may support other stuff > > (equally strong) as well. > > > > > - Mandate POST? > > > > Yes. Otherwise secrets leak into log files. > > > > > 3.3.1 Client Authentication: > > > > > > - Need new text for certificate authentication > > > - Need more flexible language > > > > The latest draft fixes this by moving the client authentication out of > > the endpoints and into its own section. > > In addition, the client identifier and secret are given a name (basic > > client credentials) to make it easier to specify other ways to > > authenticate the client. > > > > > 3.3.2 Response Format: > > > > > > - Do we need so many formats? > > > - Are all formats needed on both sides? > > > > Solved by using just JSON for token endpoint responses. > > > > > - Is no-store enough of a cache-control header? (Chuck Mortimore) > > > > *** No idea. Is it? > > > > > 3.3.2.1 Access Token Response: > > > > > > - Define scope once, include by reference > > > > Don't even need to reference anymore. Defined in a single place. > > > > > - Need "scope" example (Hannes) > > > > *** It is hard to provide scope examples. Are there any scopes common > > in more than one OAuth 1.0 implementation? > > > > > - Scope is underspecified > > > > It is as specified as we have consensus for (even this was painful). > > > > > - Authorization server MUST honor client request for token secret? > > > > Since this is moved to an extension, the answer is no. > > > > > - Semantics of "expires_in" are underspecified > > > > Added example in -09. > > > > > 3.3.2.2 Error response: > > > > > > - Data format needs to be in sync across entire spec > > > > Now uses JSON like a successful response. > > > > > - Add debugging message field to JSON > > > > Debugging is out of scope, but feel free to write a proposal. > > > > > - Predefined list of error responses? > > > > New section added in -07. Still needs to add text to describe each > > error message, as well as make the list complete. > > > > > 3.4 Flow Parameters: > > > > > > - More on error handling? (Peter St. Andre) > > > > *** Not sure what this is about. > > > > > 3.5 User-Agent Flow: > > > > > > - If refresh token leaks, you can't recover. Changing > > client secret is not enough. > > > > No longer issuing refresh token in user-agent flow. > > > > > - Can we change order of user-agent and web app flow in spec? > > > > Done. > > > > > - WRAP web server flow was more secure for rich-client > > apps, because > > > web sites cannot pretend to be rich clients. User-Agent > > flow does not > > > allow this. (Sarah Faulkner) > > > > *** Please start a new thread to discuss. > > > > > - Where do we handle custom protocol schemes in redirect URIs? > > > > *** Currently mentioned in native application section. Need guidance > > from IESG on how to handle this so it will not become a blocking > > issue. > > > > > - Move installed applications to a separate section > > > > Done. > > > > > - Need to give installed app developers a way to specify > > device name > > > (Brian Eaton) > > > > *** Please propose text. > > > > > - Can mobile developers use HTTP URL discovery from slide deck > > > instead? (Bill Keenan) > > > > *** Need clarification. > > > > > - Explain how to authenticate the client. > > > > I think the new text is pretty clear, using a reference to the client > > authentication section. > > > > > 3.5.1 Client Requests Authorization: > > > > > > - What if malicious actor (either a user or "man in the browser") > > > tampers with "scope" or "state" parameter? (Eve Maler) > > > > Since the end-user gets to authorize the request, scope tempering > > shouldn't be a problem. As for state, I'm not sure. > > > > > - Should we add an extension so that users can self-identify their > > > device? (Bill Smith) > > > > *** Please propose text or start a discussion. > > > > > - Authorization servers MAY restrict the redirection URI to not > > > include a query component. This will break PHP clients > > > > This is part of the underspecified matching rules. I'll drop it for > > now. > > > > > 3.5.1.1 End-user grants authorization: > > > > > > - seems odd that client is requesting the token secret. > > > - what happens if server doesn't want to issue token secret? > > > > Removed. Still an open question for the signature spec. > > > > > - should we make example https? > > > > I don't think this is necessary since the fragment is not transmitted. > > > > > 3.5.1.2 End-user denies authorization: > > > > > > - More error codes needed (Sarah Faulkner and Marius Scurtescu) > > > > *** Please provide text. > > > > > - Immediate mode failure needs an error code > > > > Removed. Noted for when the parameter appears on another draft. > > > > > 3.5.2 Client extracts access token: > > > > > > - Can we tell user-agents not to send fragment in HTTP request? IE > > > does this in certain circumstances. > > > > HTTP tells that. It was made more explicit in the new HTTPbis work. > > Beyond that, not sure what we can do. > > > > > 3.6.1 Client Requests Authorization: > > > > > > - redirect_uri validation strategy should be described once > > in the spec, and then included by reference. > > > > Done. > > > > > - Some of the required parameters don't make sense if > > authentication > > > of user is out of band. (Eve Maler) > > > > The only required parameter there were 'client_id', 'type', and > > 'redirect_uri'. Which one are you referring to? > > > > > 3.6.1.1 - End-user grants authorization: > > > > > > - What does the verification code provide? > > > > I think the new text explains this (part of the abstraction layer > > provided by the access grant). Let me know if it still needs to be > > clarified. > > > > > - How do people keep verification code from leaking in referrer > > > header? (Sarah Faulkner) > > > > *** Is this an issue? Can you start a thread to discuss? > > > > > - Should we define time-limit for verification code? 5 minutes? > > > (Peter St. Andre) > > > > *** Open issue. > > > > > - Specify that verification code should be used only once > > > > Made even clearer in -09. > > > > > 3.6.2 - Client requests access token: > > > > > > - should mention https > > > > Done. > > > > [Device flow feedback removed] > > > > > 3.8 - Username and password flow: > > > > > > - need to return error URL from this flow, so that users > > can get their > > > account unblocked if they are on the same IP range as a > > botnet (Brian > > > Eaton) > > > > *** Please suggest text. > > > > > 3.10 - Assertion Flow: > > > > > > - we need an example > > > > Done. > > > > > - Two format parameters > > > > Fixed. > > > > > 4 - Refresh Token: > > > > > > - should we alway tell clients to use a secret, e.g. "anonymous" or > > > "opensecret"? Absent secret might be confusing? (Brian Eaton) > > > > *** Please clarify. > > > > > - Should we allow down-scoping on this endpoint? > > > > -08 adds support for down-scoping. > > > > > - Scope needs to be figured out through entire flow (Eve Maler) > > > > *** -08 tries to clean up scope handling. Please review. > > > > > 5 - Accessing a protected resource: > > > > > > - No clear error path > > > > Noted. To be addressed in -09. > > > > > - Should the authentication scheme name be called 'Token'? > > > > I think so. Those who disagree are welcome to start a discussion. > > > > > - Can we say "bearer tokens" MUST NOT be sent over secure channels? > > > (Jim Fenton) > > > > I would like that but consensus was that SHOULD NOT is the strongest > > we can specify. > > > > > - Can we write a spec that reflects security reality - > > people do send > > > bearer tokens over HTTP connections > > > > We did :-( > > > > > - Can we say MUST NOT send bearer tokens to unfamiliar sites? > > > > Done in -09. > > > > > - Is "unfamiliar" well-defined? > > > > I think it is in the context of the spec - not hardcoded into the > > client. > > > > > - Can we have a same-origin policy? > > > > This needs to be addressed in the discovery spec. James' > > propose 'sites' parameter is one approach. > > > > > 5.2 - Bearer Token Requests: > > > > > > - We should drop realm, it has no meaningful semantics here > > > > *** I will float this past the HTTP folks to gage their reaction. > > > > > 6.1 - WWW-Authenticate Response header: > > > > > > - what about resources that return public data if request > > is unauthenticated? POST vs GET might have different security policy. > > > > *** Need to look into this. > > > > > 6.1.1. - describing the WWW-Authenticate response header > > > > > > - Discovery needed for various elements > > > > Yes. That's for the discovery 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
