Really? Can you point me to the email where he explains what the actual problem is?
Adam On Tue, May 31, 2011 at 4:23 PM, Phil Hunt <phil.h...@oracle.com> wrote: > I think Skylar has made his case that age isn't sufficient for his needs. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-05-31, at 3:49 PM, Igor Faynberg wrote: > >> ...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_FIREFOX >>>>>>>>>>> - 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 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-token >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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