rd),
> or the user running the app?
> *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)**
> **lainh...@us.ibm.com*
>
>
>
>
>
> From:Vincent Tsang
d - the app (e.g. Word),
or the user running the app?
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com
From:Vincent Tsang
To:Nat Sakimura ,
Cc:"oauth@ietf.org"
50**
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com *
From: Vincent Tsang >
To: Nat Sakimura >,
Cc: "oauth@ietf.org " >
Date: 05/29/2013 12:31 AM
Subject: Re: [OAUTH-WG] Device profile usage
Se
7;vincets...@gmail.com');>>
> To:Nat Sakimura 'sakim...@gmail.com');>>,
> Cc: "oauth@ietf.org "
> >
> Date:05/29/2013 12:31 AM
> Subject:Re: [OAUTH-WG] Device profile usage
> Sent by:oauth-boun...@ietf.o
The device flow is really made for cases where the client software can't
open a full browser at all, like a limited set top box or embedded
device. Since you can access a browser, you can very easily do an
authorization code flow with a native app. The only "trick" is getting
the code back to t
Subject: Re: [OAUTH-WG] Device profile usage
The client is a native windows application, for instance, a document editor
like MS Word.
The editor can upload copies to the cloud (e.g. Amazon S3), then record the
version history and notes associated with each cloud copy to our cloud service
via our
,
Cc: "oauth@ietf.org"
Date: 05/29/2013 12:31 AM
Subject: Re: [OAUTH-WG] Device profile usage
Sent by:oauth-boun...@ietf.org
The client is a native windows application, for instance, a document
editor like MS Word.
The editor can upload copies to the cloud (e
The client is a native windows application, for instance, a document editor
like MS Word.
The editor can upload copies to the cloud (e.g. Amazon S3), then record the
version history and notes associated with each cloud copy to our cloud
service via our cloud application API (to be secured by OAuth
A little more application and user context would help.
A use case, so to speak.
Nat
2013/05/29 12:04、Vincent Tsang のメッセージ:
> Hi Hannes,
>
> Thanks for your reply.
> Actually I am new to OAuth and am simply trying to search for the best
> industrial practice for granting access tokens when the
Hi Hannes,
Thanks for your reply.
Actually I am new to OAuth and am simply trying to search for the best
industrial practice for granting access tokens when the client to our
application API is a simple windows applications, which in most cases runs
on PC's with web browser installed.
Therefore th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Vincent,
from a pure standardization point of view that draft is long expired.
This document was initially created because the device profile was one of the
least mature parts of the OAuth 2.0 protocol. We were hoping to gain a bit more
deplo
Hi all,
I'm looking for the most suitable solution to grant the access token for
accessing our cloud service API for clients which is a windows application
with no internet browsing capability itself (though it can be installed on
a PC with access to internet). After some research, it seems the de
On Tue, Aug 2, 2011 at 3:19 PM, Aiden Bell wrote:
> Hi,
>
> I am currently implementing the device profile described at
> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
>
> Wanted to check this hadn't been superseded by any other document or
> protocol
> though I did notice the Googl
Hi,
I am currently implementing the device profile described at
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
Wanted to check this hadn't been superseded by any other document or
protocol
though I did notice the Google implementation is in-line with this document.
Even though the
While it's been a few weeks, I've made these changes and posted the Device
profile as an Internet Draft:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00. We're working
on an implementation at Facebook and hope to provide feedback toward the
next draft.
In the meantime I'd like to requ
Even better, thanks!
On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wrote:
> On Thu, Jul 15, 2010 at 2:11 PM, David Recordon
> wrote:
> > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
> >> “The client makes the following request at an arbitrary but reasonable
> >> interval which
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
>> “The client makes the following request at an arbitrary but reasonable
>> interval which MUST NOT exceed the minimum interval rate provided by
>> the authorization server (if p
boun...@ietf.org] *On Behalf
> Of *David Recordon
> *Sent:* Thursday, July 15, 2010 3:47 PM
> *To:* OAuth WG
> *Cc:* Jim Brusstar
> *Subject:* [OAUTH-WG] Device profile draft
>
>
>
> I've broken the device profile out of draft 06 so that it now lives in a
> separate docu
ot the requirement be the same in both places?
Zachary
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Thursday, July 15, 2010 3:47 PM
To: OAuth WG
Cc: Jim Brusstar
Subject: [OAUTH-WG] Device profile draft
I've broken the device
On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher wrote:
> Looks good.
>
> Are there any restrictions on the device_code such that it has to be under
> a certain size? Seems like it would be good to protect against random
> polling attacks (I presume this is what the Google research refers to). I
Looks good.
Are there any restrictions on the device_code such that it has to be
under a certain size? Seems like it would be good to protect against
random polling attacks (I presume this is what the Google research
refers to). If there are no size restrictions then the device_code could
be
I've broken the device profile out of draft 06 so that it now lives in a
separate document as an extension and have updated it to fit into the draft
10 structure. It defines a new "device endpoint" for the initial setup
request where the client gets the two codes and URL. It then uses the
existing
>From the spec:
The client makes the following request at an arbitrary but reasonable *interval
*which MUST NOT *exceed the minimum **interval rate *provided by the
authorization server (if present via the interval parameter).
I know what an interval is, and I know what a rate is. But "interval
On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wrote:
>> "The client is incapable of receiving incoming requests from the
>> authorization
>> server (incapable of acting as an HTTP server). ADD:
>> The device manufacturer is assumed to have registered with the
>> authorization server. The a
On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wrote:
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Brian Eaton
>> Sent: Monday, April 26, 2010 11:27 PM
>> To: David Recordon
>> Cc: o
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Monday, April 26, 2010 11:27 PM
> To: David Recordon
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] device profile comments
>
> On Thu, Apr
On Thu, Apr 22, 2010 at 5:58 PM, David Recordon wrote:
> I don't fully understand what you're proposing. The device would show a
> screen which tells the user to visit http://fb.me/xbox and enter the code
> 123456. (Or to visit http://xbox.com/fb.) Asking a user to go to
> http://goo.gl/?client_id
I sent this reply to Brian's original email earlier, but forgot to click
reply-all.
I disagree with hardcoding the approval URL into the device. To enable short
URLs, there's nothing in the spec preventing the Auth Server from returning a
different approval URL for each client id. E.g.,http://w
- Authorization server doesn’t return approval URL - device hard-codes
this instead.
I expect that this will point to a manufacturer specific page, and
that the manufacturer specific page will automatically redirect to a
page on the authorization server.
Why not returning client-id-spe
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
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
Google has a similar requirement to move these types of devices to
OAuth/WRAP and away from our older "ClientLogin" protocol where the user is
prompted for their username/password. The proposed profile looks fine, but
we are a few weeks from being able to do specific work on it, so we may have
mor
and the user might not be near a
>> browser-capable device..
>
> I'm not sure I like the reverse of this scenario. What stops other people
> from entering my identifier into their device, thus causing the AS to ping me
> via email or SMS? Also, the Device Profile was created as the
mail or SMS? Also, the Device Profile was created as the reverse of OAuth, so
the reverse of the Device Profile is just a variation on regular OAuth! Maybe
this could be developed into yet another profile.
-Brent
> -Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-bo
etf.org] On Behalf Of
> Brent Goldman
> Sent: Thursday, March 11, 2010 4:28 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] Device Profile
>
> Over the past couple days, Luke Shepard, David Recordon, and I have been
> brainstorming an OAuth profile for standardi
.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brent
Goldman
Sent: Thursday, March 11, 2010 4:28 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Device Profile
Over the past couple days, Luke Shepard, David Recordon, and I have bee
Over the past couple days, Luke Shepard, David Recordon, and I have been
brainstorming an OAuth profile for standardizing the flow that devices such as
game consoles and entertainment centers use to hook up with services such as
Netflix and iTunes. The basic flow is that a device can gain author
37 matches
Mail list logo
