Re: [OAUTH-WG] "shared symmetric secret"

kie on the 3rd party web site you will likely be able to access the same data as the access token (web site uses refresh token on backend to make API calls on behalf of the logged in user... which is based on the cookie that was stolen). > > EHL > > > > On 7/14/10 11:04 PM, "

Re: [OAUTH-WG] "shared symmetric secret"

"Password" doesn't seem to be the right analogy. You don't (or really shouldn't) store passwords in plain text or in cookies. How about "cookies"? Most web developers understand that cookies are used as a token that grants access to resources. We've also called these tokens"API cookies" when tryin

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott wrote: > If we can agree that it is useless from a security perspective (and I think > we agree on that by now), then an auth server must not ever issue an access > token to a user agent client without interacting with the user (no > "immediate" mode

Re: [OAUTH-WG] Understanding the reasoning for Base64

Hi all - having a little bit of a hard time following the full thread, but I'm strongly in favor of base64url encoding. A big advantage of this encoding is that, if token is base64url encoded, then urlencode(token) == token. This allows developers to avoid a large class of problems in dealing wit

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.loc

Re: [OAUTH-WG] Proposal for single JSON response format

> > > If a response from the AS is untrusted, there are much bigger issues at > stake. ... or am I missing an obvious attack where random JSON would get > sent to the Client? > For the web server flow, you know the AS server you called and can reasonably trust the data. For the user agent flow, a

Re: [OAUTH-WG] Proposal for single JSON response format

On Sun, Jun 13, 2010 at 5:55 PM, Eran Hammer-Lahav wrote: > To be clear, you are +1 on using only JSON for server responses on the > token endpoint? > Yes, +1 on JSON responses for token endpoint. > > > EHL > > > > *From:* Evan Gilbert [mailto:uid...@google.com] &

Re: [OAUTH-WG] Proposal for single JSON response format

direct URI as simple key/value pairs and actively try to discourage adding structured / complex content. We can use a followup call to the AS with the access token on the server side for complex data, and JSON is the right response format for this followup call. > > > EHL > > >

Re: [OAUTH-WG] A display parameter for user authorization requests

The "immediate" parameter is can have unintended consequences without some way to attach it to an existing user. Examples here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. I'd prefer to link these two parameters (username and immediate) in one spec - @David, this can be

Re: [OAUTH-WG] Proposal for single JSON response format

-1 I disagree very strongly with this approach if I'm understanding correctly. Let me paraphrase to make sure I understand: All responses, even those encoded in a browser URL redirect back from the AS (redirect with verification code in the web server flow and the redirect with token in the user-

Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)

On Tue, May 25, 2010 at 1:43 PM, Murali VP wrote: > Anyway to find out what the outcome was from the May 20th interim meeting? > I > wanted to participate but had to be at Google I/O. > > 3.5. User-Agent Flow > > 1. Since the client_id is public, the only check that prevents from > any client po

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

On Wed, May 19, 2010 at 6:33 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Marius, > > > Only direct responses are JSON, form/url encoded > > still has to be used: > > - direct requests > > - through browser requests > > - through browser responses > > - through browser fragment

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

On Mon, May 17, 2010 at 8:53 AM, Marius Scurtescu wrote: > On Mon, May 17, 2010 at 8:29 AM, Evan Gilbert wrote: > > I'd like to get a standard for redirect URI matching, but think this may > not > > be feasible - we are leaving the callback URI registration mechanism >

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

I'd like to get a standard for redirect URI matching, but think this may not be feasible - we are leaving the callback URI registration mechanism undefined and I've heard a number of different mechanisms that companies want to support. I think we should leave the matching undefined, possibly with

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

On Thu, May 13, 2010 at 4:54 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Evan, > > > we have no API endpoints that are only arrived at by links > > This doesn't sound very web-friendly. Your APIs don't have to follow a > web-style, but an IETF spec should support web-style APIs

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

f stuff to hardcode already, this > adds little value. > > > > EHL > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Thursday, May 13, 2010 9:00 AM > > *To:* Manger, James H > *Cc:* OAuth WG > *Subje

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

On Wed, May 12, 2010 at 11:52 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Evan, > > > The key point is that this discovery covers a lot of the same grounds as > the sites parameter, and it's hard to define semantics around a sites > parameter without understanding the semantic

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

Thanks for the response - feedback inline... On Wed, May 12, 2010 at 5:09 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Evan, > > > Clients need to know the following in advance: > > 1. The scope to use to request access to a protected resource > > 2. The API endpoint to call to

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

On Mon, May 10, 2010 at 4:30 PM, Evan Gilbert wrote: > I really like the idea behind the "sites" parameter > I continue to like the idea behind the "sites" parameter, but think it may be premature to add to the OAuth spec. Clients need to know the following in advan

Re: [OAUTH-WG] Provisional OAuth enhancements

OK, just started this experiment :) - Added a section on the OAuth IETF Wiki for proposed enhancements: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2ProvisionalEnhancements. - First proposal is for "username" parameter: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. I

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] Comments on draft-ietf-oauth-v2-03.txt

