Re: [oauth] FW: I-D Action:draft-dehora-farrell-oauth-accesstoken-creds-01.txt

[Justin Hart <[e-mail]>]

Sorry, I should use my real-name identity for the list here.  Anyway,
I realize that what I describe below is sort of the compliment of the
'Valet key' and similar to the approval-queue as described in the blog
post below.  If I'm not missing any pieces, I think its a fully viable
alternative.

I'm looking to implement at least one of these methods as a
non-login-based alternative to the web redirects (avoiding direct
auth) for devices for Photobucket.  I sort of like the 'activation
key' method, as below, myself.

On Tue, Mar 10, 2009 at 10:02 PM, Onyx Raven <[e-mail]> wrote:
> IIRC, when I was first implementing OAuth SP a year ago, there were
> some example use cases where the Consumer/UserAgent could request the
> temporary token, and present it to the user to enter on a different
> channel.  I am reminded that this is essentially the way Netflix
> device activation works.  You get the activation key, and then on your
> PC, you login to your account on the provider and enter the key.  That
> signs the request, and back on the device, it either waits for a
> button-press to attempt to proceed, or auto-checks the key to see if
> it's signed.  The device can then complete the oauth access token
> procedure.  This seems to be a convenient way of obtaining an access
> token, which is fully supported by the current OAuth Core spec if
> implemented properly.  I know that's not the direct intention of the
> spec in the subject, but it is an alternative.
>
> On Tue, Mar 10, 2009 at 9:57 AM, George Fletcher <[e-mail]> wrote:
>>
>> Stephen Farrell wrote:
>>>
>>> Eran Hammer-Lahav wrote:
>>>>
>>>> More ideas in
>>>> http://www.hueniverse.com/hueniverse/2009/02/beyond-the-oauth-web-redirection-flow.html