[OAUTH-WG] User-agent flow and pre-registered redirect_uri

The user agent flow indicates that the redirect_uri SHOULD be preregistered with the auth server for a given client. I would like to suggest that the SHOULD here be changed to *MUST*. Unless I'm missing something, without a preregistered redirect_uri any arbitrary client can obtain an access toke

Re: [OAUTH-WG] Assertion flow and token bootstrapping

because we use it On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > Why? > > On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > >> +1 >> >> Sent from my iPhone >> >> On Jun 4, 2010, at 5:38 PM, Brian Campbell >> wrote: >> >>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>> wrote

Re: [OAUTH-WG] Partially standardized format for access tokens?

On 2010-06-04, at 6:39 PM, Luke Shepard wrote: > I don't see how the extra parameter is required to support multiple auth > servers for a resource. it is needed if there are multiple token types > > Responses to Dick and Torsten: > > On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote: >> if we ha

Re: [OAUTH-WG] Assertion flow and token bootstrapping

Why? On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > +1 > > Sent from my iPhone > > On Jun 4, 2010, at 5:38 PM, Brian Campbell > wrote: > >> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >> wrote: >>> >>> At least for the assertion flow, that's definitely true. At the >>> int

Re: [OAUTH-WG] Partially standardized format for access tokens?

I don't see how the extra parameter is required to support multiple auth servers for a resource. Responses to Dick and Torsten: On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote: > if we have the parameter in the spec, then clients know to pass it along if > they see it. My main objection here i

Re: [OAUTH-WG] Assertion flow and token bootstrapping

+1 Sent from my iPhone On Jun 4, 2010, at 5:38 PM, Brian Campbell wrote: On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: At least for the assertion flow, that's definitely true. At the interim meeting we had some discussion about perhaps pulling the assertion flow out of

Re: [OAUTH-WG] Definition of XML response format

It would be useful to understand the token type as the AS and RS server may each generate and accept different token types From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Andrew Arnott Sent: Friday, June 04, 2010 6:43 AM To: George Fletcher Cc: OAuth WG (oauth@ietf.org)

Re: [OAUTH-WG] "3.4. Client Credentials" text change proposal

+1 On Fri, Jun 4, 2010 at 12:36 AM, wrote: > +1 > > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Nat Sakimura > Sent: Saturday, May 08, 2010 6:45 AM > To: oauth > Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal > > 3.

Re: [OAUTH-WG] Assertion flow and token bootstrapping

+1 Am 04.06.2010 23:38, schrieb Brian Campbell: On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: At least for the assertion flow, that's definitely true. At the interim meeting we had some discussion about perhaps pulling the assertion flow out of the base spec and into a separate

Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

Am 04.06.2010 17:04, schrieb Justin Richer: What if you had a supertoken that was only good for getting subtokens? In other words, only the AS knows about the supertoken (a refresh token, perhaps?), and it allows you to get sub-tokens using the refresh flow to access each of the different service

Re: [OAUTH-WG] Assertion flow and token bootstrapping

On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: > > At least for the assertion flow, that's definitely true. At the interim > meeting we had some discussion about perhaps pulling the assertion flow > out of the base spec and into a separate document. Perhaps that's the > best way to proce

Re: [OAUTH-WG] Partially standardized format for access tokens?

Torsten, On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote: > > Am 04.06.2010 19:45, schrieb John Kemp: >> On Jun 4, 2010, at 1:35 PM, David Recordon wrote: >> >> >>> #4 should happen as part of #3. >>> >> How would ALL OAuth 2.0+ clients know to pass along the format if it is >> t

Re: [OAUTH-WG] Partially standardized format for access tokens?

1. ++ 2. ++ 3. ++ 4. ++ as a part of 3., otherwise -- -- justin On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 s

Re: [OAUTH-WG] Partially standardized format for access tokens?

You earlier stated that multiple AS was out of scope. I am aligned that using OAuth 2.0 needs to support the widely deployed social web use cases -- if you recall, I drove getting rid of the signature requirement! :) On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard wrote: > > On Jun 4, 2010, at 8:41

Re: [OAUTH-WG] Partially standardized format for access tokens?

