Am 19.04.2010 22:37, schrieb Brian Eaton:
On Mon, Apr 19, 2010 at 1:34 PM, Torsten Lodderstedt
wrote:
Do you mean the thread "Signatures, Why?"
(http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy)?
I cannot remember that there was a consensus not to use signatures on
requests to
please, add the scope parameter to the flows and the refresh token
request as well. This way, client can obtain refresh tokens with broad
scope and narrow down it for particular request (least privileges principle)
regards,
Torsten.
Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav:
Proposal:
'
Am 20.04.2010 05:06, schrieb Dick Hardt:
On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote:
2. Server requires authentication
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm='Example', scope='x2'
Can more than one scope be returned? Is it a comma delimited list?
I
On Mon, Apr 19, 2010 at 9:50 PM, Dick Hardt wrote:
>
> On 2010-04-19, at 9:46 PM, Peter Saint-Andre wrote:
>
>> On 4/18/10 6:46 PM, Dick Hardt wrote:
>>
>>> Given the practice that the authorization endpoint and the redirect_uri
>>> can contain URI query parameters, then differentiating between
>>
On 2010-04-19, at 9:46 PM, Peter Saint-Andre wrote:
> On 4/18/10 6:46 PM, Dick Hardt wrote:
>
>> Given the practice that the authorization endpoint and the redirect_uri
>> can contain URI query parameters, then differentiating between
>> application specific query parameters and OAuth protocol p
On 4/18/10 6:46 PM, Dick Hardt wrote:
> Given the practice that the authorization endpoint and the redirect_uri
> can contain URI query parameters, then differentiating between
> application specific query parameters and OAuth protocol parameters by
> prefixing the OAuth parameters with oauth_ wou
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 4:37 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
> On Mon, Apr 19, 2010 at 2:20 PM, Eran Hammer-Lahav
> wrote:
> >
> >> -O
On Mon, Apr 19, 2010 at 8:03 PM, Marius Scurtescu wrote:
> Hi Eran,
>
> The spec looks really good, thanks for all the work you put into it.
>
> I think it was a good idea to remove the 401 responses and use only 400.
>
>
In WRAP we had used 401s when the client credentials were invalid and 400
wh
>HTTP/1.1 401 Unauthorized
>WWW-Authenticate: Token realm='Example', scope='x2'
I assume the WWW-Authenticate response header also has an "authz-uri" parameter.
WWW-Authenticate: Token realm='Example', scope='x2',
authz-uri="https://as.example.com/";
The first time a client app get
8:30am might be a tad early ...
On Mon, Apr 19, 2010 at 2:23 PM, IESG Secretary wrote:
> Location:
>
> This interim meeting is attached to the Internet Identity Workshop
> (see http://www.internetidentityworkshop.com/) in Mountain View, CA.
>
> Time:
>
> 20th of May, 8:30am - 6pm
>
> Meeting Host
On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote:
> 2. Server requires authentication
>
>HTTP/1.1 401 Unauthorized
>WWW-Authenticate: Token realm='Example', scope='x2'
Can more than one scope be returned? Is it a comma delimited list?
I wonder how much value this will provide. (I like
Hi Eran,
The spec looks really good, thanks for all the work you put into it.
I think it was a good idea to remove the 401 responses and use only 400.
A few minor comments bellow:
3.5.1
The client is described as being incapable to act as a HTTP server,
and of receiving incoming request. The
On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav wrote:
> Thanks. That makes sense.
>
>
>
> My concern is that the client will ask for a specific username but an
> attacker will change that request before it hits the server. The server then
> asks the (wrong) user to authenticate and returns a
On Mon, Apr 19, 2010 at 2:24 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, April 19, 2010 1:58 PM
>> To: Eran Hammer-Lahav
>> Cc: Dick Hardt; OAuth WG
>> Subject: Re: [OAUTH-WG] Issue: state in web server flow
On Mon, Apr 19, 2010 at 2:20 PM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, April 19, 2010 1:50 PM
>
>> I did a proof of concept implementation, with client, server and protected
>> resource support libraries,
On Apr 19, 2010, at 6:17 PM, Eran Hammer-Lahav wrote:
[...]
>>>
>>
>> I think that there is much that is unspecified in this model and thus it
>> doesn't
>> provide much interoperability. If we don't tell the client what to do with
>> the
>> scope, and we don't specify what a server means by
> -Original Message-
> From: John Kemp [mailto:j...@jkemp.net]
> Sent: Monday, April 19, 2010 2:59 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
> On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrote:
>
> > Proposal:
> >
> > 'scope' is
On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrote:
> Proposal:
>
> 'scope' is defined as a comma-separated list of resource URIs or resource
> groups (e.g. contacts, photos).
So, 'scope' at the authenticating (via OAuth) server is simply a list of one or
more URIs? There are no defined, int
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Richard Barnes
> Sent: Monday, April 19, 2010 2:29 PM
> To: Mike Moore
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
>
> On the other hand, if you've al
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 2:07 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs
> OAuth
>
> On Mon, Apr 19, 2010 at 11:06 AM, Eran Hammer-L
On the other hand, if you've already got a JSON or XML library on hand
(as many apps these days do), then JSON/XML is a lot easier to handle
than form-encoded. Plus, if you're not re-using form-encoding, then
there's no risk of being confused with actual "forms" / request
parameters. Not
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 1:58 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
> Subject: Re: [OAUTH-WG] Issue: state in web server flow
>
> On Mon, Apr 19, 2010 at 11:53 AM, Eran Hammer-Lahav
> wrot
Location:
This interim meeting is attached to the Internet Identity Workshop
(see http://www.internetidentityworkshop.com/) in Mountain View, CA.
Time:
20th of May, 8:30am - 6pm
Meeting Host:
Yahoo
(address & room to be announced)
Agenda:
Discussion of open issues around OAuth 2.0.
Up-to-da
+1 Eran's proposal as well
On Mon, Apr 19, 2010 at 1:34 PM, Torsten Lodderstedt
wrote:
> +1
>
> Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav:
>>
>> Proposal:
>>
>> 'scope' is defined as a comma-separated list of resource URIs or resource
>> groups (e.g. contacts, photos). The server can provide
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 1:50 PM
> How does defining the scope structure help interop?
Clients can use scopes the same way across provides and don't need to read
paperwork to figure out how to use the pa
On Mon, Apr 19, 2010 at 11:06 AM, Eran Hammer-Lahav wrote:
> Initially I don't think it is a problem because only OAuth 2 servers will use
> it. Later it becomes a question of discovery and what you do once you get
> such a challenge from a server you are unfamiliar with.
I think that many prot
On Mon, Apr 19, 2010 at 11:53 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, April 19, 2010 10:18 AM
>
>> I don't think it is possible to enforce callbacks without any query
>> parameters.
>> See the Drupal
On Mon, Apr 19, 2010 at 11:14 AM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, April 19, 2010 11:04 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>>
>> On Mon,
On Mon, Apr 19, 2010 at 1:34 PM, Torsten Lodderstedt
wrote:
> Do you mean the thread "Signatures, Why?"
> (http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy)?
>
> I cannot remember that there was a consensus not to use signatures on
> requests to the authorization server.
I can. =)
+1
Am 19.04.2010 18:25, schrieb Eran Hammer-Lahav:
Proposal:
'scope' is defined as a comma-separated list of resource URIs or resource
groups (e.g. contacts, photos). The server can provide a list of values for
the client to use in its documentation, or the client can use the URIs or
scope iden
Do you mean the thread "Signatures, Why?"
(http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy)?
I cannot remember that there was a consensus not to use signatures on
requests to the authorization server.
regards,
Torsten.
Am 19.04.2010 22:14, schrieb Eran Hammer-Lahav:
Which is so
Which is something we decided not to do when we discussed the use of signatures.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, April 19, 2010 12:19 PM
To: Eran Hammer-Lahav
Cc: Evan Gilbert; OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
in o
On Mon, Apr 19, 2010 at 1:03 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
>
> So what should be the singlemost encoding to be standardized? I would be
> unable to choose one.
>
I think form encoding is just fine. Its lightweight, minimalistic, and easy
to implement. I don't see a rea
in oder to prevent such attacks, one could sign the inbound request
regards,
Torsten.
Am 19.04.2010 19:58, schrieb Eran Hammer-Lahav:
Thanks. That makes sense.
My concern is that the client will ask for a specific username but an
attacker will change that request before it hits the server. T
Am 19.04.2010 17:59, schrieb Mike Moore:
On Mon, Apr 19, 2010 at 9:25 AM, Eran Hammer-Lahav
mailto:e...@hueniverse.com>> wrote:
You are missing the point.
No, I get it. But what I like about OAuth 1.0 was its simplicity. I
don't see how allowing either the server or client
to suggest al
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 10:18 AM
> I don't think it is possible to enforce callbacks without any query
> parameters.
> See the Drupal example.
In the Drupal example the client server adds its silly para
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 10:25 AM
> Maybe we should consider passing parameters some other way, and not part
> of query strings. JSON?
Please propose text.
EHL
___
I am not sure we can specify how callbacks are registered which is where your
syntax resides. The whole registration process is out of scope. The server has
*something* and needs to match the callback in the request to it.
My proposal is to provide a narrow facility with the client state paramet
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, April 19, 2010 11:04 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
> On Mon, Apr 19, 2010 at 9:25 AM, Eran Hammer-Lahav
> wrote:
> > Proposal:
Initially I don't think it is a problem because only OAuth 2 servers will use
it. Later it becomes a question of discovery and what you do once you get such
a challenge from a server you are unfamiliar with.
I proposed Token because it is in line with other HTTP authentication schemes:
Basic an
On Mon, Apr 19, 2010 at 9:25 AM, Eran Hammer-Lahav wrote:
> Proposal:
>
> 'scope' is defined as a comma-separated list of resource URIs or resource
> groups (e.g. contacts, photos).
How will commas in URIs be escaped? We just forbid them?
If the scope elements are URIs then a space separated lis
Thanks. That makes sense.
My concern is that the client will ask for a specific username but an attacker
will change that request before it hits the server. The server then asks the
(wrong) user to authenticate and returns a token. The client has no way of
knowing it got an access token for the
On Mon, Apr 19, 2010 at 8:39 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Brian Eaton [mailto:bea...@google.com]
>> Sent: Monday, April 19, 2010 8:37 AM
>> To: Dick Hardt
>> Cc: Eran Hammer-Lahav; OAuth WG
>> Subject: Re: [OAUTH-WG] Clarification: authorization server ma
The scenario described by Evan is showing a real issue and the
username parameter is solving it. Not sure if there are other
implications, but definitely worth discussing.
Marius
On Mon, Apr 19, 2010 at 10:06 AM, Evan Gilbert wrote:
> User 1 is logged into Client site
> User 2 is logged into I
On Sun, Apr 18, 2010 at 11:07 PM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Sunday, April 18, 2010 1:38 PM
>
>> Also, when implementing OAuth 2.0 people will take into account existing
>> parameters and will avoid t
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 collisions makes sense, but I think th
This seems pretty elegant to me. I like that in the general case, the protected
resource can give an error saying the scope required.
As a specific example of how Facebook could use this, we have an extended
permission for an app to publish to a user's stream. If an app tries to publish
to the
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 collisions makes sense, but I think there are no known
> conflicts and you can always add a redirection l
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: OAuth WG
On Mon, Apr 19, 2010 at 8:39 AM, Eran Hammer-Lahav wrote:
>> The first is before redirecting the user to the callback URI. This seems
>> doomed to being service provider specific, unfortunately.
>
> I agree. If someone wants to suggest some security consideration text that
> would be good.
See
User 1 is logged into Client site
User 2 is logged into IDP site
This can happen quite frequently, as client sites often have long-lived
cookies and may only be visited by one user on a shared computer.
Right now client site has no way to ask for a token for User 1, and end
result will be that Us
Isn't "Token" as a scheme to generic/ambiguous?
If a protected resource accepts several types of Authorization
headers, how can it be sure this is an OAuth 2.0 token and not some
other kind?
If adding a version parameter is too verbose, how about "OAuth2" as scheme?
Marius
On Sun, Apr 18, 201
Proposal:
'scope' is defined as a comma-separated list of resource URIs or resource
groups (e.g. contacts, photos). The server can provide a list of values for
the client to use in its documentation, or the client can use the URIs or
scope identifier of the protected resources it is trying to acce
On 4/19/10 8:51 AM, "Evan Gilbert" wrote:
>
>
> 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 Oscope¹
On Mon, Apr 19, 2010 at 9:25 AM, Eran Hammer-Lahav wrote:
> You are missing the point.
>
No, I get it. But what I like about OAuth 1.0 was its simplicity. I don't
see how allowing either the server or client to suggest alternate encodings
allows OAuth 2.0 to do more. I don't think the added compl
+1 to the "Device" idea. About a year ago I brought up the idea of
having an instance identifier as an OAuth extension, but that never got
traction and I dropped the thread.
-- justin
On Mon, 2010-04-19 at 09:03 -0400, Torsten Lodderstedt wrote:
> +1 to #1 (as starting point)
>
> In my opinion,
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
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Monday, April 19, 2010 8:37 AM
> To: Dick Hardt
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: authorization server matching of
> redirect URI
>
> On Sun, Apr 18, 2010 at 10:35 PM, Dic
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:33 AM, "Evan Gilbert" wrote:
More details on this enhancement.
Goal: Make sure you get an access token for the right user in immediate mod
On Sun, Apr 18, 2010 at 10:35 PM, Dick Hardt wrote:
> The spec should describe how the redirect URI is verified to what is
> registered. I can enumerate the options for discussion adding in the state
> parameter as an option.
Note that there are two spots where the AS does some URI matching.
T
More details on this enhancement.
Goal: Make sure you get an access token for the right user in immediate
mode.
Use case where we have problems if we don't have username parameter:
1. Bob is logged into a web site as b...@idp.com.
2. Mary (his wife) is logged into IDP on the same computer
You are missing the point. The server will be required to support one of
these, but allowed to offer more. If your client is limited, just support
the required format. This is good for clients as it guarantees both interop
and flexibility.
The downside, like anything else, is a more complex protoc
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 argument, but so is striving for actual
interop. Almost every single
> > Also, when implementing OAuth 2.0 people will take into account existing
> > parameters and will avoid them, they will chose other parameter names (if
> > possible). If the next version of OAuth, let's call it 2.1, adds a few new
> > parameters, how can we chose them so they don't collide with
On Mon, Apr 19, 2010 at 5:48 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
>
> We can also offer both and define a client request parameter (as long as
>> the server is required to make at least one format available).
>>
>
> +1 on this
>
-1 on this. As a client I don't want to have
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
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:
For this section I would like to understand the logic of using polling
rather than a client blocking. I could imagine several legitimate
reasons, but the text isn't there, and I have a very vivid (and
sometimes wrong) imagination.
Eliot
___
OAuth m
+1 to #1 (as starting point)
In my opinion, the WG should try to work towards #2. Would it be
possible to first collect what kind of "scope" implementations use
today and what ideas exists?
Based on our experiences with implementing OAuth 1.0a at Deutsche
Telekom, I see the following aspe
> I'm strongly opposed to writing a spec that must be profiled in order to be
> implemented and the proposed definition of the scope parameter mandates
> profiling the spec.
I'm strongly opposed to having a specification that can't be used because it's
so restrictive
From: oauth-boun...@ietf.o
We can also offer both and define a client request parameter (as
long as the server is required to make at least one format available).
+1 on this
regards,
Torsten.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dick Hardt
Sent:
I will work with Eran on this issue.
Eliot Lear wrote:
Hannes,
Can we please ask impose on our hosts to provide a room that is
suitable for conference calls? I would be happy to assist with WebEx
arrangements.
Eliot
On 4/19/10 12:41 PM, Hannes Tschofenig wrote:
Hi all,
I put the info ab
Hannes,
Can we please ask impose on our hosts to provide a room that is suitable
for conference calls? I would be happy to assist with WebEx arrangements.
Eliot
On 4/19/10 12:41 PM, Hannes Tschofenig wrote:
Hi all,
I put the info about the interim meeting on the WG Wiki page:
http://trac.
Hi all,
I put the info about the interim meeting on the WG Wiki page:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting
I hope that the ongoing travel problems will be solved soon. We will have an
OAuth WG session also at IETF#78. I will work with Eran on the remote
participation.
74 matches
Mail list logo