On Mon, May 10, 2010 at 1:20 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > > > Am 10.05.2010 um 22:07 schrieb Marius Scurtescu : > > > On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt >> wrote: >> >>> 3.5.1.1. End-user Grants Authorization >>> >>> I would suggest to use JSON en

Re: [OAUTH-WG] User Endpoint

+1 on delegation. This conveys the purpose nicely - I think these endpoints are always to verify that there is a currently logged in user for the purpose of delegation. "User" seems a bit vague - "user agent" seems more appropriate if we want to reference that this occurs in a browser. Also note

[OAUTH-WG] Provisional OAuth enhancements

I'm seeing a few OAuth features in spec discussions which: - Feel like it would be a major omission if they don't make it into OAuth 2.0, but - Haven't been used previously or even prototyped, which makes people uncomfortable with adding to the spec This includes the scope / sites syntax discussio

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

I really like the idea behind the "sites" parameter I think this idea relates closely to scopes and probably needs to be bound more tightly to the inbound scope parameter. Both identify a set of protected resources that can be accessed with the token - one is the requested resources, the other is

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

I assume we would also use URL parameters for the Web App flow when redirecting with the verification code. > > > EHL > > > > *From:* Evan Gilbert [mailto:uid...@google.com] > *Sent:* Wednesday, May 05, 2010 10:07 AM > *To:* Eran Hammer-Lahav > *Cc:* Torsten Lodderste

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert wrote: > > > On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Even if not supported directly by the platform there are many JSON >> libraries available these days. >>

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Even if not supported directly by the platform there are many JSON > libraries available these days. > It's not hard to add JSON support, but it's a factor in the choice. > > http://www.json.org/ lists 3 li

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

On Wed, May 5, 2010 at 10:24 AM, Robert Sayre wrote: > On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert wrote: > > > > > > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > > wrote: > >> > >> I'll add something to the draft and we'll disc

Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav wrote: > I'll add something to the draft and we'll discuss it. There is enough > consensus on a single JSON response format. Responses that are returned via a browser URL should be application/x-www-form-urlencoded. These parameters are standard

Re: [OAUTH-WG] Scope - Coming to a Consensus

+1 on option 3. Commas seem slightly cleaner, but can go either way. We should also consider naming this parameter "scopes" if we go with option 3 Evan On Mon, May 3, 2010 at 6:23 AM, Manger, James H < james.h.man...@team.telstra.com> wrote: > A comma is a better separator here. > Allow URIs a

Re: [OAUTH-WG] Combining the Native application and User-agent flows

On Fri, Apr 16, 2010 at 8:09 PM, Eran Hammer-Lahav wrote: > > > > On 4/16/10 6:00 PM, "Evan Gilbert" wrote: > > > - Add text to the spec to give overview of options for native app > developers > > I need a proposal. > Here's a proposal for text to

Re: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

On Wed, Apr 21, 2010 at 10:13 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Am 21.04.2010 17:31, schrieb Evan Gilbert: > > > > On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Am 21.04.2010 02:4

Re: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Am 21.04.2010 02:45, schrieb Evan Gilbert: > > > > On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi all, >> >

Re: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi all, > > I would like to propose an additional variant of the Web Server Flow w/o > the need for direct communication between client and authorization server in > order to obtain authorized access/refresh

Re: [OAUTH-WG] Issue: 'username' parameter proposal

herwise > > > I have no objections to this proposal but wanted to see some discussion and > support from others before adding it to the spec. > > > > EHL > > > > *From:* Evan Gilbert [mailto:uid...@google.com] > *Sent:* Monday, April 19, 2010 10:06 AM > *T

Re: [OAUTH-WG] Issue: prefixing parameters with oauth_

On Mon, Apr 19, 2010 at 10:19 AM, Marius Scurtescu wrote: > On Mon, Apr 19, 2010 at 7:28 AM, Evan Gilbert wrote: > > I have a preference to *not* have the "oauth_" prefix on parameters when > > redirecting back, but could be convinced. > > The argument about coll

Re: [OAUTH-WG] Issue: 'username' parameter proposal

