Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Here's a thought: signed_content="request,query,body" If not included, it defaults to "request,query". It's non-breaking (except for the implied removal of bodyhash), allows for either body or query content to be omitted from the signature, and looks less ugly than bodyhash=true. If yo

Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10)

I see 4 suggestions for discovery (getting details about the OAuth endpoints etc to client apps): 1. Include it as extra params when advertising authentication mechanisms. WWW-Authenticate: MAC realm="...", , auth_url="http..." I don't like this as it changes WWW-Auth headers for other auth

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Hi All, I vote for #1 - the proposal is simple and straightforward. However, as one of the authors of WRAP - I am rather fond of bearer tokens. Replacing OAuth 1.0 tokens with bearer tokens was one of the primary goals of WRAP, so #4 makes a lot of sense to me too. That being said, #1 is simple

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

This is where we stand so far: Option 1 -- 14 votes William Mills Eran Hammer-Lahav Franklin Tse David Recordon Peter Saint-Andre Phil Hunt Skylar Woodward Michael Adams Igor Faynberg Justin Hart Brian Campbell Luke Shepard James Manger Minoo Hamilton Option 2 -- 1 vote Marius Scurtescu (or #3

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Hi Skylar, > -Original Message- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Monday, February 07, 2011 9:25 AM > On including parameters for signing... > > I'd retract my suggestion that we'd include parameter-hash in the header. > Instead, I would suggest making parameters

Re: [OAUTH-WG] validate authorization code in draft 12

Hi Torsten, Thanks for getting back to me and raising this interesting point. Are you hinting that while a web application allows anonymous access, it shouldn't participate in OAuth? If so, this assumption has not been spelled out in the core specification. From what I read, the current speci

Re: [OAUTH-WG] New Working Group Items?

I'm on the other side of this. I think the opaque token is clean and allows for easy separation. What more information do we need to provide to the client? I am not in favor of having a call back to the authenticating site as a requirement for OAuth in general, but if someone wants to defin

Re: [OAUTH-WG] New Working Group Items?

Hi Igor! That is exactly what I would like to explore! My thinking was that the authorization server should be quite simple. There should be no advanced things like a policy server inside it. As long as the authorization (AS) and the resource servers (RS) use the same identity source (or trusted

Re: [OAUTH-WG] New Working Group Items?

Kristoffer, I assume you mean an interface between the authorization server and the resource server. If so, I believe it definitely merits a serious discussion, and I support the idea in principle. On this subject, I think we need even more work defining the token and linking it to the resou

Re: [OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10)

I'm a strong advocate of the Link approach, given that authorization information does not belong on the authentication headers. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of William Mills > Sent: Monday, February 07, 2011 2:50 PM >

[OAUTH-WG] Discovery RE: Bearer token type and scheme name (deadline: 2/10)

OK. So then the question is the right way to communicate token endpoints. Is it cleaner/preferred to have everything in the WWW-Authenticate header, or to break things out so we're not stuffing a lot into those headers and repeating outselves? So, all in one would be: WWW-Authenticate: M

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Nevermind. I have found the source of my confusion, and it was self-inflicted. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Saturday, February 05, 2011 9:00 AM To: William Mills; OAuth WG Subject: RE: draft-hammer-oauth-v2-mac-token-02 I'm confused. Can you cut-and-paste the proble

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Phil phil.h...@oracle.com On 2011-02-07, at 12:10 PM, Dirk Balfanz wrote: > > > On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt wrote: > What in oauth other than method of issue makes a token an oauth token? > > Is money obtained from an ATM suddenly ATM money? > > It would be if some vend

Re: [OAUTH-WG] New Working Group Items?

Oops, sorry did not want to steal anyone's thunder! Just a honest indentation mistake, great list Hannes. BR Kristoffer From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, February 07, 2011 1:14 PM To: Kristoffer Gronowski Cc: oauth@ietf.org S

Re: [OAUTH-WG] New Working Group Items?

Hi Kristoffer, Hannes compiled the list :-) regards, Torsten. Am 07.02.2011 22:10, schrieb Kristoffer Gronowski: Hi Torsten! Great that you compiled the list on WG items. IMO there is one item missing and that is to create an optional formal interface between the authorization server and the

Re: [OAUTH-WG] New Working Group Items?

Hi Torsten! Great that you compiled the list on WG items. IMO there is one item missing and that is to create an optional formal interface between the authorization server and the protected resource. It could increase the productivity of creating the oauth protected web services when the auth se

Re: [OAUTH-WG] validate authorization code in draft 12

Hi Eric, I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful a

Re: [OAUTH-WG] WWW-Auth. OAuth scheme (was RE: Bearer token type and scheme name (deadline: 2/10))

Hi James, Am 06.02.2011 14:07, schrieb Manger, James H: Phil Hunt said: The only other issue would be determining whether the token is obtained via an OAuth profile or> via some default profile. That could be handled with something like: WWW-Authenticate: Basic realm="somerealm" WWW-Authen

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

On Mon, Feb 7, 2011 at 11:23 AM, Phillip Hunt wrote: > What in oauth other than method of issue makes a token an oauth token? > > Is money obtained from an ATM suddenly ATM money? > It would be if some vendors would only accept money which came out of ATMs. Which is the situation we're in with O

Re: [OAUTH-WG] New Working Group Items?

Long introduction - here are the documents: A) Simple Web Discovery (SWD) http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt I consider authorization server endpoints and capabilities discovery an important aspect and would be willed to review. B) HTTP Authentication: MAC Aut

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

