That killer argument again. I allways tend to overestimate the skills of the developer. Thanks.
-Axel -----Original Message----- From: David Recordon [mailto:record...@gmail.com] Sent: Tuesday, June 15, 2010 5:51 PM To: Nennker, Axel Cc: e...@hueniverse.com; oauth@ietf.org Subject: Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates) Hey Axel, We had previously decided (I can try to dig up the link) that relative times will be easier for client developers. It means no timezone handling but being able to store the expiration as time() + expires_in. No, it's not going to be perfect to the second but the AS could always send an expires_in that is 5? seconds shorter than reality. --David On Tue, Jun 15, 2010 at 6:10 AM, <axel.nenn...@telekom.de> wrote: > > During the meeting we had a (short) discussion about the expires_in parameter. > I propose to change it to a notonorafter parameter with a GMT/UTC date as > value. > If the time slew between server is bigger or nearly equal to the life time of > the expires_in value than the token receiver has no chance to detect that the > token is dead on arrival. > Or we could keep the name expires_in but change the value from a relative > unit (seconds) to a absolute one (Date) > > -Axel > > expires_in > OPTIONAL. The duration in seconds of the access token lifetime. > > notonorafter > OPTIONAL. Specifies the time instant at which the assertion has > expired in universal time coordinates. > > Example > notonorafter="2007-08-21T08:18:50.605Z" > > > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Tuesday, June 15, 2010 8:35 AM > To: OAuth WG (oauth@ietf.org) > 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 > 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