User 1 starts seeing User 2's data. On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav wrote: > How can they both be logged in? I have never seen a case where two users > can be both logged into to the same service at the same time... > > EHL > > > > On 4/19/10 8

Re: [OAUTH-WG] Issue: Scope parameter

On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav wrote: > Where does it say you cannot add a parameter named scope? To suggest that > you can’t use the specification because it doesn’t define a placeholder for > something called ‘scope’ is ridiculous. > > > > Simpler client interface is a valid

Re: [OAUTH-WG] Issue: 'username' parameter proposal

nsues Secondary goal: Provide a hint for non-immediate mode On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav wrote: > Evan Gilbert proposed a 'username' request parameter to allow the client to > limit the end user to authenticate using the provided authorization server > identifi

Re: [OAUTH-WG] Issue: prefixing parameters with oauth_

I have a preference to *not* have the "oauth_" prefix on parameters when redirecting back, but could be convinced. The argument about collisions makes sense, but I think there are no known conflicts and you can always add a redirection layer if a conflict arises in the future and a web serving fra

Re: [OAUTH-WG] Issue: state in web server flow

On Sun, Apr 18, 2010 at 10:36 PM, Dick Hardt wrote: > > On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote: > > > > > > >> -Original Message- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Sunday, April 18, 2010 9:20 PM > >> To:

Re: [OAUTH-WG] Combining the Native application and User-agent flows

A few of us from Google & Facebook had a face-to-face discussion today to talk through the differences / similarities between Native App, Web Callback, and User-Agent. >From the discussion it seemed that the current Native Application flow is equivalent to Web Callback flow, with: 1. A redirect to

Re: [OAUTH-WG] Rename callback => callback_uri

ote: > > +1 for redirect_uri -- highest semantic value imho. > > > -Naitik > > > > On Apr 16, 2010, at 12:05 PM, Evan Gilbert wrote: > > > We should use the same name in the User-Agent and Web Callback flows. > Also, although the authorization server won't be

Re: [OAUTH-WG] Rename callback => callback_uri

ewhere so whatever) seems > the best to me too. > I'm fine with either. > > -Original Message- > From: Richard Barnes [mailto:rbar...@bbn.com] > Sent: Friday, April 16, 2010 12:27 PM > To: Evan Gilbert > Cc: Luke Shepard; Naitik Shah; OAuth WG > Subjec

Re: [OAUTH-WG] Rename callback => callback_uri

t parameters), but > rather as HTTP-layer things, e.g., in an Authorization header? > These all have to work as a browser GET request > > --Richard > > > > > On Apr 16, 2010, at 3:05 PM, Evan Gilbert wrote: > > We should use the same name in the User-Agent and We

Re: [OAUTH-WG] Rename callback => callback_uri

We should use the same name in the User-Agent and Web Callback flows. Also, although the authorization server won't be allowing JSONP requests, "callback" has become a bit of a defacto standard for JSONP and it would be nice to use a term that isn't overloaded? Can we make them both "redirection"?

Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer wrote: > I favor this approach as well. It feels cleaner to me to have a > separation of purposes here. The two endpoints could always be collapsed > in a particular implementation -- I've seen several OAuth 1.0 > implementations that do just this, u

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

On Thu, Apr 15, 2010 at 6:31 PM, Marius Scurtescu wrote: > OK, here is a concrete example: > > A Drupal (popular PHP based CMS) based web site wants to become an > OAuth 2 client. Among other things it needs to implement a callback > endpoint. > > Ideally this endpoint would look something like: >

Re: [OAUTH-WG] Process / timeline for OAuth 2.0

Thanks for the responses - they were very helpful. On Thu, Apr 15, 2010 at 5:12 AM, Eran Hammer-Lahav wrote: > > > > On 4/15/10 12:04 AM, "Evan Gilbert" wrote: > > > - What does it mean to have successive drafts? And if we move an issue to > the > > nex

[OAUTH-WG] Process / timeline for OAuth 2.0

I've been participating in the OAuth 2.0 discussions, but realized I don't know how the process is supposed to work for getting successive drafts and getting to an agreed upon spec and if we have a rough timeline. The "Informal Guide " didn't help that

Re: [OAUTH-WG] Option to not prompt the user for authorization

On Fri, Apr 9, 2010 at 10:08 PM, Eran Hammer-Lahav wrote: > > > > On 4/9/10 1:58 PM, "Evan Gilbert" wrote: > > > > > > > On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav > > wrote: > >> > >> > >> > >> On 4/

Re: [OAUTH-WG] A display parameter for user authorization requests

