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

I wouldn't. The fact is that the current spec provides a symmetric secret for authenticating clients. Extending this to use something else is trivial. Since this will be the majority of implementation (based on current deployment), I see no reason to make the spec harder to read and implement f

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

But that gives us a flow for each type of client credential. I think it is better to talk about client_credentials and credential_type in flow that abstracts for credential types. -Axel -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Wednesday, May 12, 2010 8:

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

I would rename "client_secret" to "client_credential" and "secret_type" to "credential_type". The client_credential might be a shared secret denoted by e.g. "credential_type=shared_secret". -Axel -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, Ma

Re: [OAUTH-WG] Strict equality matching of redirect_uri

twitter is working on a version where we will actually allow the specification of an explicit array of registered URIs, and we do strict matching against the elements of that array to see if any match. we thought of allowing just subdomain globbing and wildcards, but that seemed problematic for GA

Re: [OAUTH-WG] Strict equality matching of redirect_uri

FWIW, Facebook does not do strict equality matching on redirect_uri. We accept any redirect_uri that has either: - its prefix is the registered url - or it is a special facebook.com/xd_proxy.php url, with an origin parameter that has a prefix on the registered url I think that the spec should l

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

Yes, the Client authenticating using a RSA key pair seems like it should be a different flow. On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav wrote: > But it is not beyond the scope. We define a parameter just for that called > client_secret. If you want to use something else, you need to de

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

But it is not beyond the scope. We define a parameter just for that called client_secret. If you want to use something else, you need to define an extension that replaces that with something else. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On

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

I suggest a change to "3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using a set of client credentials. The client credentials include a client identifier and an OPTIONAL symmetric shared secret. The means through which

Re: [OAUTH-WG] sites with wildcard

Marius, >> Should it send the token when getting the photos? > I would say definitely not. If the client gets back a 403 with > discovery info that points to the same authz server and approved > scopes, only then could the client re-try with a token. > Would that work? No. That would be totally

Re: [OAUTH-WG] SWT for indicating sites where a token is valid

Marius, > If the protected resource sends a redirect instead of serving the > resource then probably it knows what it is doing. Sure, the server knows what it is doing. However it is completely legitimate for a server to knowingly redirect to an external site, to a site configured by a user, to

Re: [OAUTH-WG] sites with wildcard

We should strive to do as much as rough consensus allows. The way we decide what's in scope is by discussing it until we reach a mature proposal. Objections must always come with a technical argument why the proposal is bad. All specs include features that are a little bit experimental (in OAuth

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

No one was suggesting putting the assertion in the header. Just the client credentials... EHL > -Original Message- > From: Yaron Goland [mailto:yar...@microsoft.com] > Sent: Tuesday, May 11, 2010 4:24 PM > To: Torsten Lodderstedt > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subje

Re: [OAUTH-WG] sites with wildcard

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Yaron Goland > Sent: Tuesday, May 11, 2010 4:29 PM > To: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard > > Thanks for explaining, I now believe I

Re: [OAUTH-WG] sites with wildcard

Thanks for explaining, I now believe I understand the use case. But I would point out that this is really an unsolved problem in general and if we are to tackle it we have to deal with real concerns such as – what happens if in the time since the site list was provided and when the token was use

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

Actually it's server side that's the problem. Many servers limit the size of the HTTP request headers they will accept. Apache 2.2, for example, uses the LimitRequestFieldSize Directive (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is 8190 bytes. IIS, I Believe, defaults to

Re: [OAUTH-WG] sites with wildcard

Limited views on what a protocol is far tend to produce protocols that are actually interoperable. We should strive to do as little as possible in the standard and make sure we do a great job leaving the door open to later extensions. > -Original Message- > From: oauth-boun...@ietf.org

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert wrote: > > On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu > wrote: >> >> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >> wrote: >> > >> >> -Original Message- >> >> From: Dick Hardt [mailto:dick.ha...@gmail.com] >> >> Sent: Sunday, Ma

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu wrote: > On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav > wrote: > > > >> -Original Message- > >> From: Dick Hardt [mailto:dick.ha...@gmail.com] > >> Sent: Sunday, May 09, 2010 5:52 PM > > > >> >> 3.5.1. Client Requests Authorization

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

On Tue, May 11, 2010 at 2:29 PM, Paul Madsen wrote: > Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a > QR code and add it to the response to the client (perhaps as you say in > addition to the raw URI & user code). There would be no user-code, as we > would no longer be

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

Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a QR code and add it to the response to the client (perhaps as you say in addition to the raw URI & user code). There would be no user-code, as we would no longer be constrained by the user's short-term memory for strings

Re: [OAUTH-WG] sites with wildcard

On Mon, May 10, 2010 at 5:31 PM, Manger, James H wrote: > Yaron, > > > >> I don’t understand the scenario that requires this feature. When does >> someone ask for a token without knowing where it is going? > > > > Example: > > A client app gets a token to make an API call to a protected resource t

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

On Tue, May 11, 2010 at 3:33 AM, Vivek Khurana wrote: > On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav > wrote: >> DEADLINE: 5/13 >> >> I would like to publish one more draft before our interim meeting in two >> weeks (5/20). Below are two open issues we have on the list. Please reply >> w

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

On Tue, May 11, 2010 at 4:12 AM, Paul Madsen wrote: > Yes that's the idea. > > Where in the authorization server response would the QR code (or ref) go, > especially if it also includes the uri & user code? I don't know how QR codes are generated, but I was assuming that the device can generate o

Re: [OAUTH-WG] sites with wildcard

On Tue, May 11, 2010 at 11:03 AM, Eran Hammer-Lahav wrote: > That's a pretty limited view on what OAuth 2.0 is for. It it what has brought a large community into this mailing list. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listi

Re: [OAUTH-WG] Indicating sites where a token is valid

On Mon, May 10, 2010 at 8:45 PM, David Recordon wrote: > If the sites parameter is not specified, would it default to the > domain of the authorization server. What is the domain of the authz server? The authz server is defined by two URLs, they may not have the same domain. Marius _

Re: [OAUTH-WG] SWT for indicating sites where a token is valid

Hi James, On Mon, May 10, 2010 at 5:36 PM, Manger, James H wrote: > Marius, > >> But then again, how does the client end up making a request to > the wrong site? > > The client follows a redirect or link. It doesn't know if the ultimate source > of the new URI was the resource server’s internal

Re: [OAUTH-WG] sites with wildcard

That's a pretty limited view on what OAuth 2.0 is for. EHL > -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Tuesday, May 11, 2010 10:53 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard > >

Re: [OAUTH-WG] sites with wildcard

On Tue, May 11, 2010 at 10:49 AM, Eran Hammer-Lahav wrote: > This is completely meaningless. > > This list is all vendors specific (including OAuth 1.0 which lacks any form > of discovery) which means libraries can easily hard-code the sites allowed > into their library. Also, because there real

Re: [OAUTH-WG] sites with wildcard

This is completely meaningless. This list is all vendors specific (including OAuth 1.0 which lacks any form of discovery) which means libraries can easily hard-code the sites allowed into their library. Also, because there really isn't any authentication challenge involved, there is no issue wi

Re: [OAUTH-WG] Indicating sites where a token is valid

Am 09.05.2010 16:39, schrieb Manger, James H: Torsten, Thanks for your analysis. 1) Resource server controls token sites (context of the realm attribute) 2) Authorization server controls token sites (context of token) In my opinion, (1) improves security and eases the

