[OAUTH-WG] Secure storage of access for clients of the implicit flow

2011-09-30 Thread Doug Tangren
What is the recommended practice for storing access tokens for clients of the implicit flow. You don't really want to store it in a cookie because it will be send with every request to the server. There is html local storage but I don't know how sandboxed that is from other scripts on a given page.

Re: [OAUTH-WG] Possible alternative resolution to issue 26

2011-09-30 Thread Eran Hammer-Lahav
Two observations: - I doubt anyone is going to implement RFC 5987 in most OAuth 2.0 libraries, mostly because it offers little value and, - No one really needs scope values other than limited ASCII or URIs There should not be any interoperability issues with the error_descrip

Re: [OAUTH-WG] Possible alternative resolution to issue 26

2011-09-30 Thread Mike Jones
Thus far, I've received no responses preferring 1 or 2 or preferring A or B. Could people please weigh in so that the working group has data to base a decision on to close this issue? Thanks,

Re: [OAUTH-WG] Possible alternative resolution to issue 26

2011-09-30 Thread Julian Reschke
On 2011-09-30 14:03, Buhake Sindi wrote: Hi everyone, As for encoding, my understanding is that the scope parameter were scope fields provided by the service provider and that scope should match the service provider scope. Fair enough, we could argue that non-UTF-8 characters can't be sent over

Re: [OAUTH-WG] Possible alternative resolution to issue 26

2011-09-30 Thread Buhake Sindi
Hi everyone, As for encoding, my understanding is that the scope parameter were scope fields provided by the service provider and that scope should match the service provider scope. Fair enough, we could argue that non-UTF-8 characters can't be sent over HTTP response headers, so a better solution