On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/6/10 5:24 PM, "Evan Gilbert" wrote:
>
> > Proposal:
> > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> > username
> > The resource owner's username. The authorization server MUST only send
> back
> > refresh tokens
On 4/6/10 5:24 PM, "Evan Gilbert" wrote:
> Proposal:
> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
> username
> The resource owner's username. The authorization server MUST only send back
> refresh tokens or access tokens for the user identified by username.
What are the security
On Tue, Apr 6, 2010 at 8:24 AM, Luke Shepard wrote:
> Just curious, where did "duration" come from?
> I hate to be picky, but I feel like "expires_in" is more clear than
> "duration" ... if only because other protocols (OAuth 1.0a, OpenID, Facebook
> auth) use "expires".
"duration" is pretty vagu
On Tue, Apr 6, 2010 at 11:15 AM, David Recordon wrote:
> There is potential for leakage if the client then redirects the user to
> another SSL URL. This doesn't feel like a common pattern and the client
> would generally be redirecting to a page which they control after receiving
> the access toke
I've been reading this with much interest, but I am getting hopelessly
lost because of the usage of the word API. Somehow, to me -- for many
years--it meant the format of procedure calls, or, more general,
procedure signatures in standard libraries.
I remember David at the last meeting clarif
Yes, if we go with RFC 2617, then--and please correct me if I am
wrong--it looks to me that *realm* here means pretty much the same thing
as *Kerberos realm*. I strongly agree on getting the definition clear,
and I agree that nothing should be "opaque."
(I as puzzled by the quoted exchange, an
On Tue, Apr 6, 2010 at 2:44 PM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/6/10 7:04 AM, "Evan Gilbert" wrote:
>
> >
> >
> > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav
> > wrote:
> >> Hi Evan,
> >>
> >> On 4/5/10 4:28 PM, "Evan Gilbert" wrote:
> >>
> >>> 2.4.1 Web Callback Flow & 2.4.2 Web C
Hi Tony,
I¹m suggesting that the Service Provider determine whether its services are
available via HTTPS, HTTP, or both.
This is exactly how it is today. AFAIK, there are no standard interoperable
APIs that use Oauth. All (or practically all) APIs that use Oauth are
completely proprietary. For pr
On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt
wrote:
> Hi all,
>
> here at Deutsche Telekom, we see the need for a flow supporting the exchange
> of access tokens for one service into access tokens for another service.
>
> The scenarios is as follows: In the context of mobile applications,
On Tue, Apr 6, 2010 at 3:12 PM, Eran Hammer-Lahav wrote:
> I am still waiting for someone to show how a scope parameter with an opaque
> value helps interop, where every single example requires the client to know
> how to construct this opaque string. OAuth libraries will need to support
> extensi
Thanks John.
I tend to agree that realm comes with a lot of baggage and is probably not
going to work given people's expectations. After all, they are not likely to
study 2617 before implementing OAuth.
The point of my proposal was to show one aspect of scope in which the client is
being told
I am still waiting for someone to show how a scope parameter with an opaque
value helps interop, where every single example requires the client to know how
to construct this opaque string. OAuth libraries will need to support extension
parameters - that's a given. So how is this not an extension
On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav wrote:
> The question is how your APIs are structure. Do you have APIs that require
> multiple “scopes” in a single call?
Things can get even more complicated. When the user grants access for
the client, the approval page should list all the scope
That's only when you need to trust the client. If your requirements demand
registration, discovery is mostly pointless (other than dynamic configuration).
EHL
On 4/6/10 6:58 AM, "Brian Eaton" wrote:
Web clients are expected to have secrets or to have otherwise
registered with the AS. In orde
"The duration in seconds of the access token lifetime."
I liked 'lifetime' better than 'expires_in' (for no particular reason), but
lifetime can mean number of uses.
EHL
On 4/6/10 8:24 AM, "Luke Shepard" wrote:
Just curious, where did "duration" come from?
I hate to be picky, but I feel lik
On 4/6/10 7:04 AM, "Evan Gilbert" wrote:
>
>
> On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav
> wrote:
>> Hi Evan,
>>
>> On 4/5/10 4:28 PM, "Evan Gilbert" wrote:
>>
>>> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
>>> We should have an OPTIONAL username parameter:
>>> username
>>>
The question is how your APIs are structure. Do you have APIs that require
multiple "scopes" in a single call?
EHL
On 4/6/10 8:29 AM, "Luke Shepard" wrote:
For Facebook at least, we are currently planning to use scope as a
comma-separated list of permissions from this set:
http://wiki.devel
RFC 2617 defines what a realm is - a set of resources sharing the same set
of credentials. It saves the client the need to prompt the user again for
their credentials when browsing a site across resources. Because sending
credentials to the wrong place is dangerous, realms are hard to use because
t
Like anything else, we need proposed text to discuss. Discussing a list of
attributes is rarely practical. Discussing a concrete proposal usually works...
EHL
On 4/6/10 3:23 AM, "Torsten Lodderstedt" wrote:
Hi Eran,
> I agree that this is the right approach (separate parameters to well defin
IETF standards can do one of two things: they can set a high level of
security or they can clearly point out where they are insecure. If we do not
require HTTPS for bearer tokens, we will have to put a big disclaimer that
doing so without some other protections is insecure.
The choice is between s
On Tue, Apr 6, 2010 at 12:39 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Blaine,
>
> My take on this is that MUSTs MAY be ignored. ;-)
>>
>> To echo John's concerns here, the worst-case scenario is that client
>> libraries implement "no SSL present" as a gentle reminder warning
++
Igor
Torsten Lodderstedt wrote:
Hi Blaine,
My take on this is that MUSTs MAY be ignored. ;-)
To echo John's concerns here, the worst-case scenario is that client
libraries implement "no SSL present" as a gentle reminder warning with
a flag (possibly the default) to disable those HTTPS warn
I'm not sure if you are coming from the user or service perspective. So if a
user asks for HTTPS do you have to support HTTPS? If a service asks for HTTPS
do you have to support it? Or do you just fail?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Allen
Tom
Sent: T
Hi Blaine,
My take on this is that MUSTs MAY be ignored. ;-)
To echo John's concerns here, the worst-case scenario is that client
libraries implement "no SSL present" as a gentle reminder warning with
a flag (possibly the default) to disable those HTTPS warnings. Clients
I don't understand y
My take on this is that MUSTs MAY be ignored. ;-)
To echo John's concerns here, the worst-case scenario is that client
libraries implement "no SSL present" as a gentle reminder warning with
a flag (possibly the default) to disable those HTTPS warnings. Clients
that behave in that way should be fla
My $.02: SHOULD is okay, as long as all clients MUST support HTTPS. E.g.,
SHOULD for service providers, MUST support for clients.
Otherwise, you will end up with clients that don't support https or don't do
it properly. (E.g., don't bother to check certificates.) Which hurts
security for servi
even though i was one who advocated for HTTPS for these tokens, i think i
agree it should be a SHOULD and not a MUST. over the public internet,
twitter would require HTTPS, but inside our data center we would probably
just allow HTTP.
On Tue, Apr 6, 2010 at 11:48 AM, Torsten Lodderstedt <
tors...
+1 for the standard should recommand HTTPS or comparable means of
transport protection but not require it.
This requirement does not result in any benefit for the specification by
itself (e.g. simplification). Therefore, the decision to use HTTPS or
any other means should be up to the service
On Tue, Apr 6, 2010 at 11:26 AM, Allen Tom wrote:
> One of the biggest differences between OAuth2 and WRAP is that OAuth2
> requires that Protected Resources be accessed using HTTPS if no signature is
> being used. Bullet Point #2 in Section 1.2 says:
>
>4. Don't allow bearer tokens without
One of the biggest differences between OAuth2 and WRAP is that OAuth2
requires that Protected Resources be accessed using HTTPS if no signature is
being used. Bullet Point #2 in Section 1.2 says:
4. Don't allow bearer tokens without either SSL and/or signatures.
While some providers may
There is potential for leakage if the client then redirects the user to another
SSL URL. This doesn't feel like a common pattern and the client would generally
be redirecting to a page which they control after receiving the access token.
From 15.1.3 of RFC 2616:
Clients SHOULD NOT include a Refe
Hi all,
here at Deutsche Telekom, we see the need for a flow supporting the
exchange of access tokens for one service into access tokens for another
service.
The scenarios is as follows: In the context of mobile applications, we
employ multi-layered architectures of personalized web services
On Tue, Apr 6, 2010 at 7:53 AM, David Recordon wrote:
> The web client flow was intended to require either a fragment or SSL
> (or optionally both).
>
Even with SSL, referrer leaks seem to be a danger (I think https referrers
are still sent). Are we worried about this?
>
>
> On Tue, Apr 6, 201
For Facebook at least, we are currently planning to use scope as a
comma-separated list of permissions from this set:
http://wiki.developers.facebook.com/index.php/Extended_permissions
For instance:
oauth_scope=read_stream,email,photo_upload
I'm not sure if that maps to realm exactly.
Just curious, where did "duration" come from?
I hate to be picky, but I feel like "expires_in" is more clear than "duration"
... if only because other protocols (OAuth 1.0a, OpenID, Facebook auth) use
"expires".
On Apr 6, 2010, at 12:11 AM, Eran Hammer-Lahav wrote:
Changed to ‘duration’.
EHL
On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/2/10 3:27 PM, "Dick Hardt" wrote:
>
>> There are times when a resource may have different scope for different kinds
>> of access. realm != scope
>
> No. Realm is a subset. It is what people define as the protected segment
> n
The web client flow was intended to require either a fragment or SSL
(or optionally both).
On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert wrote:
>
>
> On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav
> wrote:
>>
>> Hi Evan,
>>
>> On 4/5/10 4:28 PM, "Evan Gilbert" wrote:
>>
>> > 2.4.1 Web Callb
On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav wrote:
> Hi Evan,
>
> On 4/5/10 4:28 PM, "Evan Gilbert" wrote:
>
> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
> > In both flows, the authorization server should be able redirect back to
> the
> > callback URI without interacting directly w
Web clients are expected to have secrets or to have otherwise
registered with the AS. In order for them to use those secrets, they
need to know the AS URL.
Cheers,
Brian
On Tue, Apr 6, 2010 at 1:23 AM, Eran Hammer-Lahav wrote:
> Why?
>
>
> On 4/6/10 12:58 AM, "Brian Eaton" wrote:
>
> On Tue, A
Hi Eran,
I agree that this is the right approach (separate parameters to well defined
scope attributes). However, so far the only well-defined attribute is a
protected segment name (aka realm).
how shall we proceed in order to come to more well-defined attributes? I
already proposed some, c
Why?
On 4/6/10 12:58 AM, "Brian Eaton" wrote:
On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wrote:
> That's the same as what I have in the draft, only with a single endpoint
> instead of two. Since we already have a 'mode' parameter (which I am
> renaming to 'type'), that single endpoint
On Tue, Apr 6, 2010 at 12:47 AM, Eran Hammer-Lahav wrote:
> That’s the same as what I have in the draft, only with a single endpoint
> instead of two. Since we already have a ‘mode’ parameter (which I am
> renaming to ‘type’), that single endpoint can speak more than one flow.
Note that the disco
That's the same as what I have in the draft, only with a single endpoint
instead of two. Since we already have a 'mode' parameter (which I am renaming
to 'type'), that single endpoint can speak more than one flow.
EHL
On 4/6/10 12:37 AM, "Brian Eaton" wrote:
On Tue, Apr 6, 2010 at 12:13 AM,
On Tue, Apr 6, 2010 at 12:13 AM, Eran Hammer-Lahav wrote:
> Yep. I'm trying to remove the need for a more complex discovery.
Not sure we need to do anything, discovery is pretty simple already.
We've been talking a bit about how to enable OAuth for IMAP:
http://tech.groups.yahoo.com/group/sasl_o
Hi Evan,
On 4/5/10 4:28 PM, "Evan Gilbert" wrote:
> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow
> In both flows, the authorization server should be able redirect back to the
> callback URI without interacting directly with the resource owner if access
> has already been approved. This is no
On 4/2/10 3:27 PM, "Dick Hardt" wrote:
> There are times when a resource may have different scope for different kinds
> of access. realm != scope
No. Realm is a subset. It is what people define as the protected segment
name. For any other scope attribute we need to first define it.
EHL
> On
I agree that this is the right approach (separate parameters to well defined
scope attributes). However, so far the only well-defined attribute is a
protected segment name (aka realm).
EHL
On 4/3/10 1:25 AM, "Torsten Lodderstedt" wrote:
> You are right, there are different aspects of scope. Wh
Yep. I'm trying to remove the need for a more complex discovery.
EHL
On 4/3/10 3:35 AM, "Torsten Lodderstedt" wrote:
> I've just seen, the current draft already specifies an attribute
> "authorization-uri" for the WWW-Authenticate header. Is this attribute
> intended for announcing the authori
Changed to 'duration'.
EHL
On 4/5/10 9:09 AM, "David Recordon" wrote:
As one of our engineers was implementing a client, they got confused about what
was being returned by the expires parameter. Anyone object to renaming it to
expires_in so that it's clear that it isn't an absolute timestamp
49 matches
Mail list logo
