Re: [OAUTH-WG] OAuth discovery draft?

2010-06-25 Thread Torsten Lodderstedt
I think it should be possible to discover a resource's OAuth server and its capabilities using a direct Discovery request. I don't think a WWW-Authenticate Header is the right representation for this kind of data. What about a JSON or XML document returned in response to an OPTIONS request

Re: [OAUTH-WG] OAuth 2 for Native Apps

2010-06-25 Thread Torsten Lodderstedt
comment/question regarding the Embedded Browser scenario: Is the URL bar and SSL verification symbols (lock + green bar) visible in that scenario? Otherwise, the user has no chance to verify the identity of the IDP/OAuth server. So there might be problems regarding password phishing . regards

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

2010-06-25 Thread Dick Hardt
The RFC term is base64url which turns up much better results when searching. "URL safe base64" is also a good search term. Note that the token may also be included in the HTTP header. base64url encoding works well for HTTP headers. Note that the token is opaque to the client, so being plain tex

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

2010-06-25 Thread Naitik Shah
So my litmus test was looking on the web for "web base 64" or "web base64". Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a native base64, and the C# one doesn't seem to have the web version (a bit

[OAUTH-WG] Proposal for text for section 2

2010-06-25 Thread Yaron Goland
Motivating Scenario: A client makes a request to a token endpoint. It uses an authorization token to authenticate itself and a refresh token to authenticate it's delegated right. This approach to authenticating clients is used in enterprises all the time because it's good security practice to se

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

