Re: [OAUTH-WG] What to do about 'realm'

+1 2010/6/28 Dick Hardt : > I vote for (3) unless a good (4) is suggested. > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > > Over the past year many people expressed concerns about the use of the > ‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC > 2617 as require

Re: [OAUTH-WG] What to do about 'realm'

On 28/06/2010 06:37, Dick Hardt wrote: > I vote for (3) unless a good (4) is suggested. Ditto. p > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > >> Over the past year many people expressed concerns about the use of the >> ‘realm’ WWW-Authenticate header parameter. The parameter is defi

Re: [OAUTH-WG] Assertion Profile PHP library

Hi everyone, In RedIRIS[1], the Spanish academic and research network that provides advanced communication services to the scientific community and national universities, we are developing a PHP library to the Assertion Profile of the OAuth2 specification. This library [2] is in development

Re: [OAUTH-WG] What to do about 'realm'

#3 +1 > 2010/6/28 Dick Hardt : > > I vote for (3) unless a good (4) is suggested. > > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > > > > Over the past year many people expressed concerns about the > use of the > > 'realm' WWW-Authenticate header parameter. The parameter is > defined in

[OAUTH-WG] Client credentials type

Yaron Goland offered a proposal for an additional client credentials mechanism based on assertion. His proposal raises the issue of differentiating between the different kind of credentials used. When it comes to access grant types, this group argued for being explicit and providing a parameter

Re: [OAUTH-WG] JSON parsing in the browser (was: Proposal for single JSON response format)

