3.4. Client Credentials
When requesting access from the authorization server, the client
identifies itself using its authorization-server-issued client
credentials.
The Client Credentials does not necessarily be issued by the
authorization server,
but may be issued by the server that au
In the assertion flow the authorization server issues an access token. In
other flows, the access token is accompanied by an expires_in parameter, but
not in this one according to the latest draft of the spec.
Was this intentional?
--
Andrew Arnott
"I [may] not agree with what you have to say, but
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 ;-)
My point is that pulling in *any* third party code is always a bigger
barrier to adoption to
Using SWT for your access tokens seems like a reasonable way to resolve this
for servers which care.
On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu wrote:
> Returning a scope parameter with issued tokens is not a bad idea.
>
> But this, and also the sites parameter suggested by James, can bot
Returning a scope parameter with issued tokens is not a bad idea.
But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.
The Simple Web Token spec goes alo
On Thu, May 6, 2010 at 6:36 PM, Manger, James H
wrote:
> Marius
>
>> Isn't this taken care of by the scope?
>
> I don't think so. It looks similar to Google scopes
> (http://code.google.com/apis/gdata/faq.html#AuthScopes), but nothing like
> Facebook scopes
> (http://developers.facebook.com/doc
On Fri, May 7, 2010 at 11:28 AM, Eran Hammer-Lahav wrote:
>
> Again, for the server, this is just a single printf() statement per format:
>
> printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires);
> printf("%s%d",
> token, expires);
>
> For the client, if they don't like the defau
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Moore
Sent: Friday, May 07, 2010 8:06 AM
To: OAuth WG
Subject: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal
I propose alter the spec so that the token responses are encoded with
application/x-www-f
Every format we add increases the probability of failing to interoperate.
I believe as a working group we need to specify exactly one format and only one
format. That doesn't preclude later extensions that support more formats but if
our goal is interoperability then the fewer options the more
On 07/05/2010 16:28, Eran Hammer-Lahav wrote:
> This approach seems the most reasonable to me.
>
> Server MUST support all three formats.
> Client MUST support one but MAY support more formats.
>
> This puts a little extra work on the server but since this is on the
> serializing side, no parser
This approach seems the most reasonable to me.
Server MUST support all three formats.
Client MUST support one but MAY support more formats.
This puts a little extra work on the server but since this is on the
serializing side, no parser is needed. On the client side it adds no additional
comple
+2¢ :D
There are hundreds of formats for a flat key->value "map", expecially when
you already know the native type of the value given the key. Http headers
are a format, HTTP form encoding is a well known and supported format and
already required by OAuth in other places.
JSON is nice, but to inv
Well, if the response is guaranteed to be a flat list of name-value
pairs, then JSON seems like overkill.
-Original Message-
From: Mike Moore
To: Paul C. Bryan
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)
Date: Fri, 7 May 2010 09:04:30 -0600
On Fri, May 7
I propose alter the spec so that the token responses are encoded with
application/x-www-form-urlencoded, matching OAuth 1.0. I also propose moving
the JSON and XML support for these responses to an extension.
I haven't heard an argument that convinces me that JSON adds anything over
application/x-
Here's my 2¢ worth...
Criteria: If the structure of encoded data is guaranteed to be a flat
list of name-value pairs, x-www-form-urlencoded seems sufficient. If the
structure could be (arbitrarily) complex (e.g. nesting lists or
associative arrays), then definitely use JSON.
Why JSON instead of,
On 06/05/2010 18:29, Torsten Lodderstedt wrote:
> +1 , we've got really strong support for JSON and I'm also looking
> forward to review Erans proposal.
Sorry but I am going to continue being Devil's Advocate and keep asking
why JSON is better. Just saying "we all want it" isn't a positive
argume
Am 07.05.2010 08:14, schrieb Manger, James H:
> what about an additional realm response value?
My original
suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html)
had a “realm” in addition to “sites”. I still think that should be
present (though more to match the HTTP au
17 matches
Mail list logo
