Re: New 'Login' Intent?

The OAuth implicit grant flow [1] looks pretty amenable to a web
intents adaptation. It would map to an explicit intent -- the client
is looking for an access token for a particular resource, capability,
or permission. Being able to capture that via a web intent as opposed
to a redirect flow is interesting from a user perspective for being
able to take advantages of the web intents UI transitions -- an
overlapped UI surface which is under the control of the provider and
can be properly attributed.

On the client side, the ability to have this act as an async call,
which doesn't need to tear down and rebuild all the desired app state
while the auth call completes, is pretty attractive.


[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2

On Tue, May 8, 2012 at 12:51 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 5/8/2012 10:44 AM, James Hawkins wrote:
>>
>> As far as the namespace is concerned, I'm not entirely sure we can't have
>> a high-level 'identify', but I do believe we should make use of existing
>> technologies instead of inventing a new protocol.  Each identity protocol
>> would have its own action, e.g. http://specs.openid.net/auth/2.0 for OpenID.
>>  The reason for this is that the client needs to verify the authenticity of
>> the identity w/ the server, which requires messaging beyond the simple
>> input/response provided by the basic Web Intents layer.
>
>
> Yeah my take on it is quite similar. I did the OAuth route in our web apps;
> it doesn't have a standard identity, though every provider has something
> like a /self/me end-point which returns JSON describing the user.
> It seems to me that I'd be passing back: {token:'arbitrary', 'endpoint':
> 'https://url'};
>
> From there, I can do client-side via <iframe> and web messaging for a
> channel, or server-side for identity.
>
> -Charles
>
>
>

Received on Tuesday, 8 May 2012 21:11:59 UTC