<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Arne,<br>
<br>
sounds reasonable. Does the current operator discovery support the
example request you gave in your posting?<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 26.08.2016 um 10:10 schrieb Arne
Georg Gleditsch:<br>
</div>
<blockquote
cite="mid:CAAbeUb0LnTD3i_wX9Sux=QUfijhhkV-ghPiguPWC8osj2JkDGw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Torsten,<br>
<br>
</div>
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>
<br>
</div>
BR,<br>
<br>
</div>
Arne.<br>
<br>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 25, 2016 at 6:31 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>
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>Am 25.08.2016 um 15:49 schrieb Arne Georg Gleditsch:<br>
</div>
<blockquote 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"
target="_blank"><a class="moz-txt-link-freetext" href="https://discover">https://discover</a>.<wbr>mobileconnect.io/telenor_<wbr>group/v2/discovery?Redirect_<wbr>URL=<a class="moz-txt-link-freetext" href="http://localhost/&">http://localhost/&</a><wbr>Selected-MCC=242&Selected-MNC=<wbr>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_<wbr>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"><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"><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">
<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"><a class="moz-txt-link-abbreviated" href="mailto:James.H.Manger@team.telstra.c">James.H.Manger@team.telstra.c</a><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</a><a
moz-do-not-send="true"
href="mailto:e@lists.openid.net"
target="_blank"><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"><span><font
color="#888888"><br>
<br>
-- <br>
<br>
Arne.<br>
</font></span></font></span></font></span></p>
<span class="HOEnZb"><font
color="#888888"> <span><font
color="#888888"> </font></span></font></span></blockquote>
<span class="HOEnZb"><font color="#888888">
<span><font color="#888888"> </font></span></font></span></div>
<span class="HOEnZb"><font color="#888888">
<span><font color="#888888"> <br>
</font></span></font></span></div>
<span class="HOEnZb"><font color="#888888"> </font></span></blockquote>
<span class="HOEnZb"><font color="#888888"> <br>
</font></span></div>
<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>