David, are you saying the optional parameter should be a separate spec, or that #3 and #4 are the same thing? (I disagree with both L) I see a new, standard token and specifying the token format are orthogonal. The PR may accept multiple proprietary token types. if we have the parameter in the sp

Re: [OAUTH-WG] Partially standardized format for access tokens?

Am 04.06.2010 19:45, schrieb John Kemp: On Jun 4, 2010, at 1:35 PM, David Recordon wrote: #4 should happen as part of #3. How would ALL OAuth 2.0+ clients know to pass along the format if it is there? I fail to see the problem with specifying an optional token format parameter in t

Re: [OAUTH-WG] Partially standardized format for access tokens?

On Jun 4, 2010, at 1:35 PM, David Recordon wrote: > #4 should happen as part of #3. How would ALL OAuth 2.0+ clients know to pass along the format if it is there? I fail to see the problem with specifying an optional token format parameter in the main spec. and giving it a default value, and se

Re: [OAUTH-WG] Definition of XML response format

How about keeping it even more flat and compact: This also is more simple on the DOM side, just doc.root['access_token'] instead of traversing or xpath. Anyway, I think OAuth 2 is better served in general by the KISS principle . -Kris On Jun 4,

Re: [OAUTH-WG] Partially standardized format for access tokens?

#4 should happen as part of #3. On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 should not prohibit resource owners s

Re: [OAUTH-WG] Partially standardized format for access tokens?

Could I conclude then that "we" are all in "agreement"? :) 1. OAuth 2.0 should not require a structured token (i.e. don't break existing use cases) 2. OAuth 2.0 should not prohibit resource owners supporting multiple Authentication Servers 3. OAuth 2.0 should allow for structured tokens via a

Re: [OAUTH-WG] Partially standardized format for access tokens?

On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > There is more to the web than the social web Luke, and supporting multiple AS > has been a design goal of WRAP and OAuth 2.0 and is being implemented. Whoa, I didn't say there wasn't. I agree that supporting multiple authorization servers is a re

Re: [OAUTH-WG] Partially standardized format for access tokens?

+1 (just in case that was not clear from my other emails :) On 2010-06-04, at 8:57 AM, Torsten Lodderstedt wrote: > +1 for an optional "token_format" attribute/parameter > > Am 04.06.2010 17:21, schrieb John Kemp: >> Hi Luke, >> >> On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: >> >> >>>

Re: [OAUTH-WG] Definition of XML response format

At the risk of betraying my SAML roots, I'd suggest that if name-space and typing like functionality is desired, we not try and reinvent the wheel and actually use a schema. After all, is effectively an attempt at nonstandard namespacing and is the same kind of thing for data typing. XML Schem

Re: [OAUTH-WG] Partially standardized format for access tokens?

+1 for an optional "token_format" attribute/parameter Am 04.06.2010 17:21, schrieb John Kemp: Hi Luke, On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: On 6/4/10 9:53 AM, Luke Shepard wrote: Having a single resource serve

Re: [OAUTH-WG] Partially standardized format for access tokens?

On 6/4/10 9:23 AM, Justin Richer wrote: >> We should solve one problem at a time. It's easy to layer structure >> on top of an opaque blob in a separate spec. > > +1 to this. Token structure seems like a nice idea, but it's outside > what should be dictated by the OAuth spec. We want people to b

Re: [OAUTH-WG] Partially standardized format for access tokens?

On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard wrote: > > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > > > On 6/4/10 9:53 AM, Luke Shepard wrote: > >> > >> Having a single resource server that works with multiple independent > auth servers is not in scope for OAuth. That said, there's nothi

Re: [OAUTH-WG] Partially standardized format for access tokens?

On Fri, Jun 4, 2010 at 8:23 AM, Justin Richer wrote: > > We should solve one problem at a time. It's easy to layer structure > > on top of an opaque blob in a separate spec. > > +1 to this. Token structure seems like a nice idea, but it's outside > what should be dictated by the OAuth spec. We wa

Re: [OAUTH-WG] Partially standardized format for access tokens?

> We should solve one problem at a time. It's easy to layer structure > on top of an opaque blob in a separate spec. +1 to this. Token structure seems like a nice idea, but it's outside what should be dictated by the OAuth spec. We want people to be able to use OAuth to shuttle their existing to

Re: [OAUTH-WG] Partially standardized format for access tokens?

Hi Luke, On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: > > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > >> On 6/4/10 9:53 AM, Luke Shepard wrote: >>> >>> Having a single resource server that works with multiple independent auth >>> servers is not in scope for OAuth. That said, ther

Re: [OAUTH-WG] Definition of XML response format

I'd personally rather see something flatter, even with an implied root namespace defined in the spec. Maybe like: asdfasoij234f 2f098jadfasdfasdf 300 Mirroring the key-value format for the JSON and form-encoded forms, this keeps the field names as elements and the values a

Re: [OAUTH-WG] Partially standardized format for access tokens?

On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > On 6/4/10 9:53 AM, Luke Shepard wrote: >> >> Having a single resource server that works with multiple independent auth >> servers is not in scope for OAuth. That said, there's nothing to stop >> multiple servers to agree amongst themselves t

Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

What if you had a supertoken that was only good for getting subtokens? In other words, only the AS knows about the supertoken (a refresh token, perhaps?), and it allows you to get sub-tokens using the refresh flow to access each of the different services. Then you could grab as many different token

Re: [OAUTH-WG] Partially standardized format for access tokens?

This is exactly the direction UMA is headed (as George knows :-), since we *are* trying to solve for "unmooring" authorization servers and resource servers -- which we call authorization managers and hosts. The absolute simplest thing to do is hand out tokens that are essentially artifacts that

Re: [OAUTH-WG] Partially standardized format for access tokens?

On 6/4/10 9:53 AM, Luke Shepard wrote: Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, t

Re: [OAUTH-WG] Definition of XML response format

So, now that OAuth 2 is not solely SP-centric, it probably makes sense to change some of the encoding (this was written in 2008) :) Also, the interaction with the Authorization server is more constrained than the interaction with the resource owner so that also allows for simplification. I do

