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 differen
+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 cas
Yahoo¹s security team has concerns regarding the immediate mode and shared
computers.
Consider the case where a browser based JS app is running in a browser tab
with credentials belonging to a particular user. While the app is still
running, the original user lets a friend borrow the browser. The
On Tue, May 25, 2010 at 1:40 AM, Pid 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 form-encoded is still use
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, exc
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 how
On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt
wrote:
>>
>> On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
>> 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
>>>
On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
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.
Consequences?
In the setup ill
On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
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.
> Consequences?
> In the setup
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.
At Deutsche Telekom we provide a vari
On Sun, May 23, 2010 at 7:13 PM, Luke Shepard 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 the server, and
On Mon, May 24, 2010 at 10:04 PM, Manger, James H
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 which it is
> issuing
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 ou
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 t
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
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 "t
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 al
17 matches
Mail list logo
