Re: New 'Login' Intent?

I've been thinking about this problem (identity over Intents) for a while
and have a few thoughts.

First and foremost we should identify (no pun intended) compelling use
cases:
* Provide identity authentication to client sites.

There are several protocols currently designed to address this use case,
e.g. OpenID [1] and Facebook Connect [2] .  FB Connect is 1:1 with respect
to client:service, while OpenID is 1:C, i.e. a client may connect to a
constant number of identity providers which must be known in advance.  If
the client does not explicitly handle authenticating identity w/ identity
provider Z, user's that log in using Z are out of luck.  Note that most
uses of OpenID are a form of the NASCAR problem, due to the need to provide
as many providers as possible to get more coverage for users [3].

Web Intents can be used to bump 1:C to 1:N by providing discovery for the
client (and get rid of the NASCAR buttons while we're at it).

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.

Let's take OpenID as an example.  Though it may be possible for an OP
(OpenID Provider) to exist entirely client-side, the most common
implementation of an OP requires a server-side component; therefore, a Web
Intents OP service should act as a proxy between the client and the server.
 The client would create a MessageChannel, passing a port to the service in
the payload for the protocol communication.  The client would send messages
to the service via postMessage, the contents of which conform to the
protocol as specified in the OpenID spec [4].  The protocol states the
messages are "mappings of plain-text keys to plain-text values" which jives
with passing JS objects through postMessage.  The WI service translates
these messages into the appropriate HTTP encoding, passes the data to the
server, and translates the responses from the server into an object to
proxy back to the client.

I'm planning to implement an example OpenID proxy for Google accounts [5]
which I'll publish on github.

Thanks,
James

[1] openid.net
[2] http://developers.facebook.com/docs/guides/web/#login
[3] http://openid-selector.googlecode.com/svn/trunk/demo.html
[4] http://openid.net/specs/openid-authentication-2_0.html
[5] https://developers.google.com/accounts/docs/OpenID

On Sun, May 6, 2012 at 7:36 PM, Eiji Kitamura <agektmr@google.com> wrote:

> There's a guy (cc'ed) who implemented OpenID Connect over WebIntent..
>
> http://t.oauth.jp/post/20756025471/when-you-access-to-an-openid-relying-party-rp
>
> Just FYI.
>
>
> On Mon, May 7, 2012 at 11:09 AM, Charles Pritchard <chuck@jumis.com>wrote:
>
>> On 5/6/2012 2:53 PM, Doug Schepers wrote:
>>
>>> I propose that we have another intent, 'Login' (I don't care about the
>>> name... it could be 'SignOn', 'SignIn', 'SelectIdentity', or whatever).
>>> This would let users select from their choice of Identity Providers (IDPs),
>>> or to create or use a bespoke account for that specific site.
>>>
>>> A corollary to this would be 'Comment' or 'Discuss', which is often
>>> hosted by third-party services like Disqus.
>>>
>>
>> How do we verify the authenticity of the ID?
>> event={ data: { user: 'arbitrary' }, origin: 'example.com' };
>>
>> Intent doesn't have a mechanism for checking that the origin is
>> example.com.
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Eiji Kitamura | Developer Advocate | agektmr@google.com | +81-80-1150-6480
>
>