(Note that in my use case, it's actually the client who wants to dispose of
its dangerous full-access token as quickly as possible, retaining only the
least-authority token it needs to continue its ongoing work. This would be
the case even if the token granting service is handing out tokens like f
Am 11.05.2010 01:43, schrieb Yaron Goland:
---
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 th
I'm wondering if this could be achieved by adding an optional scope
parameter to the existing refresh request versus creating a new
request type. Both because Dick's proposed text requires a refresh
token and it seems like services worried about this sort of risk would
not want to issue long lived
Yes; a service that does a one time configuration step, requiring
extensive access, followed by an ongoing lower level of access (say,
read-only). Lowering access means it only needs to store low-risk
tokens in its data store, limiting exposure (and liability).
On Monday, May 10, 2010, Eran Hamme
I don't know of use cases, but if we are going to have this as a capability in
the spec, then here is a suggested mechanism.
-- Dick
On 2010-05-10, at 7:51 PM, Eran Hammer-Lahav wrote:
> Are there actual use cases for this? Either way sounds like it belongs in an
> extension.
>
> EHL
>
>> -
Sweet, +1 then to adding this as an optional return parameter when
receiving an access token.
On Mon, May 10, 2010 at 8:52 PM, Manger, James H
wrote:
> Correct. All your examples match my intention, David.
>
> --
> James Manger
>
>
> -Original Message-
> From: David Recordon [mailto:reco
Correct. All your examples match my intention, David.
--
James Manger
-Original Message-
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, 11 May 2010 1:46 PM
To: Eran Hammer-Lahav
Cc: Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is va
On Mon, May 10, 2010 at 10:43 PM, Eran Hammer-Lahav wrote:
>
> What?
>
> Basic auth seems to be working just fine for the entire web...
I hadn't heard of implementations hitting a limitation on header size,
but Basic and Digest are both broken.
Basic leaves the input character encoding unspecifi
If the sites parameter is not specified, would it default to the
domain of the authorization server. If it is specified, then the valid
sites are what is explicitly listed. Wildcards would only be supported
for subdomains and it would be assumed that any resource on that
domain is valid.
Thus with
Redirections are a bad example when used with an access token in the query
parameter...
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of David Recordon
> Sent: Monday, May 10, 2010 6:34 PM
> To: Manger, James H
> Cc: OAuth WG (oauth@i
I don't see how moving the discussion/work on these features elsewhere will
help reach consensus on them. If someone has an idea that fails to get momentum
on this list, they should work harder or reach out to the key people on this
list in private and try to talk them into supporting it. Back-c
Propose text.
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, May 10, 2010 1:16 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
>
> On Sun, May 9, 2010
Are there actual use cases for this? Either way sounds like it belongs in an
extension.
EHL
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Monday, May 10, 2010 12:49 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
> Subject: Re
I strongly agree.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, May 10, 2010 5:31 PM
To: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] sites with wildcard
Yaron,
> I don’t understand the scenario that requires this
> -Original Message-
> From: Yaron Goland [mailto:yar...@microsoft.com]
> Sent: Monday, May 10, 2010 4:43 PM
> > 2. Client Authentication (in flows)
> >
> > How should the client authenticate when making token requests? The
> > current draft defines special request parameters for sendin
Brian,
OAuth bearer tokens are to a large degree glorified cookies. Cookies have been
massively deployed in the wild with their own variety of a "sites" parameter
("domain", "path" and "secure" parameters).
The biggest different between cookies and OAuth tokens today is that a client
app needs
Hi David,
> I guess the way that we solved this was having the Protected Resource
> include the access token in links as applicable.
Yes, I noticed Facebook did this in some actual responses (though I don't think
I saw it documented).
I don't personally think it is a great architectural choice,
Hey James,
I guess the way that we solved this was having the Protected Resource
include the access token in links as applicable. We don't do cross
site access tokens and I'd hate to see us standardize this more
complex use case without real world deployment experience.
Do you have an implementati
I'm concerned about prematurely standardizing something which we don't
have deployment experience to guide. One of the things I like most
about OAuth 2.0 is that we're largely not inventing new things. Rather
learning from what others have done in the past.
My view is that redelegation should firs
If you're volunteering to draft text, then go for it. Otherwise I'm
unclear what you're actually proposing...
And we do have an implementation of scope in the wild. See "Requesting
Extended Permissions" on
http://developers.facebook.com/docs/authentication/.
--David
On Mon, May 10, 2010 at 4:50
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
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 logic, user-generated
content, or a parameter in the request URI (eg an open r
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 that
returns an Atom feed.
The feed contains lots of entries, with lin
On 2010-05-10, at 4:20 PM, Brian Eaton wrote:
> On Sun, May 9, 2010 at 7:34 PM, Dick Hardt wrote:
>> There a couple of choices for the flows for how a successful delegation is
>> conveyed to the delegate. The AS could return a delegation code that is
>> similar to a verification code and the d
+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
+1
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, May 10, 2010 4:11 PM
> To: Manger, James H
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] sites with wildcard
>
> On Mon, May 10, 2010 at 7:32 AM, M
On Mon, May 10, 2010 at 4:46 PM, Manger, James H
wrote:
> Marius,
>
>> As a side note, I was thinking more about the suggested "sites"
>> parameter. In practice that sites where an access token can be used is
>> limited to what protected resources can decrypt or verify the token.
>> An access toke
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
Marius,
> As a side note, I was thinking more about the suggested "sites"
> parameter. In practice that sites where an access token can be used is
> limited to what protected resources can decrypt or verify the token.
> An access token cannot be really used at the wrong site. A "sites"
> parameter
I don’t understand the scenario that requires this feature. When does someone
ask for a token without knowing where it is going?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, May 10, 2010 7:33 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OA
Please see inline
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, May 09, 2010 2:07 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>
> DEADLINE: 5/13
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
On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wrote:
>> "The client is incapable of receiving incoming requests from the
>> authorization
>> server (incapable of acting as an HTTP server). ADD:
>> The device manufacturer is assumed to have registered with the
>> authorization server. The a
On Sun, May 9, 2010 at 7:34 PM, Dick Hardt wrote:
> There a couple of choices for the flows for how a successful delegation is
> conveyed to the delegate. The AS could return a delegation code that is
> similar to a verification code and the delegate acquires an access token
> similar to 3.6.2
On Sun, May 9, 2010 at 1:56 PM, Eran Hammer-Lahav wrote:
> The authorization server can issue an access token with any expiration but
> should not issue expiration
> later than that of the assertion. But still, there is nothing to prevent that.
Wait, why shouldn't the authorization server issue
On Mon, May 10, 2010 at 7:32 AM, Manger, James H
wrote:
> HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good match to
> how Google uses scope
> values.
It's not, actually. Our scopes are sometimes URI prefixes, and
sometimes are not. The reality is complicated, and to be hone
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 just split on & and =, they often don't trim
extra wh
Let me try to offer some of those "logical, positive statements in favour of
the technical merits of JSON over the original format choice" for those that
aren't familiar or haven't gleaned them from the thread thus far:
- unambiguous spec for encoding/decoding (including how to represent spaces
an
On Fri, May 7, 2010 at 11:29 AM, Greg Brail wrote:
> JSONObject is fine. I imagine that any development organization could use it
> in their project as long as their legal staff is willing to forgo the option
> of doing Evil. (That's what the license says ;-)
If the issue is purely the quirky lic
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 encoding here, since the URI fragment
is handled
by a client more or less like a response result.
Evan mentio
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
>
>> >> 8.1. The Authorization Request Header
>> >>
>> >> I consider the name "Token" of the authentication schema much
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
>> >>
>> >> If the client has previously registered a redirection URI with
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 encoding here, since the URI fragment is handled
> by a client more or less like a response result.
Evan mentioned that returning JSON in this case is a bad idea be
On Sun, May 9, 2010 at 10:40 PM, Eran Hammer-Lahav wrote:
>> 7. Refreshing an Access Token
>>
>> I would suggest to add an optional "scope" parameter to this request.
>> This could be used to downgrade the scope associated with a token.
>> >>>
>> >>> That would be the wrong wa
On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav wrote:
> This would only work for the client credentials flow (because you keep the
> same authorization source). For all other flows you are breaking the
> authorization boundaries.
If the requested scope is a subset of the original scope asso
Am 10.05.2010 00:25, schrieb Eran Hammer-Lahav:
3.2.1. Response Format
The authorization server MUST include the HTTP "Cache-Control"
response header field with a value of "no-store" in any response
containing tokens, secrets, or other sensitive information.
Would'nt it make sense
On 10/05/2010 15:56, Dick Hardt wrote:
>
> On 2010-05-10, at 1:11 AM, Pid wrote:
>
>> On 10/05/2010 07:57, Joseph Smarr wrote:
1. Server Response Format
>>>
>>> I vote for B, though I could live with C. (A would make me sad though)
>>>
>>> We've had a healthy and reasonable debate about the
On Sun, May 9, 2010 at 2:00 PM, Eran Hammer-Lahav wrote:
> Seems like extra complexity for little gain. The only benefit is saving
> server resources when a refresh token isn't going to be used by the client,
> but since most clients are likely to use it, the saving isn't much.
You could be rig
On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Monday, April 26, 2010 11:27 PM
>> To: David Recordon
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] devi
On Mon, May 10, 2010 at 6:20 AM, Paul Madsen wrote:
> Related, is anybody thinking of a variant of the device flow where the
> user-agent sits on a device with QR-code capabilities, and so the user
> needn't type anything (uri or code)?
The end user will point their phone to the device screen and
Hi James,
I was suggesting a transparent token format in general, SWT was just
an example. Yes, SWT does have a few problems:
- symmetric key encryption
- URL encoded name/value pairs as format
It can be easily extended to support public key crypto, but this will
help only key management between
Am 09.05.2010 23:06, schrieb Eran Hammer-Lahav:
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. Issues with consensus w
Thanks for the clarity Eran and I understand.
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Sunday, May 09, 2010 1:57 PM
To: Foiles, Doug; OAuth WG
Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)
> -Original Message-
>
On Sun, May 9, 2010 at 3:06 PM, 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. Issues w
On 2010-05-10, at 1:11 AM, Pid wrote:
> On 10/05/2010 07:57, Joseph Smarr wrote:
>>> 1. Server Response Format
>>
>> I vote for B, though I could live with C. (A would make me sad though)
>>
>> We've had a healthy and reasonable debate about the trade-offs here, but
>> I think the main countera
There are various ways to indicate where a token can be used (when an
authorization server issues a token to a client app).
A. List of URI prefixes
B. List of scheme://host[:port] tuples
C. List of domain names
D. Any of the above lists with a wildcard to include all sub-domains, eg
“sites”
some feedback wrt the device flow
- 'verification URI' and 'authorization URI' are used interchangeably
- in the example messages, the verification code the client sends on its
request for an access token is 'J2vC42OifV', not the same as that
previously issued by the authorization server, name
1. Server Response Format
A. Form-encoded only (original draft)
B. JSON only (current draft)
C. JSON as default with form-encoded and XML available with an optional
request parameter
Vote for C, to be specified as: "Server MUST support JSON, form-encoded, and
XML. Client MAY request any of
So long as we keep some language in the text that this is the endpoint where
the authorization by the user takes place, this change makes sense to me.
People coming from OAuth 1 and similar schemes are going to be looking for the
"authorization" part, I think.
-- Justin
__
+1
Any information that the client needs to care about should live outside the
token.
-- Justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Sunday, May 09, 2010 5:29 PM
To: David Recordon; Ma
> 1. Server Response Format
No Preference
> 2. Client Authentication (in flows)
> A. Client authenticates by sending its credentials using special
parameters (current draft)
> B. Client authenticated by using HTTP Basic (or other schemes supported
by the server such as Digest)
Prefer B
Mark
You can find the idea of re-delegation on
http://tools.ietf.org/id/draft-vrancken-oauth-redelegation-01.txt
About the main concern that Eran is indicating, my view is that at the time the
user is authorizing the request giving authority to the client to act on behalf
of the user, the approval i
On 10/05/2010 07:57, Joseph Smarr wrote:
>> 1. Server Response Format
>
> I vote for B, though I could live with C. (A would make me sad though)
>
> We've had a healthy and reasonable debate about the trade-offs here, but
> I think the main counterargument for requiring JSON support is that it's
>
63 matches
Mail list logo
