I think the use cases are pretty well understood (the issue here was not lack of use-case understanding).
Basically, when it comes to client and server deployment, you can have one-to-one, one-to-many, many-to-one, and many-to-many. Each setup presents is own challenges on how to produce unique nonces on the client side (for all requests with the same MAC credentials / access token), and how to store and check on the server side. Once you go beyond one-to-one, it can be extremely hard (which is why most large providers don't check it). The discussion here was mostly about the "matter of logic"... which is never as easy as it should be. :-) EHL > -----Original Message----- > From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > Sent: Tuesday, May 31, 2011 11:14 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > No, no, my little "I told you so" aside, I don't insist on putting this in the > document, especially that we have already agreed that the use case > document is a post-2.0 issue. > > I think that for the purposes of the discussion on this thread it would help > if > all the use cases in question were clearly described--if only in an e-mail for > now. Then it would be a matter of logic to see if there is a problem, and if > there is one, what the solutions to it might be. > > Igor > > Eran Hammer-Lahav wrote: > > They are coming in 2-3 directions, the use case isn't really clear (other > > than > claims of some flavors being harder than others), and overall this is more > about general HTTP authentication than OAuth use cases. Don't get me > wrong - if you want to put the effort in to capture these, go ahead. I just > think this isn't worth the effort in a formal document. > > > > EHL > > > > > >> -----Original Message----- > >> From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] > >> Sent: Tuesday, May 31, 2011 6:15 PM > >> To: Eran Hammer-Lahav > >> Cc: Phil Hunt; OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >> token > >> > >> Maybe... But this information must be captured somewhere, right? > >> > >> At the moment, there seems to be no record of and consequently no > >> reference point to the use case in question. And this is what has > >> created all this discussion--with messages coming from all directions. > >> > >> Igor > >> > >> Eran Hammer-Lahav wrote: > >> > >>> I think the use case document should focus on v2, not on MAC. At > >>> some > >>> > >> point, it becomes impractical to keep every use case discussed on > >> this list recorded. > >> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Igor Faynberg > >>>> Sent: Tuesday, May 31, 2011 3:50 PM > >>>> To: Phil Hunt > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC > >>>> token > >>>> > >>>> ...Sorry to turn the question around so as to underline my pet peeve: > >>>> Have we *documented* all cases? (This is what the Use Cases > >>>> document is supposed to be all about.) > >>>> > >>>> Just to clarify: I am not arguing with Phil's point now. I just > >>>> stress that as of this moment we don't have anything to check against. > >>>> > >>>> Igor > >>>> > >>>> Phil Hunt wrote: > >>>> > >>>> > >>>>> There seems to be a demonstrated need for both age and timestamp > >>>>> > >>>>> > >>>> tokens. > >>>> > >>>> > >>>>> The list has 2 separate cases with 2 separate proposals that do > >>>>> not solve all > >>>>> > >>>>> > >>>> cases. > >>>> > >>>> > >>>>> Can we at least agree that neither proposal works in all cases? > >>>>> > >>>>> Phil > >>>>> > >>>>> @independentid > >>>>> www.independentid.com > >>>>> phil.h...@oracle.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 2011-05-31, at 2:41 PM, Adam Barth wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> You haven't described a problem. > >>>>>> > >>>>>> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward > >>>>>> <sky...@kiva.org> > >>>>>> > >>>>>> > >>>> wrote: > >>>> > >>>> > >>>>>>> First we should agree on a common understanding of the spec. The > >>>>>>> > >>>>>>> > >>>> reason why age works with unsynchronized clocks is that the client > >>>> determines issue_date based on the time when it receives the token > >>>> over the wire. This depends on the server and client both recording > >>>> time this way and for the transmission of the token to be be not > >>>> longer than the margin of error for validating age. Are we agreed > >>>> on this > >>>> > >> understanding? > >> > >>>>>> That's not correct. > >>>>>> > >>>>>> The age allows the server to protect against replay attacks in > >>>>>> bounded memory. With unbounded memory, the server can just > >>>>>> > >>>>>> > >>>> remember > >>>> > >>>> > >>>>>> every nonce it has ever seen associated with a given key and > >>>>>> reject > >>>>>> > >>>>>> > >>>> replays. > >>>> > >>>> > >>>>>> With bounded memory, the server eventually needs to evict some > of > >>>>>> these nonces due to memory pressure. The age value lets the > >>>>>> server reject the nonces with the smallest age values first. The > >>>>>> server then rejects any messages with age values smaller than (or > >>>>>> equal > >>>>>> to) the largest age value it has ever evicted for the given key. > >>>>>> > >>>>>> Notice that neither clock synchronization nor transmission time > >>>>>> plays a role in that implementation. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> The easiest case for me to explain here is client credentials > >>>>>>> because I > >>>>>>> > >>>>>>> > >>>> have to assume you've built and registered a Twitter app at some > >>>> point (or similar OAuth 1.0a app). You registered your app on the > >>>> site and were issued a client_id and client_secret (called > >>>> consumer_key and consumer_secret in 1.0). You then embedded > these > >>>> values in your client (they were not issued programmatically to > >>>> your app). Assuming the MAC token algorithm is used then for > >>>> establishing client identity (originally one of the uses we, the > >>>> working group, hoped MAC would cover) how then will your client > determine issue date? > >>>> > >>>> > >>>>>> I recommend the date at which the developer obtained the > >>>>>> credential from Twitter because that is the date when the credential > was issued. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> After we can establish where you're at on the two above points > >>>>>>> I'll > >>>>>>> > >>>>>>> > >>>> continue with the explanation. But as a preview, the next points > >>>> would > >>>> > >> be: > >> > >>>>>>> - If issue_date comes form the server, how is it translated to > >>>>>>> the > >>>>>>> > >> client? > >> > >>>>>>> > >>>>>> The issue_date does not come from the server. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> - If you use a server provided issue_date, how do you then > >>>>>>> translate > >>>>>>> > >>>>>>> > >>>> that a value relative to the local unsyncronized clock? > >>>> > >>>> > >>>>>> The server does not provide the issue_date. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> - If your answer to that is to also provide the current server > >>>>>>> time to the > >>>>>>> > >>>>>>> > >>>> client so the offset on the server provided issue_date can be > >>>> calculated what is the difference between all of these values and > >>>> just > >>>> > >> using timestamp? > >> > >>>>>> My answer is not to provide the current server time to the client. > >>>>>> > >>>>>> Kind regards, > >>>>>> Adam > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> So don't get wrapped up in those 3 questions until we establish > >>>>>>> your > >>>>>>> > >>>>>>> > >>>> contextual understanding of the first two paragraphs. Feel free to > >>>> also respond to me off the list so we don't trouble everyone else > >>>> with us getting on the same page (the reason, I thought, why a > >>>> Skype call would be more efficient and painless). I do think my > >>>> explanations all have been very clear thus far. There must be a > >>>> contextual confusion that is keeping us from a common understanding > >>>> of > >>>> > >> the terminology or the use cases. > >> > >>>>>>> skylar > >>>>>>> > >>>>>>> > >>>>>>> On May 31, 2011, at 10:30 AM, Adam Barth wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> I'm not sure we need a Skype call. Can you explain the trouble > >>>>>>>> caused by age clearly? I didn't understand your previous > >>>>>>>> explanation. The more concrete you can be, the better. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Adam > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward > >>>>>>>> <sky...@kiva.org> > >>>>>>>> > >>>>>>>> > >>>> wrote: > >>>> > >>>> > >>>>>>>>> It seems we're failing to communicate. Or you're not > >>>>>>>>> understanding > >>>>>>>>> > >>>>>>>>> > >>>> my use cases. Age doesn't "just" work. It only works for a limited > >>>> number of uses cases that must include all of yours - and it is > >>>> brittle at that. It doesn't work for any of our uses cases (where > >>>> the client can't know issue_date w/o the server telling it - in > >>>> which case we have the equivalent problem as timestamp). > >>>> > >>>> > >>>>>>>>> If you'd like to talk this out over Skype I'm happy to do > >>>>>>>>> that, so I can > >>>>>>>>> > >>>>>>>>> > >>>> help you understand why age doesn't work. > >>>> > >>>> > >>>>>>>>> On May 31, 2011, at 9:47 AM, Adam Barth wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Timestamps don't work when the client doesn't have a > >>>>>>>>>> synchronized clock. It's true that a client could > >>>>>>>>>> synchronize its clock with the network, but our > >>>>>>>>>> implementation experience is that many clients don't for a > >>>>>>>>>> variety of reasons. That means that age better because, you > know, it works. > >>>>>>>>>> > >>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward > >>>>>>>>>> > >>>>>>>>>> > >>>> <sky...@kiva.org> wrote: > >>>> > >>>> > >>>>>>>>>>> I don't think you read my first message on the topic (or I > >>>>>>>>>>> wrote too > >>>>>>>>>>> > >>>>>>>>>>> > >>>> much). > >>>> > >>>> > >>>>>>>>>>> Age is fragile because if the clock changes between > >>>>>>>>>>> issue_date and > >>>>>>>>>>> > >>>>>>>>>>> > >>>> the time of submission, it will fail. We know many people don't > >>>> have synchronized clocks, but using age only solves this problem if > >>>> two assumptions hold true: > >>>> > >>>> > >>>>>>>>>>> 1) the client is able to guess the issue_date the server is > >>>>>>>>>>> using based on the time the credential was issued > >>>>>>>>>>> 2) the client system clock doesn't change between issue date > >>>>>>>>>>> and > >>>>>>>>>>> > >>>>>>>>>>> > >>>> submission time. > >>>> > >>>> > >>>>>>>>>>> Timestamp has neither of these issues because the client can > >>>>>>>>>>> > >>>>>>>>>>> > >>>> always inquire about network time and can effectively correct for > >>>> inaccuracies in the device timekeeping system. > >>>> > >>>> > >>>>>>>>>>> Regarding the first assumption, this fails when a token > >>>>>>>>>>> might be re- > >>>>>>>>>>> > >>>>>>>>>>> > >>>> issued between devices. An example is that we use MAC token for the > >>>> client credentials, which are issued when a developer registers an > >>>> application. The client has no way of determining on its own when > >>>> the value was actually issued (unless we communicate that on the > >>>> developer website and force users to embed that with client_id, > >>>> which adds usability issues of users copying and entering string > >>>> date values correctly). The same is actually true for all of our > >>>> OAuth access tokens because we reissue tokens to the same client_id > >>>> if they were previously issued and are still valid. (The client > >>>> would thus think the issue_date was now() when if fact it was the > >>>> time of the first issue for client_id+scope+grantor_id). Thus, age > >>>> is really just a > >>>> > >> convoluted way of trying to communicate the device system offset: > >> > >>>>>>>>>>> local_offset = current_server_time - current_device_time > >>>>>>>>>>> age = current_device_time - > >>>>>>>>>>> (server_issue_date-local_offset) > >>>>>>>>>>> > >>>>>>>>>>> Since the protocol doesn't currently allow for > >>>>>>>>>>> server_issue_date to > >>>>>>>>>>> > >>>>>>>>>>> > >>>> be given with tokens, thus age currently can't have the resilience > >>>> that timestamp does. It also forces servers to issue new tokens on > >>>> demand just to make the convoluted age system work (rather than > >>>> reuse existing valid tokens). Or, you have to modify the protocol > >>>> to add server_issue_date and current_server_time into the > >>>> token-issue > >>>> > >> exchange - eg, more complexity. > >> > >>>>>>>>>>> Timestamp is simpler, proven, it and it has a solution for > >>>>>>>>>>> your use > >>>>>>>>>>> > >>>>>>>>>>> > >>>> case of unsyncronized clocks. > >>>> > >>>> > >>>>>>>>>>> skylar > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On May 30, 2011, at 9:08 AM, Adam Barth wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> I can't speak for Mozilla, but I can tell you that many > >>>>>>>>>>>> folks don't have synchronized clocks, for a wide variety of > reasons. > >>>>>>>>>>>> I guess I don't really understand why you view age as > >>>>>>>>>>>> problematic. You reference "fragility of using > >>>>>>>>>>>> time-since-credentials-issued" but you don't say what > >>>>>>>>>>>> exactly is fragile about it. There's nothing particularly > >>>>>>>>>>>> complex about age, especially when using the monotonic > >>>>>>>>>>>> clock provided by > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> all modern operating systems. > >>>> > >>>> > >>>>>>>>>>>> Adam > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> <sky...@kiva.org> wrote: > >>>> > >>>> > >>>>>>>>>>>>> But see, now you are specializing the use of MAC token > >>>>>>>>>>>>> even > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> more - now it's becoming a service mainly for user-agents on home > >>>> desktops? This is further for the original goal of making MAC as > >>>> flexible is possible. In this case you should change the spec name > >>>> to > >>>> > >>>> > >> > MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FI > >> > >>>> REFOX - or MTBCRLF for short. > >>>> > >>>> > >>>>>>>>>>>>> Sarcasm aside, my point is that timestamp is just as good > >>>>>>>>>>>>> as your > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> offset technique and is more: reliable, straightforward, flexible. > >>>> > >>>> > >>>>>>>>>>>>> User agents that care about creating robust behavior for > >>>>>>>>>>>>> home > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> desktops or mobiles (presumably of users and OS not yet > >>>> sophisticated enough to check network time on their own) should be > >>>> advised to do clock correction on their own (by pinging a time > >>>> service) and trusting the device clock alone. > >>>> > >>>> > >>>>>>>>>>>>> Please change the spec back to using timestamp rather > than > >>>>>>>>>>>>> > >> age. > >> > >>>>>>>>>>>>> I'd also like to hear a convincing argument from the > >>>>>>>>>>>>> Mozilla > >>>>>>>>>>>>> co- > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> authors about why they think that age is more resilient than the > >>>> above (I believe it is not) and further more why they would find > >>>> the above unattractive or difficult to implement in a modern user- > agent. > >>>> > >>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> skylar > >>>>>>>>>>>>> > >>>>>>>>>>>>> ... -.- -.-- .-.. .- .-. - .-- --- --- -.. .-- .- .-. -.. > >>>>>>>>>>>>> - ... -.- -.-- .-.. .- .-. - .- > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> - --- --- -.. .-- .- .-. -.. > >>>> > >>>> > >>>>>>>>>>>>> skylar woodward > >>>>>>>>>>>>> Kiva Developer Program / build.kiva.org / @buildkiva > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Any kind of clock sync requirement for user-agents > >>>>>>>>>>>>>> (basically, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> home desktops) it completely impractical. The added complexity > >>>> pales in comparison to the difficulty of trying to use timestamps > >>>> and any kind of clock sync. No window will be big enough as > >>>> experience shows some users have closes that are off by more than an > hour and a half. > >>>> > >>>> > >>>>>>>>>>>>>> The issue here is who is this being optimized for. > >>>>>>>>>>>>>> Server-to- > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> server communication should simply use TLS for privacy and MITM > >>>> protection on top of MAC instead of using nonces to prevent replay. > >>>> The whole point of this kind of replay protection is when TLS is > >>>> not > >>>> > >> available. > >> > >>>>>>>>>>>>>> I think a better approach is to simply make checking the > >>>>>>>>>>>>>> nonce > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> optional when TLS is used. > >>>> > >>>> > >>>>>>>>>>>>>> EHL > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: oauth-boun...@ietf.org [mailto:oauth- > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> boun...@ietf.org] > >>>> > >>>> > >>>>>>>>>>>>>>> On Behalf Of Peter Wolanin > >>>>>>>>>>>>>>> Sent: Sunday, May 29, 2011 6:53 PM > >>>>>>>>>>>>>>> To: Skylar Woodward > >>>>>>>>>>>>>>> Cc: OAuth WG > >>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> element - > >>>> > >>>> > >>>>>>>>>>>>>>> MAC token > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am also concerned by the fragility of using > >>>>>>>>>>>>>>> time-since-credentials-issued, and also the added > >>>>>>>>>>>>>>> complexity > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> of specifying this construction. > >>>> > >>>> > >>>>>>>>>>>>>>> I think it would be preferable to always require a > >>>>>>>>>>>>>>> timestamp as part of the authorization header, and > maybe > >>>>>>>>>>>>>>> even include in the spec a maximum time difference > >>>>>>>>>>>>>>> > >> between > >> > >>>>>>>>>>>>>>> client and server (e.g. 900 seconds) that can be > >>>>>>>>>>>>>>> tolerated. This makes generating the nonce easier also, > >>>>>>>>>>>>>>> since the value need to > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> longer be unique over all time. > >>>> > >>>> > >>>>>>>>>>>>>>> We have such rules in place for an HMAC-based > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> authentication > >>>> > >>>> > >>>>>>>>>>>>>>> system we use. Once in a while a client has a local > >>>>>>>>>>>>>>> clock so far out of sync that there is an issue, but it's > >>>>>>>>>>>>>>> rare. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -Peter > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward > >>>>>>>>>>>>>>> <sky...@kiva.org> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Resending to the list from my subscribed account... > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Begin forwarded message: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> From: Skylar Woodward <sky...@larw.com> > >>>>>>>>>>>>>>>>> Date: May 23, 2011 6:14:00 PM PDT > >>>>>>>>>>>>>>>>> To: Skylar Woodward <sky...@kiva.org> > >>>>>>>>>>>>>>>>> Cc: Eran Hammer-Lahav <e...@hueniverse.com>, > >>>>>>>>>>>>>>>>> > >> OAuth > >> > >>>> WG > >>>> > >>>> > >>>>>>>>>>>>>>>>> <oauth@ietf.org> > >>>>>>>>>>>>>>>>> Subject: Re: [OAUTH-WG] issues with token age > >>>>>>>>>>>>>>>>> > >> element - > >> > >>>>>>>>>>>>>>>>> MAC token > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> So after discussing this today and reflecting on it a > >>>>>>>>>>>>>>>>> bit, I would suggest that > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> nonce simply be the "unique value" (as it is so named) > >>>>>>>>>>>>>>> without further requirements. It might be suggested > that > >>>>>>>>>>>>>>> this be composed of an > >>>>>>>>>>>>>>> random+timestamp (not age) value, but that seems > more > >>>>>>>>>>>>>>> > >> of a > >> > >>>>>>>>>>>>>>> random+MAY or > >>>>>>>>>>>>>>> "recommended" practice. If the expectation is that very > >>>>>>>>>>>>>>> few if any providers would actually check the timestamp > >>>>>>>>>>>>>>> (or moreover, the nonce itself), why add terminology in > >>>>>>>>>>>>>>> the draft that requires it? Developers are doing extra > >>>>>>>>>>>>>>> housekeeping (and perhaps for a perceived benefit) but > >>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> no payoff or added security. > >>>> > >>>> > >>>>>>>>>>>>>>>>> I'm sending this feedback based on having > implemented > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>> the > >>>> > >>>> > >>>>>>>>>>>>>>>>> v3-5 changes > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> last night (for both client credentials and requests w/ > >>>>>>>>>>>>>>> access tokens). After the changes, the nonce creation is > >>>>>>>>>>>>>>> now the most complicated part of the normalized > request > >>>>>>>>>>>>>>> string > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> and yet these changes offer the least benefit. > >>>> > >>>> > >>>>>>>>>>>>>>> What's most important is that nonces are unique on each > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> request for an ID. > >>>> > >>>> > >>>>>>>>>>>>>>>>> There are issues with age as well: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> - As Bill mentioned, if the client stores the issue > >>>>>>>>>>>>>>>>> time based on receipt, then the internal clock changes > >>>>>>>>>>>>>>>>> (presumably w/o knowledge of the software storing > the > >>>>>>>>>>>>>>>>> dates) then time will also fail. Assuming that a user > >>>>>>>>>>>>>>>>> with a bad clock (of by hours or more) will never fix > >>>>>>>>>>>>>>>>> it and actually encourages bad user behavior (don't > >>>>>>>>>>>>>>>>> fix your clock or Twitterbot will stop working!). > >>>>>>>>>>>>>>>>> Though we say that timezones won't bring about the > >>>>>>>>>>>>>>>>> situation of changed clock, I'd be to differ. Many > >>>>>>>>>>>>>>>>> users aren't savvy enough to change time zone, but > >>>>>>>>>>>>>>>>> just adjust the time to local time anyway. Users who > >>>>>>>>>>>>>>>>> are more likely to get it right already have auto > >>>>>>>>>>>>>>>>> clock sync enabled (via web, mobile, etc.) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> - What if the token wasn't originally issued > >>>>>>>>>>>>>>>>> programmatically? In this case, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> the issue time has to be obtained from the server and > >>>>>>>>>>>>>>> stored on the client then you have the same problem as > >>>>>>>>>>>>>>> with a timestamp - the client clock is not sync'd to the > >>>>>>>>>>>>>>> server clock and there is no adjustment. You want this > >>>>>>>>>>>>>>> to apply to uses outside of just OAuth, but now > >>>>>>>>>>>>>>> requiring the client to be able to determine an issue > >>>>>>>>>>>>>>> time based on when it receives > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> an HTTP request necessarily limits the types of token flows for > >>>> which this can be used. > >>>> > >>>> > >>>>>>>>>>>>>>>>> - It's one more detail to store. Hardly an issue for a > >>>>>>>>>>>>>>>>> developer, but it is > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> inelegant. It's like having a double ID. Yet it's not an > >>>>>>>>>>>>>>> ID, it is actually more of a recording of "my personal > >>>>>>>>>>>>>>> clock offset value" but obfuscated several times over > >>>>>>>>>>>>>>> (one for each > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> token) as issue_date. > >>>> > >>>> > >>>>>>>>>>>>>>>>> - This implementation assumes software programs > use > >>>>>>>>>>>>>>>>> > >> the > >> > >>>>>>>>>>>>>>>>> computer > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> internal clock exclusively for timestamp. A robust > >>>>>>>>>>>>>>> program that is dependent on accurate timestamps > would > >>>>>>>>>>>>>>> ping the origin server (or similar trusted time > >>>>>>>>>>>>>>> authority) to ask it the current time. Then it could > >>>>>>>>>>>>>>> store a "my device clock offset" value for the lifetime > >>>>>>>>>>>>>>> of the program execution. All requests needing > timestamp > >>>>>>>>>>>>>>> would > >>>>>>>>>>>>>>> > >> be > >> > >>>>>>>>>>>>>>> adjusted accordingly. For age, if the clock is changed > >>>>>>>>>>>>>>> since the > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> stored issue_date, the problem can't be corrected in this manner. > >>>> > >>>> > >>>>>>>>>>>>>>> Thus, a significant advantage for timestamp. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> All in all, this seems like a misguided but > >>>>>>>>>>>>>>>>> well-intentioned attempt to get > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> around end-user issues of mis-set clocks. It feels like > >>>>>>>>>>>>>>> a hack and it certainly isn't a foolproof solution. The > >>>>>>>>>>>>>>> more I think about the implications of the age > >>>>>>>>>>>>>>> parameter, the less I like it. Timestamp has been used > >>>>>>>>>>>>>>> for many years in the industry and with reasonable > >>>>>>>>>>>>>>> success in relevant applications. If we change to a new > >>>>>>>>>>>>>>> way of trying to sync on > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> time I think we run a greater risk of stumbling upon unforeseen > >>>> issues, such as those outlined above. > >>>> > >>>> > >>>>>>>>>>>>>>>>> I recommend the requirement of an age (or > timestamp > >>>>>>>>>>>>>>>>> > >> for > >> > >>>>>>>>>>>>>>>>> that matter) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> be dropped from the nonce construction. For providers > >>>>>>>>>>>>>>> > >> that > >> > >>>>>>>>>>>>>>> deem it valuable, timestamp can be an optional value > >>>>>>>>>>>>>>> (either as part of the nonce or the overall header, as > >>>>>>>>>>>>>>> > >> before). > >> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> skylar > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> You may have noticed, on page 8 the host is listed as > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>> "example.net" > >>>> > >>>> > >>>>>>>>>>>>>>>>>> - should be example.com, I believe. (draft v5) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> All in all, I'm in support of the changes in v2. > >>>>>>>>>>>>>>>>>> Certainly addresses my > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> hesitations from v2. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> skylar > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav > >>>>>>>>>>>>>>>>>> > >> wrote: > >> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> (Please discuss this draft on the Apps-Discuss > >>>>>>>>>>>>>>>>>>> <apps-disc...@ietf.org> mailing list) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2- > >>>>>>>>>>>>>>>>>>> > >> mac- > >> > >>>> tok > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> en > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> While this document has moved to the Apps- > Discuss > >>>>>>>>>>>>>>>>>>> mailing list for the > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> time being, I wanted to give a quick update to those who > >>>>>>>>>>>>>>> have been following this draft which originated on this > list. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> The major changes since -02 are: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * Removed OAuth terminology and association. > The > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>> draft > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> is now a > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> general purpose HTTP authentication scheme. It does > >>>>>>>>>>>>>>> include an OAuth 2.0 binding which is described in less > >>>>>>>>>>>>>>> than > >>>>>>>>>>>>>>> > >> a page. > >> > >>>>>>>>>>>>>>> One suggestion would be to move section 5.1 into the > >>>>>>>>>>>>>>> > >> OAuth > >> > >>>>>>>>>>>>>>> specification and drop all the OAuth 2.0 text from the > >>>>>>>>>>>>>>> MAC > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> draft. > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> * Added 'Set-Cookie' extension for using MAC with > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>> session cookies. > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> * Removed request URI query normalization. The > new > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>> draft > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> uses the > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> raw request URI unchanged. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * Replaced timestamps with credentials age to > >>>>>>>>>>>>>>>>>>> > >> remove > >> > >>>> the > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> need for > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> clock sync. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * Added a placeholder for extension, allowing > random > >>>>>>>>>>>>>>>>>>> text to be > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> included in the request and MAC. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * Added issuer attribute for identifying the source > >>>>>>>>>>>>>>>>>>> of the credentials as > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> an additional protection. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Draft -04 is not compatible with previous drafts. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> EHL > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>> _______________________________________________ > >>>> > >>>> > >>>>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> Peter M. Wolanin, Ph.D. : Momentum Specialist, > Acquia. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> Inc. > >>>> > >>>> > >>>>>>>>>>>>>>> peter.wola...@acquia.com : 978-296-5247 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> "Get a free, hosted Drupal 7 site: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> http://www.drupalgardens.com"; > >>>> > >>>> > >> _______________________________________________ > >> > >>>>>>>>>>>>>>> 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
