Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI

[Kevin Smith <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]<mailto:
>>> [e-mail]>> 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
>>>    <[e-mail] <mailto:[e-mail]>> 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: [e-mail]
>>>        <mailto:[e-mail]>
>>>
>>>
>>>        --
>>>        You received this message because you are subscribed to the
>>>        Google Groups "OAuth WRAP WG" group.
>>>        To post to this group, send email to
>>>        [e-mail]
>>>        <mailto:[e-mail]>.
>>>
>>>        To unsubscribe from this group, send email to
>>>        [e-mail]<[e-mail]>
>>>        <mailto:[e-mail]<[e-mail]>
>>> >.
>>>
>>>        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
>>>    [e-mail]
>>>    <mailto:[e-mail]>.
>>>
>>>    To unsubscribe from this group, send email to
>>>    [e-mail]<[e-mail]>
>>>    <mailto:[e-mail]<[e-mail]>
>>> >.
>>>
>>>    For more options, visit this group at
>>>    http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>