<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Arne,<br>
<br>
thanks for the explanation.<br>
<br>
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?<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 25.08.2016 um 15:49 schrieb Arne
Georg Gleditsch:<br>
</div>
<blockquote
cite="mid:CAAbeUb3xpB+wkg0nBzbexnzRn7EdUVVt3DLtshAUN3bCuR9j4A@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
href="https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01"><a class="moz-txt-link-freetext" 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></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
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></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 moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank">torsten@lodderstedt.net</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"><a class="moz-txt-link-abbreviated" href="mailto:argggh@telenordigital.com">argggh@telenordigital.com</a></a>><br>
An: Torsten Lodderstedt <<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></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.c<wbr>om</a>>,<a
moz-do-not-send="true"
href="mailto:openid-specs-mobile-profile@lists.openid.net"
target="_blank">openid-specs-mobile-</a><a
moz-do-not-send="true"
href="mailto:profile@lists.openid.net"
target="_blank">profil<wbr><a class="moz-txt-link-abbreviated" href="mailto:e@lists.openid.net">e@lists.openid.net</a></a><br>
<br>
<p>Torsten Lodderstedt <<a
moz-do-not-send="true"
href="mailto:torsten@lodderstedt.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></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>
</blockquote>
<br>
</body>
</html>