Hi Kevin,
out of curiosity: why do you experience this problem with pre-paid users
only?
regards,
Torsten.
Am 14.06.2010 13:54, schrieb Kevin Smith:
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
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> 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: [email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
--
You received this message because you are
subscribed to the
Google Groups "OAuth WRAP WG" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>.
To unsubscribe from this group, send email to
[email protected]
<mailto:oauth-wrap-wg%[email protected]>
<mailto:oauth-wrap-wg%[email protected]
<mailto:oauth-wrap-wg%[email protected]>>.
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
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>.
To unsubscribe from this group, send email to
[email protected]
<mailto:oauth-wrap-wg%[email protected]>
<mailto:oauth-wrap-wg%[email protected]
<mailto:oauth-wrap-wg%[email protected]>>.
For more options, visit this group at
http://groups.google.com/group/oauth-wrap-wg?hl=en.
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------------------------------------------------
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
