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

Reply via email to