[Fwd: RE: mobile OpenID and role of mobile carriers]
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 [EMAIL PROTECTED] Pour :: 'Laurent Michel | AF83' [EMAIL PROTECTED] Références: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent Michel | AF83 Sent: Sunday, October 07, 2007 1:17 PM To: specs@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@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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [Fwd: RE: mobile OpenID and role of mobile carriers]
Here are some more thoughts. I agree with Laurent, 3rd party applications on mobiles are a pain - too many architectures to deal with. Especially if you are trying to do something interesting you can't do with J2ME + JSRxxx. Windows mobile will be no problem when (if) it gets cardspace as there is the option for openid over cardspace as previously demonstrated, but we may have a long wait. Without protection the header/callback method proposed provides a rather simple way to track your movements around the internet back to your openid (paranoid hat on). Also, couldn't you achieve exactly the same effect with a gateway which sends out a x-openid: my.openid.here header? To alleviate the tracking problem you could protect this with a allow/deny page provided by the network e.g. 1. RP detects mobile browser using header information 2. RP discovers the auto-openid-discovery url at the mobile network (maybe the header simply contains the discovery url) 3. RP redirects the user browser to that url 4. Mobile network check the user's mobile matches a known registered user of the discovery service and presents an allow/deny page 5. User presses allow or deny 6. Network redirects back to the RP with the openid in a header if the user allowed it 7. RP initiates discovery/authentication - from the beginning because the previous steps prove nothing about the user's identity If you had a browser plugin you could send the x-openid header on demand and not need to do the above. Mobile phone possession as an authentication method is very interesting. Not sure how the delegation of this service would work - it is tricky if you aren't in control of the gateway and able to tie the browser and phone together. This is off the top of my head so let me know if I have missed something obvious! Andrew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent Michel | AF83 Sent: 08 October 2007 10:33 To: specs@openid.net Subject: [Fwd: RE: mobile OpenID and role of mobile carriers] 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 [EMAIL PROTECTED] Pour :: 'Laurent Michel | AF83' [EMAIL PROTECTED] Références: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent Michel | AF83 Sent: Sunday, October 07, 2007 1:17 PM To: specs@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
SVN URLs Changed
Hey all, We're currently in the process of changing all of the SVN URLs to be in the form of http://svn.openid.net/. New URLs are: http://svn.openid.net/ - WebSVN http://svn.openid.net/repos/website/ http://svn.openid.net/repos/specifications/ Sorry for the change, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PAPE Extension Specification
# Yep, the idea is for the PAPE spec to define a few generic and # agreed upon policies and then RPs and OPs can create others. Thus # if there isn't agreement on a policy, there would be multiple policy # URIs. Same concept as in Attribute Exchange. Using policy URIs to indicate certain modes of authentication is a fine idea, but that doesn't really address the original issue: the spec does not define active (direct) authentication. -- Jonathan Daugherty JanRain, Inc. irc.freenode.net: cygnus in #openid cygnus.myopenid.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
