[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,
Torsten.
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