Re: [OAUTH-WG] Partially standardized format for access tokens?

+1 to some standardization to the token The URI would also allow for discovery and the ability for the provider to define an endpoint in the XRD for the URI that allows "dumb mode" token validation. This way, even if the resource owner doesn't know how to "crack" the token locally, they could

Re: [OAUTH-WG] Partially standardized format for access tokens?

+1, but why only partially? I would like to add another use case for a standardized token format. Suppose a software vendor wants to built and sell a standard software component (service), e.g. an address book service, which is secured using OAuth2. Having a standardized token format would ma

Re: [OAUTH-WG] Partially standardized format for access tokens?

Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spe

Re: [OAUTH-WG] Definition of XML response format

Thanks, George. From that I get this: token secret >From the text around it, it sounds like SPs were permitted to add to this (presumably using their own element names). While this seems reasonable, it seems that SP-specific extensions that used alternate element names would t

[OAUTH-WG] Partially standardized format for access tokens?

Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client. This access token is in an encrypted format that only the resource server understands. I feel pretty good about this approach as it lends to high security and tokens that on

Re: [OAUTH-WG] Definition of XML response format

I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group. http://groups.google.com/group/oauth-extensions/browse_thread/thread

Re: [OAUTH-WG] Definition of XML response format

In the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me): some access token some refresh token 235298298 So the main points here is: 1. no namespace 2. root tag is called

Re: [OAUTH-WG] "3.4. Client Credentials" text change proposal

+1 -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Saturday, May 08, 2010 6:45 AM To: oauth Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal 3.4. Client Credentials When requesting access from the auth

Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

BTW: the security threat I described in point 4) not only holds for self-contained tokens but also for (super) handles. I consider it especially dangerous if abusing a service causes costs for the end-user. regards, Torsten. Am 03.06.2010 20:27, schrieb Torsten Lodderstedt: I probably exaggera

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Nat, >>> All the request parameters MUST be provided through request file. >>"All" doesn't make much sense if params can still appear in the URI, and >>override the file. > What about this:  > > Request parameters SHOULD be provided through request file.  If it is perfectly legitimate to includ