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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Aug 25 11:45:24 UTC 2016


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-profile at lists.openid.net
>     <mailto:openid-specs-mobile-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/779037bb/attachment.html>


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