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 specific user (typically
>> they are, but imagine a secretary granting an app access to his boss's
>> calendar and then leaving the
I will leave this to the security folks to decide but it seems to me that if
the client asks to limit the username of the end user granting access by
specifying it in the request, the server must repeat that information when
issuing such a token. Otherwise, an attacker can force a user to grant
acc
My point is simple. *Server* should be allowed to include a refresh token
with every access token issued. It is already optional everywhere it is
included. What I suggested is to allow it to be optional everywhere.
If the server doesn't support refresh tokens for some flows, it should
simply not p
How about something like this:
When accessing resources using the http URI scheme, clients SHOULD NOT use and
servers SHOULD NOT accept bearer token requests (unsigned requests) as such a
request is equal to sending unprotected credentials in the clear. Instead,
clients SHOULD obtain and utiliz
On 4/7/10 5:23 PM, "Dick Hardt" wrote:
>
>
> On 2010-04-07, at 4:26 PM, Eran Hammer-Lahav wrote:
>
>> * token size limit
>> * restriction on values characters
>> * specificity of the assertion flow
>> * parameter name prefix
>> * single authorization endpoint
>> * inclusion of both user-age
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote:
> I'm assuming that tokens need not be bound to a specific user (typically
> they are, but imagine a secretary granting an app access to his boss's
> calendar and then leaving the company and therefore being removed from the
> calendar ACL, but t
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
I think it depends on which profiles we end up with. If we have the web and
rich client profiles from Dick's WRAP draft plus the JS profile from David's
draft, I would want to return the refresh token with the first two profiles
but not with the third. Since our refresh tokens are going to be very
I would envision that the requests from different flows will have a different
mode value, which makes them uniquely different requests for the AS.
I think returning a refresh token when it can't be used will lead to confusion
for Client and AS developers.
-- Dick
On 2010-04-07, at 1:51 PM, Era
You guys are both right: The recommendation I made before is basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.
--Richard
On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:
Eran
Richard and Lief are describing the same point we had in the past
where Peter s
Eran
Richard and Lief are describing the same point we had in the past where Peter
surmised the discussion that an *implementation* MUST support TLS is required
for bearer tokens to be compliant, and that TLS is recommended for *deployment*
-- Dick
On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav
On 2010-04-07, at 4:26 PM, Eran Hammer-Lahav wrote:
> Latest is always at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth
>
> (xml is always up to date. txt and html when I can. Atom feed available)
>
> ---
>
> I finished going over sections 1-4 which includes the overview, flows, and
>
Latest is always at:
http://github.com/theRazorBlade/draft-ietf-oauth
(xml is always up to date. txt and html when I can. Atom feed available)
---
I finished going over sections 1-4 which includes the overview, flows, and
refresh method. Next is using tokens. By finished I mean those sections a
We are looking at this all wrong.
There are two kinds of protected resources OAuth supports:
* http://
* https://
OAuth provides two kinds of token authentication modes:
* bearer token
* token + signature
I don't know how to translate your statement below into text I can put in
the draft to an
Yes, shorter is better, and we'll get to it later. But all the flows use a
single endpoint (right now), so each request needs a unique type.
EHL
On 4/1/10 7:02 PM, "Paul Walker" wrote:
> Along those lines, I would suggest renaming the mode values as the terms
> "request" and "flow" are kinda s
Right now most of the flows return the same parameters (access token,
expiration, refresh token). A few do not return a refresh token. When we add
signatures, we will need to add token secret and algorithm type.
I know there are good reasons why certain flows do not return a refresh
token but inst
Hi Marius,
Am 07.04.2010 00:39, schrieb Marius Scurtescu:
On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt
wrote:
Hi all,
here at Deutsche Telekom, we see the need for a flow supporting the exchange
of access tokens for one service into access tokens for another service.
The scenari
I'm assuming that tokens need not be bound to a specific user (typically
they are, but imagine a secretary granting an app access to his boss's
calendar and then leaving the company and therefore being removed from the
calendar ACL, but the app still keeping access by virtue of the capability
grant
On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav wrote:
> What about an attacker changing the username similar to the way a
> callback can be changed?
>
I don't think there is a danger here.
We still use all of the safeguards in place from the rest of the flow -
adding this parameter never lo
To re-iterate and clarify Leif's second point, I would be in favor of
making TLS:
-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)
This a pretty universal pattern in IETF protocols.
--Richard
On Apr 7, 2010, at 7:20 AM, Leif Johansson wr
Go implement whatever you want. But the spec should set the highest
practical bar it can, and requiring HTTPS is trivial.
As a practical note, if the WG reaches consensus to drop the MUST, I would
ask the chairs to ask the security area and IESG to provide guidance whether
they would approve su
While odd, this is a perfectly legal GET request with a form-encoded body.
EHL
On 4/7/10 3:33 AM, "Greg Beech" wrote:
Hi
I noticed that there is an error in the example for section 3.4.1.1 in
the latest OAuth draft. The example of building a signature base string
uses the following request as
Hi
I noticed that there is an error in the example for section 3.4.1.1 in
the latest OAuth draft. The example of building a signature base string
uses the following request as an example (note the extraneous query
parameters at the bottom):
GET /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1
On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote:
That's only when you need to trust the client. If your requirements demand
registration, discovery is mostly pointless (other than dynamic configuration).
At the risk of comparing apples and pears - many large-scale SAML
deployments rely on di
What about an attacker changing the username similar to the way a callback can
be changed?
EHL
On 4/6/10 11:14 PM, "Evan Gilbert" wrote:
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
25 matches
Mail list logo
