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

Torsten Lodderstedt torsten at lodderstedt.net
Fri Aug 26 09:56:28 UTC 2016

Hi Arne,

sounds reasonable. Does the current operator discovery support the 
example request you gave in your posting?

best regards,

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 <mailto: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 <mailto: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
>>>         <mailto:torsten at lodderstedt.net> <torsten at lodderstedt.net
>>>         <mailto: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
>>>             <mailto:argggh at telenordigital.com>>
>>>             An: Torsten Lodderstedt <torsten at lodderstedt.net
>>>             <mailto:torsten at lodderstedt.net>>
>>>             Cc: "Manger, James" <James.H.Manger at team.telstra.com
>>>             <mailto:James.H.Manger at team.telstra.com>>,openid-specs-mobile-
>>>             <mailto:openid-specs-mobile-profile at lists.openid.net>profil
>>>             <mailto:profile at lists.openid.net>e at lists.openid.net
>>>             <mailto:e at lists.openid.net>
>>>             Torsten Lodderstedt <torsten at lodderstedt.net
>>>             <mailto: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/13cda3b4/attachment-0001.html>

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