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
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
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=...
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 mscurte...@google.com
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
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
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
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
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
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
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.
-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 through the -08
On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard lshep...@facebook.com 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
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
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
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.
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)
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 like
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
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 with
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,
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
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
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
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
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
+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 25, 2010
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard lshep...@facebook.com 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?
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
-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 know exactly
On Fri, Jun 25, 2010 at 11:39 AM, Breno breno.demedei...@gmail.com wrote:
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard lshep...@facebook.com
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
+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
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
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
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
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 text
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 .
37 matches
Mail list logo
