[Fwd: RE: mobile OpenID and role of mobile carriers]

[Laurent Michel | AF83]

Thanks Paul for this feed back.

Running such a thin client on a mobile device is not that easy ... at 
least on a short term basis : 1) mobile browsers do not allow for 
plugins ..2) having endusers to download and install third party apps is 
a real challenge !

That's why i'm looking for an api running "behind the scene" ...

++

-------- Message original --------
Sujet: 	RE: mobile OpenID and role of mobile carriers
Date: 	Sun, 7 Oct 2007 23:03:32 -0400
De: 	Paul Trevithick <paul at socialphysics.org>
Pour :: 	'Laurent Michel | AF83' <laurent.michel at af83.com>
Références: 	<4709149E.1040408 at af83.com>



Hi Michel,

My 2 cents:

The concept of user's having their own URL-based identifier (e.g.
OpenID/i-name) is a good one. My personal belief is that:
- user's should have ONE and it should resolve to a card-based agent
- user's should configure and run a thin client that knows this identifier
(so they don't have to type it in each time)
- user's should then WITHIN this OpenID/i-name select (by clicking) an
i-card appropriate to the site/service they wish to use.

The Higgins project (http://eclipse.org/higgins) is working on a very thin
client that could be adapted to work on mobile devices. It is i-name/OpenID
compatible and Microsoft CardSpace compatible.

-Paul

> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
> Of Laurent Michel | AF83
> Sent: Sunday, October 07, 2007 1:17 PM
> To: specs at openid.net
> Subject: mobile OpenID and role of mobile carriers
> 
> Hi all,
> 
> I am currently working on "bringing OpenID to mobile" : that is allowing
> the use of OpenID authentification to sign in / up on compliant xHTML
> wap sites / relaying parties.
> 
> So far i've encountered 2 issues :
> 
> 1) to type in the OpenID URL on a wap site login form. It's impossible
> to ask endusers to type in such an url (even i-names) with a mobile
> keyboard .. This may sound like a minor issue ... but it's actually a
> crucial one .. and OpenID could also help on this field too.
> 2) to use mobile operators/carriers as OpenID Providers .. or allow
> existing OpenID providers to delegate the authentification dialog to the
> mobile operator. I think this is quite a strategic issue for OpenID : if
> OpenID tends to offer more reliable authentification, then mobile
> networks have something strong to offer : the ability to strongly
> auto-identify the enduser on each wap session.
> 
> But my main concern these days is 1) :
> I am thinking of proposing the following scheme : a public API allowing
> mobile RPs to automatically discover wether the enduser has an (or many)
> OpenID account(s).
> The API would do the following :
> - the RP transmitts to the API the IP of the mobile enduser + a
> session-ID (most operators use a "x-nokia-gid" paramater transmitted on
> HTTP headers)
> - the API detects if this IP corresponds to a mobile operator gateway
> - if yes : the API asks the mobile operator (API to define and implement
> by mobile operators) if the enduser associated with the sessionID has an
> OpenID accout ...
> - if yes, the API returns to the RP this OpenID
> 
> This assumes that :
> - endusers declare to their mobile tellco their OpenID urls
> - mobile teclos implement the described api
> 
> 
> Does anyone have heard of a similar approach ? Any feedback ?
> 
> Thanks !
> 
> 
> 
> --
> 
> *Laurent Michel | AF83*
> 42, boulevard de Sébastopol | 75003 Paris | France
> Tél. : +33 1 40 27 83 83 | Mobile : +33 6 79 72 0800
> Web : _www.af83.com_ <http://www.af83.com/> | Skype : laurent_michel
> ---
> This email is: [ ] bloggable [ ] ask first [X] private
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs




-- 

*Laurent Michel | AF83*
42, boulevard de Sébastopol | 75003 Paris | France
Tél. : +33 1 40 27 83 83 | Mobile : +33 6 79 72 0800
Web : _www.af83.com_ <http://www.af83.com/> | Skype : laurent_michel
---
This email is: [ ] bloggable [ ] ask first [X] private