Actually, monotonically increasing fails for this use case because even if clocks are sync'd, device A and B can submit requests sequentially in UTC time but could arrive in reverse order.
So monotonically increasing, with some tolerance or window of error would seem to be sufficient for allowing the server to expire nonces yet accounting for the complications of multiple devices presenting the same token. If providers were left to determine the window of error (which is really just a way of the provider controlling allocations for nonce storage) then it could accommodate for minor variances in device system time as before as well. skylar On Jun 1, 2011, at 9:24 AM, Adam Barth wrote: > Sounds like Eran's proposal will work fine for this scenario. > MegaWorld for iOS can just do what you suggest in the final paragraph, > which meets the new requirements for age. I'm glad we're able to > address you use case. > > Thanks, > Adam > > > On Wed, Jun 1, 2011 at 12:15 AM, Skylar Woodward <sky...@kiva.org> wrote: >> Provider: api.megaworld.com >> >> Software Program: A universal binary iOS app called MegaWorld for iOS >> Client ID: mega_app >> >> User: Frankie in London >> Username: frankie_uk >> >> Device A: Frankie's iPhone >> Device B: Frankie's iPad >> >> Now imagine MegaWorld for iOS installed on device A & B. Client ID is the >> same across the two devices. >> >> - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS >> to access his account (frankie_uk) >> - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time >> on device A is 1306911444. >> - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS >> to access his account (frankie_uk) >> - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time >> on device B is 1275375611. >> >> The provider, mega_app, does not issue multiple tokens for the same grant >> request (scope, client_id). This simplifies provider implementation but also >> helps enforce the correct user UI with respect to credential control at >> http://megaworld.com/my/apps - that is, the provider can't accurately know >> if frankie_uk has authorized one software instance twice on the same device, >> or multiple software instances once each (across multiple devices). Thus, >> the my/apps UI shows one authorization for "Megaworld for iOS" and thus one >> option to de-authorize this client_id (and thus all installed instances of >> the single software program with ID mega_app). >> >> Regardless if age or timestamp is used, if the implementation for validating >> the time value is sequential (perhaps with some window of error) then one >> device will have all its OAuth requests rejected as soon as the other >> presents a request. If timestamps are used the one with the older clock >> (device B) is rejected. If age is used, the one with the highest value of >> time (in this case, the more correct client) will be rejected as age will be >> calculated to be smaller than device B with an incorrect clock. >> >> If you also consider the case where device A and B have the same value for >> current time (UTC time, let's say) then age fails for device B after device >> A submits a request since device B thinks the credential is younger than >> device A. Timestamp does not fail in this case (because clocks are already >> sync'd). >> >> Only when the timestamp is a unified standard like UTC can both device A and >> B both use token 89ARC. If client B has it's request rejected it can quickly >> check UTC from any reasonable source (including api.megaworld.com) to >> correct its clock. Even better, it can politely check the correct system >> time on a regular basis and cache the offset between UTC and device time. >> Though experience may show that many software developers don't currently do >> this clock correction, it is trivial to adopt as a best practice. (Many >> software developer also don't routinely review their software for security >> or stability vulnerabilities of any sort.) Certainly is nothing for the >> small percentage of well-written high-value clients such as Firefox, >> TweetDeck or any serious effort with even moderate distribution or >> engineering resources. >> >> skylar >> >> >> On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: >> >>> This is not true. >>> >>> The age value has to be monotonically increasing, but not necessarily >>> unique. Really, any counter will do. The reason why timestamp isn't any >>> better than age or sequence is because ultimately, it is the server's >>> memory restriction which determines the nonces storage size, not anything >>> else (like a time limit). >> >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
