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

[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> 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> 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>
>> An: Torsten Lodderstedt <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
>> e at lists.openid.net
>>
>> Torsten Lodderstedt <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/cd5dcd24/attachment.html>