> -----Original Message----- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Tuesday, May 31, 2011 11:03 PM > To: Eran Hammer-Lahav > Cc: igor.faynb...@alcatel-lucent.com; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Eran, sorry, where should use cases be officially documented?
This list seems a fine enough place. I have no problem keeping track. > I assume the use cases being more like "HTTP Auth" are not in reference to > the ones I've been describing. For my part, I'm focused on OAuth use cases. > Both that of a single token being used on multiple devices (or app instances) > and that of tokens being presented for client credentials in the OAuth flow. I > thought we had already agreed from a previous thread that the MAC token > spec should be extensible beyond just use of access tokens and at least to > that of client credentials. Useful for, yes. Extensible, no. The only extensible part if the choice of algorithm. > skylar > > > On Jun 1, 2011, at 7:54 AM, 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
