Re: New 'Login' Intent?

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