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

Fri Aug 26 08:10:32 UTC 2016

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> 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> 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>,
>>> openid-specs-mobile- <openid-specs-mobile-profile at lists.openid.net>
>>> profil <profile 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/dc6e45f3/attachment.html>