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
