Thanks for the good question Torsten - and thanks to Igor for answering it better than I could :) . We are looking at GBA within the OneAPI group but as you say the low deployment base may be a problem.
Best, Kevin On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynberg < igor.faynb...@alcatel-lucent.com> wrote: > A good question! > > I suspect I know the problem here. > > In mobile networks users are authenticated separately and for separate > purposes. So, one gets authenticated via MSISDN for the link layer > connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are > achieved by using the AKA protocol.) > > There is a Generic 3GPP Bootstrapping Architecture standard, which > specifies the method for application authentication, but it has not been > widely deployed, and--to the best of my knowledge--it is not supported by > browsers. > > I do think that AKA can be used directly, with the IETF version of AKA > digest, and we have in fact researched and found the solution for OpenID ( > http://www3.interscience.wiley.com/journal/123441615/abstract), which can > be extended to geolocation. This would indeed allow to authenticate on IMSI > or MSISDN. > > Igor > > Torsten Lodderstedt wrote: > >> Hi Kevin, >> >> what problems do you have with pre-paid users? Is your network unable to >> authenticate them (by IMSI or MSISDN)? >> >> regards, >> Torsten. >> >> Am 08.06.2010 18:31, schrieb Kevin Smith: >> >>> Hi David, Blaine, >>> >>> We (the OneAPI group) have been looking further into OAUTH 2.0 and would >>> like to see how it can work in a mobile network scenario: for example, a >>> desktop Web application wants to locate a mobile user to plot their location >>> on a map. So the client is the Web application and the server is an HTTP >>> platform sitting on top of the mobile core network. >>> >>> It seems that the Web application could register a client ID and client >>> secret with the OneAPI-implementing server. When location is requested by >>> this client, the server would prompt the user, and if permission were >>> received, would enable the client to access the location via an access >>> token/secret. >>> >>> One difference to the regular OAUTH flow is that 'post-pay' contract >>> network subscribers would not have to enter a username/password to identify >>> themselves since they would be implicitly identified on the network anyway; >>> they would just need to confirm authorisation ('Allow/Block'). We are not >>> sure how to handle pre-pay users that buy phone credits in advance. >>> >>> In case either of you (or any other OAUTH expert) would be available to >>> lead a discussion on the technology, and to answer questions from mobile >>> operators and platform vendors, we are having a meeting next Tuesday in >>> London. The meeting is also accessible over Webex. Please let me know if you >>> would be willing to do so, as I'm sure it will help kick-start our >>> implementation work. >>> >>> Cheers! >>> Kevin >>> >>> On Thu, May 6, 2010 at 6:13 AM, David Recordon <record...@gmail.com<mailto: >>> record...@gmail.com>> wrote: >>> >>> +OAuth IETF list >>> -WRAP list to BCC >>> >>> Hi Kevin, >>> OAuth 2.0 should be pretty simple for you to implement and any >>> feedback your team has would be really appreciated! There are >>> already implementations in Cocoa, Python, and Ruby list on the >>> wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the >>> spec at http://tools.ietf.org/html/draft-hammer-oauth2-00. >>> >>> You may also be interested in the mobile web implementation we've >>> built at Facebook. http://developers.facebook.com/docs/guides/mobile/ >>> >>> I'm also cc'ing Blaine Cook who lives in Ireland and might be >>> able to present. >>> >>> Cheers, >>> --David >>> >>> >>> On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone >>> <mrkrcsm...@googlemail.com <mailto:mrkrcsm...@googlemail.com>> wrote: >>> >>> Dear OAUTH WRAP group, >>> >>> My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile >>> operator project called OneAPI ('Open Network Enablers') [1]. >>> The aim >>> is to provide a RESTful API to expose network functions such as >>> location, messaging, payments and more to developers; with the >>> reckoning that this will make it far easier to mash-up Web >>> applications with network capabilities and reduce the time to >>> reach >>> all mobile subscribers in a territory. Thus far we have a >>> live pilot >>> implementation across the 3 major Canadian operators [2] and >>> a non- >>> commercial test site connected to >>> 12 European operators [3], and will be releasing v1.0 >>> specifications >>> backed by the OMA this month. >>> >>> For the first release we did not attempt to prescribe an AAA >>> model to >>> operators, instead leaving them to reuse their own SDP AAA >>> implementation for OneAPI. For our second phase now underway >>> we would >>> like to provide a recommended reference implementation AAA >>> model for >>> operators who are unsure how to allow secure API access whilst >>> allowing user consent and privacy to be respected. Therefore >>> we have >>> discussed OAUTH as an ideal candidate that will be well-known >>> to Web >>> developers. >>> >>> My question regards the suitability of WRAP for such a reference >>> implementation: the decoupling of authentication is good >>> sense and >>> would be welcome by operators, however it appears that WRAP is >>> deprecated and is intended to be replaced by OAUTH 2.0 - is that >>> right? Please could you provide any details on the plans for >>> if/how >>> the two will interoperate? If it's at all possible, we would >>> very much >>> welcome a member of the group to present on WRAP at one of >>> our face-to- >>> face meetings in London - if that is of interest please let >>> me know >>> and I can make arrangements. >>> >>> Thanks for your time and look forward to your advice. >>> >>> Kind regards, >>> Kevin >>> >>> [1] http://www.gsmworld.com/oneapi >>> [2] http://canada.oneapi.gsmworld.com/ >>> [3] http://oneapi.aepona.com/ >>> >>> Kevin Smith >>> Senior Technology Strategist, R&D >>> Vodafone Technology >>> >>> E-mail: kevin.sm...@vodafone.com >>> <mailto:kevin.sm...@vodafone.com> >>> >>> >>> -- >>> You received this message because you are subscribed to the >>> Google Groups "OAuth WRAP WG" group. >>> To post to this group, send email to >>> oauth-wrap...@googlegroups.com >>> <mailto:oauth-wrap...@googlegroups.com>. >>> >>> To unsubscribe from this group, send email to >>> >>> oauth-wrap-wg+unsubscr...@googlegroups.com<oauth-wrap-wg%2bunsubscr...@googlegroups.com> >>> >>> <mailto:oauth-wrap-wg%2bunsubscr...@googlegroups.com<oauth-wrap-wg%252bunsubscr...@googlegroups.com> >>> >. >>> >>> For more options, visit this group at >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> >>> >>> -- You received this message because you are subscribed to the >>> Google Groups "OAuth WRAP WG" group. >>> To post to this group, send email to >>> oauth-wrap...@googlegroups.com >>> <mailto:oauth-wrap...@googlegroups.com>. >>> >>> To unsubscribe from this group, send email to >>> >>> oauth-wrap-wg+unsubscr...@googlegroups.com<oauth-wrap-wg%2bunsubscr...@googlegroups.com> >>> >>> <mailto:oauth-wrap-wg%2bunsubscr...@googlegroups.com<oauth-wrap-wg%252bunsubscr...@googlegroups.com> >>> >. >>> >>> For more options, visit this group at >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
