Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

Brian, > There are actually a bunch of fundamentally conflicting requirements > for signatures from the various folks contributing to this working > group. > ... > For the record, I think *every single one* of those requirements makes > sense in certain contexts. I agree. >... we're going to hav

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

sounds reasonable Are your working on the cryptographic primitives and such profiles? regards, Torsten. Am 30.05.2010 23:41, schrieb Brian Eaton: On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt wrote: Regarding client secrets: One of the major obstacles when using OAuth 1.0 in lar

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Nat, > All the request parameters MUST be provided through request file. "All" doesn't make much sense if params can still appear in the URI, and override the file. > The "request_url" MUST be provided in the URL. This isn't really a "MUST", its just indicates if you are using this feature (t

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt wrote: > Regarding client secrets: One of the major obstacles when using OAuth 1.0 in > large deployments is the need for sharing client secrets between authz > server and resource server. Overcoming that obstacle was an important > requirement

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

Encrypting the token secret in self-contained tokens is the obvious solution, from my point of view. That's the way such things are handled in Kerberos. Regarding client secrets: One of the major obstacles when using OAuth 1.0 in large deployments is the need for sharing client secrets between

Re: [OAUTH-WG] Should replay of access token request be allowed?

I think so. In WRAP the verification code was RECOMMENDED one time use. On 2010-05-30, at 9:38 AM, Andrew Arnott wrote: > I was reviewing 3.6.2. Client Requests Access Token and it occurred to me > that there's no requirement in the spec (that I can find) that a given > callback URI and verifi

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

The advantage over using token secrets as it seems to me is that neither auth server nor resource server need to store any issued access tokens because they could be self-describing and signed. By having token secrets I think storing every issued token at the auth server or resource server side is

[OAUTH-WG] Should replay of access token request be allowed?

I was reviewing 3.6.2. Client Requests Access Tokenand it occurred to me that there's no requirement in the spec (that I can find) that a given callback URI and verification code can only be exchanged for access and refresh tokens at m

[OAUTH-WG] Questions about scopes (section 6.1)

I have some questions regarding the WWW-Authenticate header's "scope" attribute. The spec states "The "scope" attribute is a space-delimited list of URIs (relative or absolute) indicating the required scope of the access token for accessing the requested resource." Which of the scope URI

Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

what is the advantage in comparison to a token secret? How do you want to propagate the client_id and secret to the resource servers? regrards, Torsten. Am 30.05.2010 um 03:27 schrieb Andrew Arnott : Perhaps we can say that installed client apps can have client secrets after all, by call