2010-06-25 Thread John Panzer
There are 2 characters that are different between base64 and base64url. Many good libraries support both (as they're both useful, and both are in the base64 RFC spec); the ability to eliminate a class of encoding problems seems like a good trade-off for, in some languages without full base64 suppo

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Justin Hart
+1 towards space-seperated strings. It seems like every server is going to have diverging requirements on scopes, so anything more will be awfully hard for everyone to agree on. -- Justin Hart -- jh...@photobucket.com On Jun 25, 2010, at 12:14 PM, Eran Hammer-Lahav wrote: > I like th

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

2010-06-25 Thread Naitik Shah
On Fri, Jun 25, 2010 at 11:39 AM, Breno wrote: > On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard > wrote: > > Brian, Dirk - just wondering if you had thoughts here? > > > > The only strong reason I can think of for base64 encoding is that it > allows for a delimiter between the body and the signa

Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint

2010-06-25 Thread Eran Hammer-Lahav
> -Original Message- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, June 17, 2010 2:56 PM > >> Basically, why cannot be that problem solved by 2 different requests, > >> both done by the JavaScript layer? > >> > >> If latency is a problem, it would be good to kn

Re: [OAUTH-WG] client secret used in Native App profile

2010-06-25 Thread Eran Hammer-Lahav
The current prose makes the distinction as a matter of practicality, not normative language. IOW, it uses these labels to provide an introduction on how OAuth may be applied to these well establish client types. However, when it comes to the actual endpoints (once the simplification proposal mak

Re: [OAUTH-WG] client secret used in Native App profile

2010-06-25 Thread Brian Dunnington
I think the line between 'native apps' and 'user-agent apps' is fuzzier than that. if the only difference being considered is that user-agent apps are not compiled (Javascript) vs. native apps that are, that is not the whole picture. some native apps may not be compiled (think Python, etc) and even

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

2010-06-25 Thread Breno
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard wrote: > Brian, Dirk - just wondering if you had thoughts here? > > The only strong reason I can think of for base64 encoding is that it allows > for a delimiter between the body and the signature. Is there any other reason? Without base64 encoding

Re: [OAUTH-WG] proposal for signatures

2010-06-25 Thread William Mills
+1 for optional > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Breno > Sent: Friday, June 25, 2010 11:02 AM > To: Luke Shepard > Cc: hannes.tschofe...@gmx.net; OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures > > On Fri, Jun

Re: [OAUTH-WG] How do autonomous clients asks for access tokens?

2010-06-25 Thread Yaron Goland
Sorry. I screwed up. I somehow missed "none" as an option. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, June 25, 2010 11:20 AM To: Yaron Goland Cc: OAuth WG (oauth@ietf.org) Subject: RE: How do autonomous clients asks for access tokens? The access grants do not correlate to

Re: [OAUTH-WG] Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
The language parameter will need a new spec (doesn't have to be an RFC, but that's open to debate), and will register the parameter in the IANA registry for that endpoint. In order to register, the request will be posted to a public list and a designated expert(s) will review it in a timely mann

Re: [OAUTH-WG] OAuth discovery draft?

2010-06-25 Thread Yaron Goland
Revocation - My assumption is that Yochi would tell Yahoo Calendar to pull Leon's permission. This would happen out of band. When Live Calendar (Leon's service provider) tries to use its refresh token to get an access token from Yahoo's token endpoint the request will fail because the permission

Re: [OAUTH-WG] Clients authenticating with assertions

2010-06-25 Thread Eran Hammer-Lahav
We never had support for two assertions in one request. The client authenticates itself and can include an assertion (or use type 'none'). The client credentials are the "client assertion" and the assertion is about the resource owner. Also, you can define an assertion type that's a composite a

[OAUTH-WG] Clients authenticating with assertions

2010-06-25 Thread Yaron Goland
If a client wants to authenticate itself to a token endpoint to get an access token using an assertion how should it do it? Grant_Type = assertion doesn't seem right because that assertion should be from the resource owner who delegated the permission, not from the client, right? In other words

Re: [OAUTH-WG] Extensibility for OAuth?

2010-06-25 Thread Dick Hardt
Agree that if it is a different kind of function, than a new end point is a good thing. I'm not understanding the review process below in your example. Would adding language parameters not be an extension? Would that need to be a change to the spec or a new spec? . On 2010-06-25, at 11:18 AM, E

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
That's coming in -09. EHL > -Original Message- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Friday, June 25, 2010 11:19 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > I'm ok w

Re: [OAUTH-WG] How do autonomous clients asks for access tokens?

2010-06-25 Thread Eran Hammer-Lahav
The access grants do not correlate to the profiles anymore. For example, user-agent uses the authorization-code access grant. The section lists how an autonomous client can use the client credentials or assertion to obtain an access token. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Dick Hardt
I'm ok with that if we provide some guidance in the spec to implementors that recommends the use of URIs for scopes they expect to be standardized. On 2010-06-25, at 11:14 AM, Eran Hammer-Lahav wrote: > I like the idea of an extensibility mechanism for standard scopes, but I am > not sure I lik

Re: [OAUTH-WG] Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
I think the two endpoints are currently well defined. For example, the token endpoint always takes an access grant and turns it into an access token with optional refresh token. To "extend" it to say, register new clients dynamically, is a bad thing. But adding a new parameter (such as language)

[OAUTH-WG] How do autonomous clients asks for access tokens?

2010-06-25 Thread Yaron Goland
Section 1.4.4 says that autonomous clients can get access tokens. But how? What grant_type should they use? Thanks, Yaron P.S. I looked for a grant_type of autonomous but I didn't see it in -08. Sorry if I missed it.

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
I like the idea of an extensibility mechanism for standard scopes, but I am not sure I like the idea of a prefix or reserved characters. Using URIs as scope values was a requirement (and something that is currently deployed by Google). We defined space-delimited to make simple strings and URIs p

Re: [OAUTH-WG] Extensibility for OAuth?

2010-06-25 Thread Dick Hardt
Would you elaborate on your reasons here? Do you think we have enumerated all the possibilities? On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: > I would rather limit the ability to extend the two endpoints beyond their > current architecture, and instead, allow others to specify new end

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
The interop value of the current proposal is simple: - defines how multiple scopes are to be expressed (order doesn't matter, space delimited) - provides an easy way to express the required scope when rejected a protected resource request - allows clients the ability to combine scopes (known and

Re: [OAUTH-WG] proposal for signatures

2010-06-25 Thread Breno
On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard wrote: >> What's the purpose of leaving out the key ID? > It's one more field that developers have to learn and configure and type in. > We should keep the simple case simple, while allowing for more complex > cases. I think the fact that many provide

Re: [OAUTH-WG] Extensibility for OAuth?

2010-06-25 Thread Eran Hammer-Lahav
> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, June 22, 2010 11:08 PM > To: OAuth WG > Subject: [OAUTH-WG] Extensibility for OAuth? > > Hi Eran, > Hi all, > > I briefly browsed throu

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Luke Shepard
Agree. Dick- just to clarify, you mean a restriction that they be space-delimited opaque strings as defined in the latest draft? Or something different? On Jun 25, 2010, at 8:54 AM, Dick Hardt wrote: > Glad to see people agreeing with me. I don't think Hannes was disagreeing > with me though.

Re: [OAUTH-WG] proposal for signatures

2010-06-25 Thread Luke Shepard
> What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in. We should keep the simple case simple, while allowing for more complex cases. I think the fact that many providers now offer only a single, shared secret is an indication

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

2010-06-25 Thread Luke Shepard
Brian, Dirk - just wondering if you had thoughts here? The only strong reason I can think of for base64 encoding is that it allows for a delimiter between the body and the signature. Is there any other reason? On Jun 24, 2010, at 11:33 AM, Naitik Shah wrote: > I've been following some of the d

Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates)

2010-06-25 Thread Eran Hammer-Lahav
I have completed all my action items. I have not seen any responses to this list (in two weeks) and will be closing these issues on my end (editor's queue). If you still want to discuss this, please bring it up again. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Dick Hardt
Glad to see people agreeing with me. I don't think Hannes was disagreeing with me though. :) Per my response to Hannes, I think there is value in a small restriction on scope strings so that we have a reserved format for the future. -- Dick On 2010-06-25, at 7:52 AM, Blaine Cook wrote: > I ag

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Dick Hardt
To clarify, the goal is to reserve a namespace for future use so that near term implementations won't collide? I expect the standardization of scope values to not be in OAuth, but in standardized APIs that use OAuth, so a namespace mechanism that differentiates between a standardized scope and

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Blaine Cook
I agree with Dick that the scope should remain out of scope for OAuth. ;-) Having a shared parameter here gives the illusion of interoperability, but because there's no common understanding of permissible scopes, there's no way to guarantee that any given client-server pair could expect to produce

Re: [OAUTH-WG] proposal for signatures

2010-06-25 Thread Breno
Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, "Ben Laurie" wrote: On 22 June 2010 21:45, David Recordon wrote: > Hey Dick, in answering my quest... I

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Justin Richer
I don't agree: these values are still opaque to OAuth. They're not opaque to the client and server, they're part of the API. But the client -- and by "client" here I mean the whole client application, not just the OAuth client -- needs to know what they're for. In the same fashion, the client needs

Re: [OAUTH-WG] client secret used in Native App profile

2010-06-25 Thread Bouiaw
If we consider HTML5 browser, I am not sure there is a clear separation betweeen native apps and user agent clients. What is the technical difference between a native app and a browser that support HTML 5 localStorage ? On Fri, Jun 25, 2010 at 9:22 AM, Marius Scurtescu wrote: > I think the main d

Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

2010-06-25 Thread Tschofenig, Hannes (NSN - FI/Espoo)
Dick pointed me to the Facebook API on how scope is used. The main page is here: http://developers.facebook.com/docs/authentication/ It describes the basic functionality and also lists an example: " https://graph.facebook.com/oauth/authorize? client_id=...& redirect_uri=http://www.exam

[OAUTH-WG] 78th IETF DRAFT Agenda

2010-06-25 Thread Tschofenig, Hannes (NSN - FI/Espoo)
Hi all, An early version of the agenda is available and indicates that the Oauth WG session is scheduled for Tuesday, July 27, 2010. The agenda is still subject to change. The final agenda will be published on July 2, 2010. Ciao Hannes ___ OAuth m

Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication

2010-06-25 Thread Colin Snover
On 24/06/2010 23:30, Luke Shepard wrote: You're right; this can be an interesting issue. It's very tied up in identity - if you are talking about connecting accounts (like you would with Facebook) then there's a layer missing from OAuth that provides the identity on top of it. At the moment, t

Re: [OAUTH-WG] client secret used in Native App profile

2010-06-25 Thread Marius Scurtescu
I think the main difference is that User-Agent clients (aka JavaScript clients) cannot store a secret while Native Apps can safely store a secret, but the secret cannot be distributed (or, even if it can be distributed, it may not have much value). The difference is important. Each native app inst