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
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
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
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
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
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
+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
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
> -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
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
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
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
+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
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
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
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
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
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
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
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
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...
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
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)
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 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
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
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
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
> -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
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.
> 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
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
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
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
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
