On 25/05/2010 01:52, Dick Hardt wrote:
On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote:
And to add to this, this example shows that encoding is hard, JSON
only solves decoding (in most cases, but not all).
JSON solves encoding and decoding with the same library.
For all direct
It seems like this would make what I see as the more common case -- getting a
single access token from a flow -- more complicated. Everybody pays the
overhead in order to support one limited use case, which is what brought about
the request token in oauth1. I don't want to always have to grab
Justin,
I don't want to always have to grab token[0] from the response where before
i just grabbed token.
Surely token[0] vs token is too trivial to be an issue.
Also, this approach ties us to a hierarchical data representation format like
JSON instead of being able to use anything that
Few responses on this topic:
On May 25, 2010, at 7:08 AM, Manger, James H wrote:
Justin,
I don't want to always have to grab token[0] from the response where
before i just grabbed token.
Surely token[0] vs token is too trivial to be an issue.
It's a pretty reasonable issue to raise.
The message flows within OAuth 2.0 are virtually identical to the Kerberos
protocol (RFC4120 and RFC1510). There is also significant overlap in
functionality (e.g. OAuth token matches the Kerberos ticket, the Refresh Token
matches the TGT, etc).
Since there is a huge install-base of Kerberos
On Mon, May 24, 2010 at 10:04 PM, Manger, James H
james.h.man...@team.telstra.com wrote:
How does the authz
server know how to partition the scopes to the multiple tokens? One
scope per token? What if an API requires multiple scopes?
An AS will generally know a fair bit about the services for
On Sun, May 23, 2010 at 7:13 PM, Luke Shepard lshep...@facebook.com wrote:
Brian - I like your proposal. It solves the refresh token problem and the
server-side auth in one go.
Marius - your proposal would work great in a circumstance where you have
strong integration between JavaScript and
Thank you all for your feedback on my posting. I will answer in a single
response.
To start with I want to clarfiy where I come from and what way my
thoughts went along. This will hopefully help to understand the
limitation of OAuth2 I want to address.
why different tokens?
At Deutsche
On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
As proposed by Marius, the authorization server could issue a refresh token
and the client could use the refresh request in combination with the
downscoping feature in order to acquire access tokens.
On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
As proposed by Marius, the authorization server could issue a refresh token
and the client could use the refresh request in combination with the
downscoping feature in order to acquire access tokens.
On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
As proposed by Marius, the authorization server could issue a refresh
token
and the client could use the refresh request
Once again, I want to plea the case for keeping the response simple key/value
string pairs so it is trivial to serialize to multiple formats. The OAuth
endpoint should be able to match the format(s) of the API it protects.
Given this simple response payload, the spec can generically describe
Anyway to find out what the outcome was from the May 20th interim meeting? I
wanted to participate but had to be at Google I/O.
3.5. User-Agent Flow
1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine,
On Tue, May 25, 2010 at 1:40 AM, Pid p...@pidster.com wrote:
The best summary of the arguments in favour of JSON was by Joseph Smarr
in response to my previous inquiry, which hasn't been superseded, I think.
Yes, Joseph made a very good argument for JSON.
My only objection is that
+1
I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.
That being said, I think that bearer token/refresh token model can satisify
the majority of use
Yes one of the design goals for Oauth-WRAP was to eliminate the request
token.
It is very tricky for SPs to implement the Request Token due to data
replication issues. The Request token could be issued to the client in one
data center, and then immediately submitted by the browser to a
16 matches
Mail list logo
