Re: New 'Login' Intent?

Would you post the connect and response examples?


Such as: a = new Intent(...);

res.postMessage({...});

I saw one on your presentation but I'd like to confirm I've seen the full concept.

OAuth 2 is much simpler than OAuth as they basically get rid of a layer in favor of SSL (which does not work or requires interception in some cases, such as extensions).

IMO, they're two different things and OAuth2 could be more appropriate for web intents as-is.


On May 8, 2012, at 11:01 PM, nov matake <matake@gmail.com> wrote:

> Hi all,
> 
> Nice too meet you.
> 
> As Eiji introduced, I've made a WebIntents-based OpenID Connect demo sites.
> https://connect-op.heroku.com/ (IdP, access here and register intent service first)
> https://connect-rp.heroku.com/ (RP, click "Or Try WebIntents?" button after registering above IdP as intent service)
> * WebIntents demo works only in Safari now :(
> 
> OpenID Connect is based on OAuth 2.0 and handling OpenID Connect Client Registration (= OAuth client registration in standardized way) was the hardest part in my case.
> That's why I gave up to handle whole OpenID Connect flow in WebIntents and focused on OpenID Connect Discovery (= Simple Web Discovery, similar to WebFinger).
> In OpenID 2.0, it doesn't have "Client Registration", so we might can use WebIntents in different layer tough.
> 
> For OpenID Connect Discovery, current WebIntents spec seems enough useful for me.
> 
> Cheers
> 
> --
> nov matake
> 
> 
> 2012/5/9 James Hawkins <jhawkins@chromium.org>
> 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
> >
> >
> >
> 
> 
> 
> 
> -- 
> nov matake