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
