<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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 class="moz-cite-prefix">Am 24.08.2016 um 15:39 schrieb Arne
Georg Gleditsch:<br>
</div>
<blockquote
cite="mid:CAAbeUb25zucxEzZwpwW2ufT8=z1Vz-cgxvib3An8kD58focCMw@mail.gmail.com"
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
moz-do-not-send="true" href="mailto:torsten@lodderstedt.net"><a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></a>
<span dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:argggh@telenordigital.com" target="_blank">argggh@telenordigital.com</a>><br>
An: Torsten Lodderstedt <<a moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br>
Cc: "Manger, James" <<a moz-do-not-send="true"
href="mailto:James.H.Manger@team.telstra.com"
target="_blank">James.H.Manger@team.telstra.<wbr>com</a>>,<a
moz-do-not-send="true"
href="mailto:openid-specs-mobile-profile@lists.openid.net"
target="_blank">openid-specs-mobile-<wbr><a class="moz-txt-link-abbreviated" href="mailto:profile@lists.openid.net">profile@lists.openid.net</a></a><br>
<br>
<p>Torsten Lodderstedt <<a moz-do-not-send="true"
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"><br>
<br>
-- <br>
<br>
Arne.<br>
</font></span></p>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>