+1 in general Question about display=none - I missed this part before, and proposed a different parameter (immediate=true) for the same purpose - http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html. Anyone have thoughts on whether we should have a separate parameter for immediate mod

Re: [OAUTH-WG] Draft progress update

ibly this requirement can move. Possibly some of the folks who initially proposed client state can give context as to why this might be different than URL parameters. > EHL > > > > On 4/9/10 7:37 AM, "Evan Gilbert" wrote: > > > > On Fri, Apr 9, 2010 at 12:3

Re: [OAUTH-WG] Option to not prompt the user for authorization

On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav wrote: > > > > On 4/9/10 8:29 AM, "Evan Gilbert" wrote: > > > > > > > On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav > > wrote: > >> > >> > >> > >> On 4/

Re: [OAUTH-WG] Option to not prompt the user for authorization

On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav wrote: > > > > On 4/8/10 9:17 PM, "Evan Gilbert" wrote: > > > > > > > On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav > > wrote: > >> > >> > >> > >> On 4/7

Re: [OAUTH-WG] Draft progress update

On Fri, Apr 9, 2010 at 7:37 AM, Evan Gilbert wrote: > > > On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav wrote: > >> >> >> >> On 4/8/10 11:11 PM, "Evan Gilbert" wrote: >> >> >> >> >> >> >>>> 2

Re: [OAUTH-WG] Draft progress update

On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav wrote: > > > > On 4/8/10 11:11 PM, "Evan Gilbert" wrote: > > >> > >> > >>>> 2. Section 2.1: "The authorization endpoint advertised by the server > >>>> MUST NOT i

Re: [OAUTH-WG] Draft progress update

> > > > >> 2. Section 2.1: "The authorization endpoint advertised by the server > >> MUST NOT include a query or fragment components as defined by > >> [RFC3986] section 3." Why do we disallow query parameters? If we want > >> to enforce strict matching of callback URLs maybe we should just > >> de

Re: [OAUTH-WG] Option to not prompt the user for authorization

On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav wrote: > > > > On 4/7/10 9:20 PM, "Evan Gilbert" wrote: > > > Authorization servers in the OAuth Web Callback flow and the User Agent > flow > > should have the option to redirect back with access/refresh

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

clear to me that there's a security hole, but it never hurts to provide more information in the response back. > EHL > > > On 4/7/10 10:46 PM, "Evan Gilbert" wrote: > > > > > > > > > On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote: >

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

On Wed, Apr 7, 2010 at 11:40 PM, John Panzer wrote: > > > On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert wrote: > >> >> >> >> On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote: >> >>> I'm assuming that tokens need not be bound to a specif

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

by username Current: username OPTIONAL. The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens *capable of making requests on behalf of* the user identified by username > > On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert wrote: > >&g

[OAUTH-WG] Option to not prompt the user for authorization

Authorization servers in the OAuth Web Callback flow and the User Agent flow should have the option to redirect back with access/refresh tokens without prompting the user, if the client has already been granted access to the protected resource. This is already implied by some of the text (3.4.3.1

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

arameter never log you in when omitting the parameter would not have. It will just create more error responses. > > EHL > > > > On 4/6/10 11:14 PM, "Evan Gilbert" wrote: > > > > On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav > wrote: > > > &g

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav wrote: > > > > On 4/6/10 5:24 PM, "Evan Gilbert" wrote: > > > Proposal: > > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter > > username > > The resource owner's username.

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

On Tue, Apr 6, 2010 at 2:44 PM, Eran Hammer-Lahav wrote: > > > > On 4/6/10 7:04 AM, "Evan Gilbert" wrote: > > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > > wrote: > >> Hi Evan, > >> > >> On 4/5/10 4:

Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom wrote: > One of the biggest differences between OAuth2 and WRAP is that OAuth2 > requires that Protected Resources be accessed using HTTPS if no signature is > being used. Bullet Point #2 in Section 1.2 says: > >4. Don't allow bearer tokens without

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

> On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert wrote: > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav > > wrote: > >> > >> Hi Evan, > >> > >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > >> > >>

Re: [OAUTH-WG] Comments on Web Callback & Client Flow

On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav wrote: > Hi Evan, > > On 4/5/10 4:28 PM, "Evan Gilbert" wrote: > > > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > > In both flows, the authorization server should be able redirect back to > the >

[OAUTH-WG] Comments on Web Callback & Client Flow

A few comments on the Web Server and Web Client flow from the draft 2.0 spec . Evan 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow In both flows, the authorization server should be able redirect back to the callback URI without interacting