We mustn't drop advertisements (details in 401 responses).
We mustn't drop the goal of a standard for interoperability.
I don't think we have to, just because of difficulties over the 'scope'
parameter.
How about if the spec explicitly says:
"There can be any number of authorization endpoints
Thanks!
On Thu, Apr 22, 2010 at 4:49 PM, Brian Eaton wrote:
>
> So I’d propose changing the profile as follows:
>
> - Client requests device code by sending type=device and client_id=
>
I might be reading something different than you are, but according to
http://tools.ietf.org/html/draft-hammer
A couple of comments on this profile.
1) Error URL
I noticed that there was wide consensus that returning a
captcha-specific error was not going to be useful. That matches our
experience with ClientLogin [1] - very few developers properly handle
captcha. And if a developer is sophisticated enou
Just went through the draft - it is coming along nicely. Thanks!
This is all comments on language. I have a few more substantive
comments that I will send separately.
“or to limit access to the methods supported by these resources.”
This didn’t parse for me.
“The use of OAuth with any other t
I'm going through the April 21 draft and making notes... Most of them
are of the "what color should the bike shed be" variety, but I think
the device profile needs real changes.
The verification URI has to be short and memorable, because users have
to type it.
Different devices are probably goin
I'm getting whiplash. :) Some of us are working on UMA implementations based
on the ever-changing OAuth substrate, and just discussed being glad we could
reuse OAuth's advertisement of these two endpoints rather than inventing our
own mechanism. If it goes, I guess we'll have to go back to defi
My proposal is just that, a proposal. And it is an attemp to get
closer to how most companies plan to use it. We have no consensus on
defining a prameter name without defining a value.
Got new ideas?
EHL
On Apr 22, 2010, at 13:50, "Brian Eaton" wrote:
> On Thu, Apr 22, 2010 at 12:41 PM, Er
On Thu, Apr 22, 2010 at 12:41 PM, Eran Hammer-Lahav wrote:
> Drop the 'scope' parameter as well and we're on the same page.
So we have a choice between
a) not documenting something that a bunch of providers have already
implemented and found useful
or
b) documenting something that no one has
On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav wrote:
> This suggests we need to rethink our goal of interop and replace it with
> library re-use.
>
> To me interop means that a client can interact with an unknown server by
> simply speaking the protocol (the way an email can be delivered to
Drop the 'scope' parameter as well and we're on the same page.
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Thursday, April 22, 2010 12:36 PM
> To: Eran Hammer-Lahav
> Cc: John Kemp; OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
> On T
On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav wrote:
> If we are not going to enable a client to access a protected resource hosted
> by an unfamiliar
> server, we need to stop pretending this (alone) is about interop. In other
> words, if we take
> this approach we are mandating paperwork
On Apr 22, 2010, at 2:21 PM, Brian Eaton wrote:
> On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav
> wrote:
>> Rules around realms show this is very tricky but unless we update 2617
>> (which we
>> are not chartered to do) we are still stuck with realm as a required
>> parameter.
>> One way
This suggests we need to rethink our goal of interop and replace it with
library re-use.
To me interop means that a client can interact with an unknown server by simply
speaking the protocol (the way an email can be delivered to any server).
Library re-use means that we define a set of configur
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Thursday, April 22, 2010 11:48 AM
> On Thu, Apr 22, 2010 at 11:39 AM, John Kemp wrote:
> > I agree that 'scope' is something that many SPs want. If they don't
> > want it roughly the same way though (something
On Thu, Apr 22, 2010 at 11:39 AM, John Kemp wrote:
> I agree that 'scope' is something that many SPs want. If they don't want it
> roughly the
> same way though (something more than a "bucket of opaque strings with a
> standard
> name") I don't know if I understand the point to standardizing it.
Hi Brian,
On Apr 22, 2010, at 1:36 PM, Brian Eaton wrote:
> On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav
> wrote:
>>> The scope doesn't have to match the base URI of the resource which the
>>> client tried and got the 401 from?
>>
>> That's a security issue we need to address (when to tr
On Thu, Apr 22, 2010 at 11:30 AM, Eran Hammer-Lahav wrote:
> What makes this so much different from Basic? Instead of using a flow the
> browser
> simply asks the user for a set of credentials. Once it has a set, it reuses
> it based on realm.
Those rules aren't practical or correct for most AP
What makes this so much different from Basic? Instead of using a flow the
browser simply asks the user for a set of credentials. Once it has a set, it
reuses it based on realm.
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Thursday, April 22, 2010 11:22
On Thu, Apr 22, 2010 at 11:01 AM, Eran Hammer-Lahav wrote:
> Rules around realms show this is very tricky but unless we update 2617 (which
> we
> are not chartered to do) we are still stuck with realm as a required
> parameter.
> One way to avoid this debate is to simply say that clients should
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Thursday, April 22, 2010 10:36 AM
> To: Eran Hammer-Lahav
> Cc: John Kemp; OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
> On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav
> wrote:
> >> The s
On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav wrote:
>> The scope doesn't have to match the base URI of the resource which the
>> client tried and got the 401 from?
>
> That's a security issue we need to address (when to trust the resource server
> and reuse an existing token). We need to fi
Dear experts.
I read the two specifications(community/ietf hammer draft), and confused to
interprete those specs about regulation of signing additional parameters.
- Community (http://oauth.net/core/1.0)
--
"5.2 Consumer Request Parameters"
In addition to these defined
On 21/04/2010 19:18, Paul Lindner wrote:
> Ditto here. Apache Shindig uses OAuth extensively and we would like to
> upgrade it to OAuth 2.0. The current stable java oauth library is okay,
> but does not have an active developer community, and isn't even
> published to maven central.
Both of thos
23 matches
Mail list logo
