[OpenID] Can we make a seamless OpenID mobile experience?
lshepard at facebook.com
Mon Apr 13 15:36:36 UTC 2009
That's a great distinction, Nat. As you and Allen point out, OpenID is reasonably robust as long as there is some sort of browser on the device - even if it's small, we can accommodate it. The For example, the iPhone is a enables a full-featured browser, even with applications. For Facebook Connect for iPhone, we use the web view with a custom UI to let users log in directly to facebook.com: http://developers.facebook.com/connect_iphone.php .
The main use case that hasn't been addressed is what to do for applications and devices for which opening a browser is impossible, or at least doing so represents a significantly degraded user experience.
It seems that the number of devices that are internet-enabled, but lack proper web browsers, is only increasing. Yes, the upper end phones have browsers now, but there are plenty of phones that don't have great browsers but still allow applications. In addition, there are plenty of set-top boxes that may be able to call out to a browser, but it's a pain, and even more for which it's impossible. And don't we want OpenID to work on all devices?
For those kinds of devices, Facebook enables a special API that lets trusted partners submit email and password and get a session directly. That's how you can enter your email/password directly into the Blackberry app and it just works.
Many providers use email/password or username/password, but not all, and in fact OAuth and OpenID were built explicitly to not require passwords, which is great. Allen raises a great point, too - one of the scenarios enabled by OpenID is delegating through multiple authorities - i.e,. I use my Google OpenID to log in to, say, Yahoo, and then I use that to authorize Flickr photos to a photo printing service. With the chain of redirects in a browser, this is doable, but how do you manage that chain of responsibility without a browser?
I don't have an answer - doing it in a distributed way is really hard, which is why the community has basically punted on it. I just want to raise that it is a real problem, and if the open protocols always require a one-size-fits-all "stick it in a browser", then they will always be at a competitive disadvantage to systems that do enable login to devices without browsers. So it is in the interests of the community to brainstorm a solution to this problem.
On 4/12/09 11:00 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:
When we talk about mobile, I think we should devide the device into
iPhone kind of intelligent device is one, then WAP etc. phone is another, and
there is SMS deveices.
In Japan, i-mode/wap type of browser phone is the norm.
They have unique identifiers assigned at the carrier gateway.
(So does some U.S. phones as well.)
These can be treated fairly robust as long as we are on SSL/TLS
channel. Thus, after registering the device to the OP, the
user experience will be quite seamless.
The user goes to the RP, clicks on Login, he will be taken to the OP
and automagically logged in with the device id, and sent back to
the RP. There is no click other than the initial click on the OP
Downside is: OpenID messages are lengthy with GET, and when it is
coupled with AX or something like that, many phone will choke.
Something similar to SAML's Artifact binding would be preferable over the
current "GET/POST" binding.
On Sat, Apr 11, 2009 at 11:14 AM, Allen Tom <atom at yahoo-inc.com> wrote:
> The problem with having the client directly submit the username/password to
> the SP is that it requires OAuth Service Providers to have passwords for
> their users, implying that OpenID Relying Parties cannot be OAuth SPs.
> For an example of a good mobile browser based OAuth UX, check out the
> Sparrow iPhone App for Fire Eagle. The Sparrow app opens Safari to the
> Yahoo Mobile Login screen, and then sends the user to the Fire Eagle OAuth
> Permissions screen to authorize the OAuth token. The Sparrow App
> automatically regains focus after the user authorizes the token via a
> custom protocol handler on the OAuth callback URL.
> Is the UX demonstrated by the Sparrow iPhone app sufficient for mobile apps?
> I think it's just as good, if not better, than submitting the
> username/password directly to the SP.
> Luke Shepard wrote:
>> It's still not great.
>> For example, take my Gmail app on my Blackberry. I don't have to go to a
>> website- I can enter my credentials directly. This is great- if I had to go
>> to a web browser, I would probably never have installed it.
>> So, how can we do that with OpenID and OAuth?
>> One way could be an extension that allows an OAuth consumer to ping the
>> provider directly with a username and password, and get a token directly.
>> Yes, this has issues with trust and security. But my point is that these
>> apps are being built already, and wouldn't it be cool if they were built
>> using open standards?
>> So I'm just putting it out there.
> general mailing list
> general at openid.net
Nat Sakimura (=nat)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general