On Sun, Jun 27, 2010 at 1:46 PM, Robert Sayre wrote: > On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert wrote: > > > >> > >> Can you explain the XSS hole from parsing a random JSON string? > > > > Naive processor calls: > > var href = document.location.href; > > var jsonBlob = href.substring(href.

Re: [OAUTH-WG] What to do about 'realm'

+1 Am 28.06.2010 07:37, schrieb Dick Hardt: I vote for (3) unless a good (4) is suggested. On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: Over the past year many people expressed concerns about the use of the ‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC 261

Re: [OAUTH-WG] OAuth 2 for Native Apps

On Fri, Jun 25, 2010 at 10:33 PM, Torsten Lodderstedt wrote: > comment/question regarding the Embedded Browser scenario: Is the URL bar and > SSL verification symbols (lock + green bar) visible in that scenario? > Otherwise, the user has no chance to verify the identity of the IDP/OAuth > server.

Re: [OAUTH-WG] Client credentials type

I would prefer (2) since authorization headers are the natural way to handle authentication in HTTP. Different client credential mechanisms can be represented by different authentication scheme (even custom-defined). HTTP libraries typically have special support for handling such headers and it

[OAUTH-WG] Messenger Connect ships today

Windows Live just shipped a beta of our Messenger Connect platform. The platform uses OAuth WRAP (among other standards

Re: [OAUTH-WG] Client credentials type

Only HTTP headers may not be enough. In Yaron's proposal, the assertion could be a SAML assertion, and these could be too large for headers. I think #1 makes sense. Marius On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt wrote: > I would prefer (2) since authorization headers are the nat

Re: [OAUTH-WG] Client credentials type

While the AS implementor can infer the request by the parameters, I prefer the programmer explicitly state what she is doing. Thinking of it as a method parameter rather than a type parameter makes more sense to me. Similiarly, HTTP has GET, POST, PUT etc. even though you could differentiate bet

Re: [OAUTH-WG] Client credentials type

what size do you expect? SPNEGO authentication headers can be up to 12392 bytes and this does not seem to be a problem. regards, Torsten. Am 28.06.2010 21:19, schrieb Marius Scurtescu: Only HTTP headers may not be enough. In Yaron's proposal, the assertion could be a SAML assertion, and these

Re: [OAUTH-WG] Messenger Connect ships today

Here's a draft with the links fixed:) Windows Live just shipped a beta of our Messenger Connect platform. The platform uses OAuth WRAP (among other standards) and a new consent dialogue

Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint

On Fri, Jun 25, 2010 at 12:07 PM, Eran Hammer-Lahav wrote: > >> -Original Message- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Thursday, June 17, 2010 2:56 PM > >> >> Basically, why cannot be that problem solved by 2 different requests, >> >> both done by the JavaScri

Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint

On 6/28/10 1:27 PM, "Marius Scurtescu" wrote: > > Again, all I am saying is that it would help to have a very detailed > use case for this token_and_code mode, to see if it is really needed. > Or, an actual implementation. I have no objections. I will include it in -09 but will mark it as co

Re: [OAUTH-WG] Proposal for text for section 2

The following is proposed language for a new section, 2.2, in the spec. This is part of the spec that deals with client authentication. This proposal is completely orthogonal to anything in section 4 such as grant types. At Eran's suggestion I added in an example into the text to help readers un

[OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

In a private thread with Eran an issue came up regarding how to handle unrecognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that contains both a client_id and a client_foo_bar argument, what should it do? Should it reject the

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

It also depends on how extensions will work, looking forward to read -09. If extensions are namespaced somehow then you could ignore unknown extension but be strict with core parameters (those would be parameters with no namespace) and with known extensions. Marius On Mon, Jun 28, 2010 at 3:01

Re: [OAUTH-WG] OAuth discovery draft?

I believe that GET should be used to return the resource’s state and its OAuth token endpoint is just a tiny part of that state. When we want to return part of the state we typically use either explicit headers (a la byte ranges) or a query parameter. Content-types should, I think, just control

Re: [OAUTH-WG] What to do about 'realm'

+1 (for #3->#4) From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, June 28, 2010 11:08 AM To: Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] What to do about 'realm' +1 Am 28.06.2010 07:37, schrieb Dick Hardt: I vote for

Re: [OAUTH-WG] Client credentials type

We regularly deal with SAML assertions that easily go into the 100s of K. This is far more than most HTTP servers will accept. So we are pretty much required to use the body. > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodder

Re: [OAUTH-WG] OAuth discovery draft?

In the SASL stuff I'm working on I was presuming I'd use the WWW-Authenticate header for returning the discovery info. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:10 PM

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

If we define that unrecognized arguments / elements are ignored then we can define extensions such that if their arguments / elements are ignored they don't introduce insecurity. Ian On Tue, Jun 29, 2010 at 10:01 AM, Yaron Goland wrote: > In a private thread with Eran an issue came up regarding

Re: [OAUTH-WG] JSON parsing in the browser (was: Proposal for single JSON response format)

On Tue, Jun 29, 2010 at 5:53 AM, Evan Gilbert wrote: > > > What specifically don't you agree with? I agree that the RegEx match or a > library will fix the security hole. > The problem is that the insecure behavior - "eval(json)" - will just work, > is obvious for developers to try, and non-obviou

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensions hard, and at a minimum requires an error to include the bad parameter in a machine readable way (so a library can figure out an extension is not supported). 2. Ignore unre

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

For #2, if an extension defines required parameters then you're not supporting the extension if you ignore them. Or am I missing something? On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav wrote: > There are 3 general ways to deal with this: > > > > 1. Break on unrecognized parameters – this t

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

There are times when the client wants the server to fail if it doesn't support an extension. The client developer might consider the server as being less secure without the added protection of the extension and would like the server to be able to tell it was making such a request and fail. This

Re: [OAUTH-WG] Client credentials type

I don't care about the name (type vs method). Are there any objection to defining a parameter for the client authentication method? Any views about using this parameter with an HTTP authorization header? EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Monday, June 28, 2010 12:25 PM To:

Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses?

I agree. I think we indeed should clearly articulate the use cases driving discovery (maybe Zachary could report on those?), but I also think that we will probably need to get something like "procedures," which describe expected usages, within the protocol specification. For one thing, all ex

Re: [OAUTH-WG] Client credentials type

For what it's worth, I (Facebook) would not require my clients to specify a type. It's fine to discuss it in the docs and examples, but if a client passed in a request without a type, I would probably try to infer the grant type from the request rather than throwing an error. Besides the purity

Re: [OAUTH-WG] Client credentials type

Your approach fits with the "be generous in what you accept" ethos. On 2010-06-28, at 8:02 PM, Luke Shepard wrote: > For what it's worth, I (Facebook) would not require my clients to specify a > type. It's fine to discuss it in the docs and examples, but if a client > passed in a request withou

Re: [OAUTH-WG] Proposal for text for section 2

Yaron, "Assertion Client Credentials" is too much of a hack. It only works for POSTs, and only when the body is form-encoded. It could not be used, for instance, to delete a token with an HTTP DELETE request to a token URI. Though that specific idea has not been accepted yet, it is a reaso

[OAUTH-WG] I-D Action:draft-ietf-oauth-v2-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename: dr

[OAUTH-WG] Draft -09

Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WWW-Authenticate header. o Added note about parameters with empty