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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Aug 25 16:31:03 UTC 2016

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,

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. 
> 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>profile at lists.openid.net
>>         <mailto:profile 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/20160825/1928bcd0/attachment-0001.html>

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