[Openid-specs-mobile-profile] Alternative account porting design

Arne Georg Gleditsch argggh at telenordigital.com
Fri Aug 26 10:16:32 UTC 2016

Hi Torsten,

Yes, that endpoint should work for you today, provided you access it using
valid HTTP basic auth credentials (that have been enabled for the
telenor_group organization / the mcc:mnc 242:01 MNO).  You'll see something
like this:

$ curl -uxxx:yyy '
  "ttl": 1480586270,
  "response": {
    "client_id": "XXX",
    "client_secret": "YYY",
    "serving_operator": "telenor_norway",
    "country": "Norway",
    "currency": "NOK",
    "apis": {
      "operatorid": {
        "link": [
            "href": "
            "rel": "authorization"
            "href": "
            "rel": "token"
            "href": "
            "rel": "userinfo"
            "href": "
            "rel": "tokenrefresh"
            "href": "
            "rel": "tokenrevoke"

(The Redirect_URL argument is required, but apparently not used or checked.)



On Fri, Aug 26, 2016 at 11:56 AM, Torsten Lodderstedt <
torsten at lodderstedt.net> wrote:

> Hi Arne,
> sounds reasonable. Does the current operator discovery support the example
> request you gave in your posting?
> best regards,
> Torsten.
> Am 26.08.2016 um 10:10 schrieb Arne Georg Gleditsch:
> Hi Torsten,
> Yes, that's currently the most robust way.  However, as mentioned, I would
> suggest we just provide the RPs with a resolution strategy towards an
> opaque URL (containing these), then the OPs can replace these with
> something more appropriate at their discretion if/when that becomes
> possible.
> BR,
> Arne.
> On Thu, Aug 25, 2016 at 6:31 PM, Torsten Lodderstedt <
> <torsten at lodderstedt.net>torsten at lodderstedt.net> wrote:
>> Hi Arne,
>> thanks for the explanation.
>> If I get it right, the current Mobile Connect credential mgmt regime
>> requires to map the "iss" provided in "aka" to "mnc" & "mcc" because these
>> data are needed to identify the MNO/OP?
>> best regards,
>> Torsten.
>> Am 25.08.2016 um 15:49 schrieb Arne Georg Gleditsch:
>> Hi Torsten,
>> I'm not opposed to the general approach of letting the old OP map to the
>> correct sector id without requiring the new OP to supply all relevant
>> pieces of information needed to do so.  I am, however, apprehensive about
>> formulating an approach that requires deployment and adoption of an
>> entirely new operator discovery and client credentials framework in order
>> to work.
>> FWIW, all the RPs we've helped onboard obtain operator credentials
>> through the operator discovery.  Our OP platform also verifies client
>> credentials using operator discovery's request validator facility.
>> For the current credentials management regime, we need some way to get
>> from the "aka" structure to (the credentials returned in) the json document
>> returned from e.g
>> <https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01>
>> https://discover.mobileconnect.io/telenor_group/v2/
>> discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01.
>> It may be sufficient that we mandate that issuers must include a link like
>> the one above under the key "mc_discovery_identity_endpoint" or similar
>> in its openid-configuration document, for instance.  (It would be nice if
>> the URL was a little less clunky, but as long as it is opaque to the RP, I
>> guess we can improve on that as needed.  The important point would be that
>> it is an endpoint that the RP can invoke with its operator discovery
>> credentials to receive a document containing credentials appropriate for
>> the old OP it is in the process of contacting.)
>> I realize that this is quite Mobile Connect specific, and may be more
>> relevant to a CPAS document rather than to a general spec. However, since
>> this disconnect is introduced with the scheme now under discussion, I'd
>> like the to request that the operators aiming to use this spec in a Mobile
>> Connect context indicate if they'd support this approach of managing
>> credentials for RPs using the current incarnation of operator discovery, or
>> if there are other ways we could close this gap.
>> Regards,
>> Arne.
>> On Thu, Aug 25, 2016 at 1:45 PM, Torsten Lodderstedt <
>> <torsten at lodderstedt.net>torsten at lodderstedt.net> wrote:
>>> Hi Arne,
>>> I think we first of all should come up with a viable solution.
>>> My concern is if we depend the solution on a rather limited approach to
>>> RP identification. In my observation, using redirect URIs (or sector ids)
>>> for that purpose has the following issues:
>>> - it works for front channel OIDC only, where redirect URIs are part of
>>> the protocol. It won't work for any back channel OIDC
>>> - it assumes the RP's redirect URI is the same for old and new OP, which
>>> may directly contradict security mitigations for the mix-up attack. Based
>>> on the current discussions about this attack, I expect the community will
>>> advice implementors to use distinct/different redirect URIs for every OP/AS
>>> - redirect URIs using custom schemes or device local targets can be
>>> faked, which renders the mechanism useless for native apps
>>> On the other hand, using the RP's client credentials with the old OP is
>>> the natural way to identify/authenticate RPs in OIDC.
>>> - it works with any grant/response type and flow
>>> - all logic to determine the subject value for a RP is already in place
>>> at the old OP, they will just be reused for the migration use case
>>> Do we have real issues with the way operator discovery works today? I
>>> don't know. According to my information, most active deployments use
>>> manually configured client credentials. My proposal would work in these
>>> deployments right away. If other deployments want to offer account
>>> migration, either API exchange will need to offer a way to directly obtain
>>> client credentials or those deployment are being migrated towards dynamic
>>> client registration (which is on the roadmap anyway). I think that's an
>>> acceptable price for having a secure and privacy-preserving account
>>> migration solution.
>>> I agree with you, account migration is a strongly desired feature, but
>>> we should take the time to come up with a really robust and secure
>>> solution. In my opinion, account migration is the most security-critical
>>> function in Mobile Connect. If we don't to it right in our first attept, it
>>> will allow attackers to conveniently hijack accounts using an interoperable
>>> API. That really scares me!
>>> best regards,
>>> Torsten.
>>> Am 24.08.2016 um 15:39 schrieb Arne Georg Gleditsch:
>>> Hi Torsten,
>>> I welcome an overhaul of the discovery process, but it concerns me if we
>>> make that a prerequisite of getting a viable solution to life cycle
>>> handling in place.  I think this is overdue as it is, I'd be much happier
>>> if we could design a scheme that worked with both variants of operator
>>> discovery.
>>> Regards,
>>> Arne.
>>> On Wed, Aug 24, 2016 at 10:38 AM, <torsten at lodderstedt.net>
>>> torsten at lodderstedt.net < <torsten at lodderstedt.net>
>>> torsten at lodderstedt.net> wrote:
>>>> Hi Arne,
>>>> I hope Mobile Connect discovery and credential management will be
>>>> decoupled and aligned with OpenId/OAuth standard mechanisms. We had
>>>> productive discussions about that topic with GSMA and will see first
>>>> results with the intro of the openid-configuration to API exchange soon.
>>>> Next step might be use of Software Statements for credential mgmt.
>>>> I recommend you to take a look onto MODRNA discovery and registration
>>>> drafts in our repo.
>>>> In this case, RPs will have/manage their OP credentials independent of
>>>> the discovery process. So it should be possible to authenticate towards the
>>>> old OP.
>>>> best regards,
>>>> Torsten.
>>>> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
>>>> emails as clean, short chats.
>>>> -------- Originalnachricht --------
>>>> Betreff: Re: [Openid-specs-mobile-profile] Alternative account porting
>>>> design
>>>> Von: Arne Georg Gleditsch < <argggh at telenordigital.com>
>>>> argggh at telenordigital.com>
>>>> An: Torsten Lodderstedt < <torsten at lodderstedt.net>
>>>> torsten at lodderstedt.net>
>>>> Cc: "Manger, James" < <James.H.Manger at team.telstra.com>
>>>> James.H.Manger at team.telstra.com>,openid-specs-mobile-
>>>> <openid-specs-mobile-profile at lists.openid.net>profil
>>>> <profile at lists.openid.net> <e at lists.openid.net>e at lists.openid.net
>>>> Torsten Lodderstedt < <torsten at lodderstedt.net>torsten at lodderstedt.net>
>>>> writes:
>>>> > 3) RP sends request to porting check API at the old OP, including the
>>>> > porting token + the credentials it regularily uses to
>>>> > identify/authenticate with the tokens endpoint of this particular OP
>>>> > (it must have an identity with this OP as it is a RP for this OP as
>>>> > well)
>>>> I agree that complete separation of RP identification is a nice feature
>>>> -- however, we need to keep in mind that in a Mobile Connect context,
>>>> the RPs cannot be expected to hold on to (up-to-date) credentials for
>>>> all OPs, not even the ones they have previously been in communication
>>>> with.  For them to to be able to authenticate towards the old OP, they
>>>> would need to first communicate with the Operator Discovery facility to
>>>> retrieve OP-specific credentials.  This is not a show-stopper per se,
>>>> but it is going to complicate the flow a bit for the RPs.  We also need
>>>> to supply them with information they can use towards Operator Discovery
>>>> to resolve the old OP, i.e just indicating the old iss value is not
>>>> going to be enough at this step.  (Although it would be nice if OD
>>>> supported lookups by iss...)
>>>> --
>>>> Arne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160826/23238ef9/attachment-0001.html>

More information about the Openid-specs-mobile-profile mailing list