<div dir="ltr"><div><div><div>Hi Torsten,<br><br></div>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.<br><br></div>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.<br><br></div><div>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 <font size="1"><span style="font-family:monospace,monospace"><a href="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</a></span></font>. 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.)<br><br></div><div>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.<br><br></div><div>Regards,<br><br></div><div>Arne.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 1:45 PM, Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Arne,<br>
<br>
I think we first of all should come up with a viable solution. <br>
<br>
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:<br>
- it works for front channel OIDC only, where redirect URIs are part
of the protocol. It won't work for any back channel OIDC<br>
- 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<br>
- redirect URIs using custom schemes or device local targets can be
faked, which renders the mechanism useless for native apps<br>
<br>
On the other hand, using the RP's client credentials with the old OP
is the natural way to identify/authenticate RPs in OIDC.<br>
- it works with any grant/response type and flow<br>
- 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<br>
<br>
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. <br>
<br>
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!<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div>Am 24.08.2016 um 15:39 schrieb Arne
Georg Gleditsch:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Torsten,<br>
<br>
</div>
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.<br>
<br>
</div>
Regards,<br>
<br>
</div>
Arne.<br>
<br>
<div>
<div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 24, 2016 at 10:38 AM, <a href="mailto:torsten@lodderstedt.net" target="_blank"></a><a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>
<span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Hi Arne,</p>
<p dir="ltr">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. </p>
<p dir="ltr">I recommend you to take a look onto MODRNA
discovery and registration drafts in our repo. </p>
<p dir="ltr">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. </p>
<p dir="ltr">best regards,<br>
Torsten. </p>
<p dir="ltr">Sent by <a href="http://www.mail-wise.com/installation/2" target="_blank">MailWise</a> – See your emails as clean,
short chats.</p>
<br>
<br>
-------- Originalnachricht --------<br>
Betreff: Re: [Openid-specs-mobile-profile] Alternative
account porting design<br>
Von: Arne Georg Gleditsch <<a href="mailto:argggh@telenordigital.com" target="_blank">argggh@telenordigital.com</a>><br>
An: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br>
Cc: "Manger, James" <<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.c<wbr>om</a>>,<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-</a><a href="mailto:profile@lists.openid.net" target="_blank">profil<wbr>e@lists.openid.net</a><br>
<br>
<p>Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>>
writes:<br>
> 3) RP sends request to porting check API at the old
OP, including the<br>
> porting token + the credentials it regularily uses to<br>
> identify/authenticate with the tokens endpoint of
this particular OP<br>
> (it must have an identity with this OP as it is a RP
for this OP as<br>
> well)<br>
<br>
I agree that complete separation of RP identification is a
nice feature<br>
-- however, we need to keep in mind that in a Mobile
Connect context,<br>
the RPs cannot be expected to hold on to (up-to-date)
credentials for<br>
all OPs, not even the ones they have previously been in
communication<br>
with. For them to to be able to authenticate towards the
old OP, they<br>
would need to first communicate with the Operator
Discovery facility to<br>
retrieve OP-specific credentials. This is not a
show-stopper per se,<br>
but it is going to complicate the flow a bit for the RPs.
We also need<br>
to supply them with information they can use towards
Operator Discovery<br>
to resolve the old OP, i.e just indicating the old iss
value is not<br>
going to be enough at this step. (Although it would be
nice if OD<br>
supported lookups by iss...)<span class="HOEnZb"><font color="#888888"><span><font color="#888888"><br>
<br>
-- <br>
<br>
Arne.<br>
</font></span></font></span></p><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br>
</font></span></div>
</blockquote>
<br>
</div>
</blockquote></div><br></div>