[OAUTH-WG] a question on authorization to resource and scope in request

Hi, all I wonder how an access token is bound with the required resource item, I cann't see any field specifying the requested resource in request for authorization token and access token. Is "scope" relevant with this? Regards~~~ -Sujing Zhou___

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Bill, I seem to recall in Paris that client misconfiguration of TLS was a concern. In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication. If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go i

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

AS would still be required to be HTTPS as per the spec. From: David Waite To: oauth@ietf.org Sent: Thursday, August 9, 2012 4:02 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 For #1: Does the use of plain HTTP to talk to protected res

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

For #1: Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS? For #2: Would the signature protection just cover HTTP

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On Aug 9, 2012, at 1:08 PM, Justin Richer wrote: > With MAC, you should be able to re-use about 80-90% of your existing codepath > that's in place for Bearer, simplifying the setup below. That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAu

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Yes, sort of. I blew two days debugging my code accessing Twitter. We had intermittent failures. It would work for hours, and then fail for hours. Eventually I noticed that we were calling http://api.twitter.com instead of https://api.twitter.com. Once we changed that it worked fine. On Aug 9

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Mostly it's around making sure you get the signature base string constructed right in my experience. From: Dick Hardt To: William Mills Cc: Dick Hardt ; "oauth@ietf.org" Sent: Thursday, August 9, 2012 12:48 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-o

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

+1 We've supported #3 for quite some time in our public APIs that pre-date OAuth. Thanks, George On 8/9/12 3:37 PM, Justin Richer wrote: Use case #2: signature protection over plain HTTP parameters MAC gives us message-level signing in a way that doesn't require all the parameters to be pa

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below. I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so m

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Use case #2: signature protection over plain HTTP parameters MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On 09/08/12 20:53, William Mills wrote: MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model I work on the framework which already supports MAC (with major thanks to a user contribution). I'm not too w

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

OK, I'll play and start documenting the use cases.   Use case #1: Secure authentication in plain text connections: Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

+1 finishing a draft for historical reasons without the full context of HoK use-cases and identified threats concerns me In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the u

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On 08/09/2012 07:26 PM, John Bradley wrote: > In Vancouver the question was asked about the future of the MAC spec due to > it no linger having a editor. > > The Chair and AD indicated a desire to have a document on the use-cases we > are trying to address before deciding on progressing MAC or

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document. Phil Hunt is going to put tog

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

also, the oauth 2 abstract says the following so it seems confusing that oauth 1 is the proposed solution for mac: This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849 . On Thu, Aug 9, 2012 at 12:53 PM, William Mills wr

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt To: Will

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On Aug 9, 2012, at 9:52 AM, William Mills wrote: > I find the idea of starting from scratch frustrating. MAC solves a set of > specific problems and has a well defined use case. It's symmetric key based > which doesn't work for some folks, and the question is do we try to develop > something

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case an

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

OK, that's fair. I just don't want process to get in the way of progress. -- Justin On 08/08/2012 05:21 PM, John Bradley wrote: We did discuss per message signing in Vancouver. The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms. Per message