Still working on security considerations. I'm comparing these two
profiles based on passwords:
http://tools.ietf.org/html/draft-hardt-oauth-01#section-5.1
- this is probably used by automated tasks.
- the password can be assumed to be high-entropy, since no one
needs to remember it.
- wh
This must be an editing error.
Version 0.9.7.2 of the spec requires exactly the other way around, the
correct way: Client Account and Password (5.1) does not return a
refresh token, and Username and Password (5.3) requires a refresh
token to be returned.
Marius
On Tue, Mar 30, 2010 at 2:34 PM,
+1
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Marius Scurtescu
Sent: Tuesday, March 30, 2010 12:07 PM
To: Brian Eaton
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] two username/password profiles
This must be an editing error.
Version 0.9.7.
my bad, Marius is correct
On 2010-03-30, at 12:07 PM, Marius Scurtescu wrote:
> This must be an editing error.
>
> Version 0.9.7.2 of the spec requires exactly the other way around, the
> correct way: Client Account and Password (5.1) does not return a
> refresh token, and Username and Password
One of the challenges we're running into from an implementation standpoint is
having the ability for a Client developer to tell the Authorization Server if
they're looking for a popup, full page redirect, mobile experience, or no user
interface for the times when a user is being sent through an
I think it makes sense, but can this be an extension as opposed to be
added to core?
A related parameter IMO (could be part of the same extension) would be
l10n, in what language should the Authorization Server interact with
the user. OpenID I think has a similar extension.
Marius
On Tue, Mar 3
This seems rather application-specific. What semantics do these
things take on when HTTP is just being used as a transport, e.g., for
a virtual world system (see VWRAP)?
Also, maybe I'm misunderstanding things here, but since it's the
Client that send the browser to the authorization page,
On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes wrote:
> This seems rather application-specific. What semantics do these things take
> on when HTTP is just being used as a transport, e.g., for a virtual world
> system (see VWRAP)?
>
> Also, maybe I'm misunderstanding things here, but since it's t
i like having an optional hint / parameter which would hint to the server
which type of response the client wants back. whether or not this needs to
be "core" or an "extension", however, is a valid question.
twitter is actually facing the same issue that david mentions, and have
implemented somet
Sounds like something best outlined in a best-practices doc or extension -
there are going to be a lot of different implementation specific things here
I think.
We're not doing it right now, but Photobucket will be doing some light user
agent detection, with a hint option, for this sort of interac
On 3/30/10 4:16 PM, David Recordon wrote:
> On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes wrote:
>> This seems rather application-specific. What semantics do these things take
>> on when HTTP is just being used as a transport, e.g., for a virtual world
>> system (see VWRAP)?
>>
>> Also, maybe I
I guess I'm one of those IETF folks that likes to separate content
from presentation :)
In any case, it seems like there's some agreement here that display
parameters are something that should be optional / extension. That's
fine with me.
It sounds, though, like maybe what you want is a
This should be implemented using a parameter with some level of
discovery to find out the options supported by the server.
As for where this belongs (extension, etc), I say write it and we'll
figure it out later. It will be part of core more based on the
libraries and companies that adopt i
why does a client need to discover what the server supports? presumably the
client would already know given that they are integrating with it? it could
simply be documented somewhere (just looking for a way for this not to
snowball into something complicated).
On Tue, Mar 30, 2010 at 5:22 PM, Er
On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian wrote:
> why does a client need to discover what the server supports? presumably the
> client would already know given that they are integrating with it?
+1.
___
OAuth mailing list
OAuth@ietf.org
https://
So I doubt that the client always knows what the server supports, the server
should be open in allowing all parties to find out what is supported
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Tuesday, March 30, 2010 5:44 PM
Aren't these independent issues?
Regardless how the client figures what the server supports (discovery
or hard code configuration) it must have a way to tell the
Authorization Server its preferences when it sends the user over.
Marius
On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin wrote:
>
Because the server can deploy support for new devices after the client is
released and deployed. Wouldn't it be better if the client didn't need a new
release to take advantage of something as trivial as asking the server for a
better interface?
EHL
On 3/30/10 5:25 PM, "Raffi Krikorian" wrot
They are, but thinking about interop for both parts is the same work. Once you
figure out what the client might need, you figure out what the server may
support. At that point discovery is as simple as giving these different options
names and putting this information somewhere.
I am not saying
Since we have consensus that using signed requests is a more advance use
case and will be used by more experienced developer, I would like to suggest
we limit sending signed request parameters to the Authorization header (no
URI query parameters or form-encoded body).
This will not change the abil
On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav wrote:
> The makes client request parameter much simpler as the only parameter
> "invading" the URI or body space of the request is oauth_token. Anything
> else is limited to the header.
Why would oauth_token ever hit the URI or body in a signed
Sounds reasonable. If you're computing signatures then you certainly
can set an authorization header.
On Tue, Mar 30, 2010 at 9:25 PM, Brian Eaton wrote:
> On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav
> wrote:
>> The makes client request parameter much simpler as the only parameter
>> "i
On 3/30/10 9:25 PM, "Brian Eaton" wrote:
> On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav
> wrote:
>> The makes client request parameter much simpler as the only parameter
>> "invading" the URI or body space of the request is oauth_token. Anything
>> else is limited to the header.
>
> Wh
+1
-Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
Date: Tue, 30 Mar 2010 21:20:40 -0700
Since we have consensus that using signed requests is a more advance use
case and will be used by more ex
+1
generally, why do we need other ways than headers for sending the
authorization data? HTTP basic/digest authentication only use headers
+1
-Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
D
25 matches
Mail list logo
