On 4/8/10 9:17 PM, "Evan Gilbert" wrote:
>
>
> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav
> wrote:
>>
>>
>>
>> On 4/7/10 9:20 PM, "Evan Gilbert" wrote:
>>
>>> Authorization servers in the OAuth Web Callback flow and the User Agent flow
>>> should have the option to redirect bac
I finally found some time to put together a suggestion for the Assertion Flow.
I separated this into a core Assertion Flow used as a basis for consistent
profiling, and a SAML specific profile. The SAML Profile is designed to allow
the authorization server to accept SAML assertions with the
>
>
>
> >> 2. Section 2.1: "The authorization endpoint advertised by the server
> >> MUST NOT include a query or fragment components as defined by
> >> [RFC3986] section 3." Why do we disallow query parameters? If we want
> >> to enforce strict matching of callback URLs maybe we should just
> >> de
On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher wrote:
> I realize that these sorts of use cases are trivial if establishment of the
> SSO session switches from a signed mechanism to the OAuth WRAP bearer token
> model. The one nice feature of the signed URL is that it is one time use
> where the
On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/7/10 9:20 PM, "Evan Gilbert" wrote:
>
> > Authorization servers in the OAuth Web Callback flow and the User Agent
> flow
> > should have the option to redirect back with access/refresh tokens
> without
> > prompting the user,
On 4/8/10 1:10 PM, "Torsten Lodderstedt" wrote:
> Am 08.04.2010 16:31, schrieb Eran Hammer-Lahav:
>> While I agree that the spec would be much cleaner with only HTTP header
>> support, and have tried that approach before, in practice it will cause
>> significant adoption problems.
>>
>
> C
On 4/8/10 4:25 PM, "Marius Scurtescu" wrote:
> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav wrote:
>> This seems reasonable, but it does add more complexity for the client.
>
> True, but not that much. Just an extra request parameter if it wants a
> refresh token. Default could be "no".
On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav wrote:
> This seems reasonable, but it does add more complexity for the client.
True, but not that much. Just an extra request parameter if it wants a
refresh token. Default could be "no".
> The
> thing is, there is no point in a refresh token i
Hi Igor,
Without getting into any specific details, most large websites will check
your browser cookies, along with other factors (including your IP address,
simultaneous sessions from other IP addresses, recent changes to your
account, the time you last verified your password, etc) to determine i
This seems reasonable, but it does add more complexity for the client. The
thing is, there is no point in a refresh token if the token lifetime is the
same as the access grant. Should the server ignore the client's request in such
cases?
EHL
On 4/8/10 11:03 AM, "Marius Scurtescu" wrote:
On
Allen,
(I am a happy user of Yahoo mail via Verizon.) In some cases, especially
if I had not used e-mail for a while, Yahoo prompts me to enter the
password. Now, I think this is a very good feature, which would protect
me if my computer is stolen. The question: how is this interworking with
Certainly it should be recommended that bearer tokens have limited
scope, but because the notion of "limited scope" isn't well-defined,
you can't really say that "bearer tokens MUST have limited scope".
When it comes to the *normative* text (i.e., the stuff in capital
letters), we need to
Yahoo has exactly the same use case.
The user is authenticated into the Yahoo Instant Messenger client
application, and clicks on the Yahoo Mail button to check Yahoo Mail.
Clicking the Mail button spawns a browser window with an authentication
token that is passed to the browser on the URL. The
Torsten,
I really like this use case. I think it ought to be documented on its own.
(But please let me know if you disagree and thing that it is a subset of
another use case.)
I also see potential synergy with the recursive delegation case.
For my use-cases draft, I am trying to develop a co
On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote:
> The scope argument doesn't really hold any water, since OAuth isn't defining
> the scope that tokens have -- authorization servers could issue tokens that
> have the same power as passwords. Not all implementors are "reasonable" :)
Indeed, yo
That looks fine to me.
On Apr 8, 2010, at 2:06 AM, Eran Hammer-Lahav wrote:
How about something like this:
When accessing resources using the http URI scheme, clients SHOULD
NOT use and servers SHOULD NOT accept bearer token requests
(unsigned requests) as such a request is equal to sendi
The scope argument doesn't really hold any water, since OAuth isn't
defining the scope that tokens have -- authorization servers could
issue tokens that have the same power as passwords. Not all
implementors are "reasonable" :)
--Richard
On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:
Usi
Am 08.04.2010 16:31, schrieb Eran Hammer-Lahav:
While I agree that the spec would be much cleaner with only HTTP header
support, and have tried that approach before, in practice it will cause
significant adoption problems.
Can you please give details on that? You removed query and post
par
On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:
> Using a bearer token without a signature over HTTP is not equivalent to HTTP
> Basic Auth in the clear.
+1
>
> A bearer token is far less powerful than the user’s password.
s/is/should be/ and I agree ;)
> In most cases, a MITM who steals the
Yes, I don't see a problem with returning the refresh token with every
access token response as long as its optional.
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is alrea
On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
Can you share an example of a native application launching an external
browser with a protect resource?
Native application = AIM
Protected Resource = User's AIM Mail box
AIM has supported this for a while.
Why can't the end user just login to the b
Using a bearer token without a signature over HTTP is not equivalent to HTTP
Basic Auth in the clear.
A bearer token is far less powerful than the user¹s password. In most
cases, a MITM who steals the user¹s password would be able to change the
user¹s password, locking the user out his account. P
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is already optional everywhere it is
> included. What I suggested is to allow it to be optional everywhere.
>
> If the server d
Agreed with Eran. GET parameters certainly make exploring APIs easier.
On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav wrote:
> While I agree that the spec would be much cleaner with only HTTP header
> support, and have tried that approach before, in practice it will cause
> significant adoptio
+1, I support servers being allowed to optionally include refresh
tokens with every access token.
On Wed, Apr 7, 2010 at 11:13 PM, Eran Hammer-Lahav wrote:
> My point is simple. *Server* should be allowed to include a refresh token
> with every access token issued. It is already optional everywh
On Wed, Apr 7, 2010 at 11:21 PM, Eran Hammer-Lahav wrote:
> I will leave this to the security folks to decide but it seems to me that
> if
> the client asks to limit the username of the end user granting access by
> specifying it in the request, the server must repeat that information when
> issui
On Wed, Apr 7, 2010 at 11:40 PM, John Panzer wrote:
>
>
> On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert wrote:
>
>>
>>
>>
>> On Wed, Apr 7, 2010 at 9:29 AM, John Panzer wrote:
>>
>>> I'm assuming that tokens need not be bound to a specific user (typically
>>> they are, but imagine a secretary g
Can you share an example of a native application launching an external browser
with a protect resource?
Why can't the end user just login to the browser using normal web login and
access the resource?
EHL
On 4/8/10 7:51 AM, "Anthony Nadalin" wrote:
> Why is the native application launching
> Why is the native application launching a browser with a protected resource
> request? That seems odd.
Not odd at all a lot of the Eclipse applications can work this way
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, April 08, 2010
Why is the native application launching a browser with a protected resource
request? That seems odd.
Note that we currently have no plans of supporting signatures in any of the
flows. We are discussing signatures only for using tokens with secrets when
accessing protected resources.
EHL
On 4
There is a difference between having no semantic meaning (i.e. Not a
representation of a resource, etc.) to being ignored. I agree it is odd. I'll
take a look when it is in AUTH48.
EHL
On 4/8/10 7:03 AM, "Greg Beech" wrote:
Apologies, I had not realised that this was intended to be a form-en
While I agree that the spec would be much cleaner with only HTTP header
support, and have tried that approach before, in practice it will cause
significant adoption problems.
I rather add support for query and post parameters (we are really talking
about a single parameter, oauth_token, outside th
Another use case is where a rich client wants to bootstrap a web session
with the same identity (rich client to web SSO). Assuming that the web
session will be established via OAuth with signatures, there is no way
to fire up the browser with a "signed URL" if the OAuth parameters and
signature
Apologies, I had not realised that this was intended to be a form-encoded body,
and thought it was a typo. However, according to RFC 2616 the body of a GET
request has no semantic meaning and should be ignored by an origin server
(summarised well in the following quotation from Roy Fielding):
Hi Eran,
since you are re-working sections 5-7 now, I want to address some
general issues I see there.
- What is the benefit of including "URI Query Parameter" and
"Form-Encoded Body Parameter" in the standard? I see OAuth as an HTTP
authentication scheme similar to BASIC or SPNEGO. All
On 4/7/10 9:20 PM, "Evan Gilbert" wrote:
> Authorization servers in the OAuth Web Callback flow and the User Agent flow
> should have the option to redirect back with access/refresh tokens without
> prompting the user, if the client has already been granted access to the
> protected resource.
36 matches
Mail list logo