Re: [OAUTH-WG] Provisional OAuth enhancements

On Mon, May 10, 2010 at 8:05 PM, Eran Hammer-Lahav wrote: > I don’t see how moving the discussion/work on these features elsewhere will > help reach consensus on them. I think the proposal is to keep discussion on the IETF mailing list, but clearly separate things that are speculative from things

Re: [OAUTH-WG] sites with wildcard

On Mon, May 10, 2010 at 5:31 PM, Manger, James H wrote: > In general, the web is about following links. Clients need to know when > following a link crosses a security boundary. Cookies provide this; Basic > provides this; Digest provides this; OAuth needs this too. Notably absent from the list o

[OAUTH-WG] Call for Issues

Hannes and I are currently working on preparing an agenda for next week's meeting. In addition to the two issues Eran has open for comments on the list, we would like to solicit open issues from the community. Thanks to the incredible efforts that Eran and everyone else who has contributed recentl

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

Am 11.05.2010 12:33, schrieb Vivek Khurana: 2. Client Authentication (in flows) How should the client authenticate when making token requests? The current draft defines special request parameters for sending client credentials. Some have argued that this is not the correct way, and that the cl

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

Yes that's the idea. Where in the authorization server response would the QR code (or ref) go, especially if it also includes the uri & user code? I don't see mention of an extensibility model by which additional params could be defined/added On 5/10/2010 2:03 PM, Marius Scurtescu wrote: O

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav wrote: > DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issue

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

On 2010/05/11 12:49, Robert Sayre wrote: > What /would/ be nice is an HTTP authentication scheme that used some > sort of PAKE... but don't gate the OAuth spec on that. FYI for people interested: my proposal for PAKE-based HTTP authentication submitted as an Internet-Draft:

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

On 2010/05/11 12:49, Robert Sayre wrote: > Basic leaves the input character encoding unspecified, so it doesn't > handle anything but ASCII in an interoperable way. OAuth > implementations will certainly screw this up too, but I suspect it > will be somewhat less buggy, since most people will prob

Re: [OAUTH-WG] delegating access to another client

although we are the ones who are pushing this into our ecosystem right now, i agree with david on this one -- i'm happy to take the lead in drafting this (i have some sketches of it working in the oauth 1.0a world for a one time use -- http://mehack.com/oauth-echo-delegation-in-identity-verificatio

Re: [OAUTH-WG] delegating access to another client

Lifespan of this delegation token could be: - One time usage of token - Time or numbers of usage given to the AS when the delegation has been asked. If the access of the client is revoked, all the delegate tokens should be also revoked. I have implemented a couple of scenarios for recursive d

Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

On 10/05/2010 23:38, Joseph Smarr wrote: > Oh, one other quick benefit of JSON (kind of an extension of point 1 below): > > - no ambiguous treatment of whitespace or newlines (this is a problem > I've observed multiple times while helping developers debug OAuth 1.0 > implementations--since they ju

Re: [OAUTH-WG] modifying the scope of an access token

Are you actually (planning on) writing something like this? EHL > -Original Message- > From: John Panzer [mailto:jpan...@google.com] > Sent: Monday, May 10, 2010 10:40 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] modifying the scop

Re: [OAUTH-WG] modifying the scope of an access token

Yes. In the case of an authorization server handing out tokens like free candy, it's unlikely that it would implement the ability to restrict scope on a token it already issued. Thus my argument is that it seems like this method would be implemented by authorization servers who make use of refresh