What in oauth other than method of issue makes a token an oauth token? Is money obtained from an ATM suddenly ATM money? What if the tokens are Kerberos tokens. What makes them suddenly oauth tokens? Phil Sent from my phone. On 2011-02-07, at 10:39, Eran Hammer-Lahav wrote: > Given the loos

Re: [OAUTH-WG] who is working on security considerations?

It would probably be helpful to do this work in public. If not via I-Ds (even if very rough) than via github etc. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, February 07, 2011 10:35 AM > To: Br

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Given the loose definition of tokens, any token issued as part of the OAuth flow is an OAuth token. It doesn't mean that an OAuth token cannot be (internally or in practice) using a token format from another protocol. The idea that an OAuth token request may issue something other than an OAuth t

Re: [OAUTH-WG] who is working on security considerations?

Hi Brian, Mark McGloin, Phil Hunt and I are working on a security considerations document. We plan to submit it to the working group in the next couple of weeks. Your contribution would be highly appreciated. What would you like to contribute? regards, Torsten. Am 07.02.2011 19:09, schrieb

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

I don't agree that at token issued by an OAuth server is by definition an OAuth token. OAuth describes a flow pattern around how tokens may be obtained, etc. There are many types of tokens that could be employed. OAuth does not describe how SP's interpret and use tokens. It only suggests how

[OAUTH-WG] who is working on security considerations?

Has anyone stepped up to start writing security considerations yet? Now that the organization is back to tracking different use cases using different flows, I think it's feasible and would like to contribute. ___ OAuth mailing list OAuth@ietf.org https:/

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

What don’t you agree with? EHL From: Phillip Hunt [mailto:phil.h...@oracle.com] Sent: Monday, February 07, 2011 8:29 AM To: Eran Hammer-Lahav Cc: Dirk Balfanz; Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) -1 I don't agree fully here. Phil

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

-1 I don't agree fully here. Phil Sent from my phone. On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote: > Yes, any token issued via OAuth by an authorization server is an OAuth token > by definition. Which makes ‘token_type=oauth2’ an silly and confusing > statement, given that any token i

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

Yeah... I struggled with that. There is no reason to include the body hash with the request other than to indicate a body hash is included in the normalized request string. It's just that an attribute like 'bodyhash=true' is so ugly... I'm still thinking about this. EHL > -Original Messag

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

On body-hash... Having completed a trial implementation, it seems redundant, and potentially problematic, to include the body-hash in the Authentication header. The danger is that implementors may neglect to recalculate the hash themselves, reusing the value (even if incorrect) provided by the

Re: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2-mac-token-02

comments below... On Feb 4, 2011, at 6:22 AM, Manger, James H wrote: > Comments on draft-hammer-oauth-v2-mac-token-02 > > > This draft is a good improvement. > > (continuing numbering from my previous comments) > > 11. The "access

Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

A couple of editorial notes: 3.2 has a mismatch of parameters between the example and the text (eg, "using access token j92fsdjf094gjfdi,..." where h480djs93hd8 from 1.1 is used in the example). The timestamp and nonce are also mismatched, though bodyhash seems correct. As a result, the signatu

Re: [OAUTH-WG] client_id chicken+egg problem and a typo in draft 12

I struggled w/ this conflict as well during implementation since we also tie the redirection URI to client identity. However, URI preregistration is not required by the spec (3.1.1, paragraph 3, so, if a provider's redirect_uri validation is not dependent on client_id (be it a subset of URIs, or

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Yes, any token issued via OAuth by an authorization server is an OAuth token by definition. Which makes 'token_type=oauth2' an silly and confusing statement, given that any token issued via this method is also an OAuth 2.0 token... but for some reason only one is labeled oauth2. EHL From: oaut