Re: New 'Login' Intent?

Greg, let's pull discussions about oauth into a separate thread, since the
use cases for oauth, i.e. resource authentication, and openid, i.e.
identification, are not the same.  I think the former is important to solve
as well, but they're both tricky so we should separate the discussions.

Thanks,
James

On Tue, May 8, 2012 at 2:11 PM, Greg Billock <gbillock@google.com> wrote:

> 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
> >
> >
> >
>