<div dir="ltr">Hi James,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 4:41 AM, Manger, James <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-AU"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">> </span>allowing the RPs to specify the sector id explicitly is a security risk<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">sector_id actually appears twice in a call to the port_check_endpoint: in the query parameter; and in the enc_port_token JWE header (where the New OP has bound it to the token by including it in the Additional Authenticated Data (AAD) of the AEAD encryption). Section 5 “Port checking API” should explicitly state that the Old OP MUST confirm that these two match.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Similarly the New OP is identified twice: in the iss query parameter; and by the client_id (in the “kid” member) in the JWE. Section 5 “Port checking API” should also explicitly state that the Old OP MUST confirm that these correspond to the same New OP.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The benefit of the duplication it that the Old OP sees the New OP’s view of {Old OP, New OP, RP} and the RP’s view of {Old OP, New OP, RP} and, hence, can ensure they match.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Is the security risk you see that the Old OP might use the query parameter values set by the RP without checking that match the values set by the New OP? Would explicit text saying these checks MUST be done addresses that sufficiently?<u></u><u></u></p><p class="MsoNormal"><u></u></p></div></div></blockquote><div><br></div><div>Yes, unless this is mandated I am concerned that malicious RPs could use the port_check endpoint to discover the sub values provided to other RPs by the Old OP.  However, as Torsten says, mandating this check introduces a tight coupling between how the Old and New OP partition their pairwise subject ids, and also to a certain extent exposes the mechanics of the the pairwise subject id partitioning to the RP.  I would prefer if the sector id was calculated independently by the Old and New OP, derived from the RP's client entry with the individual OPs.  In fact, I would suggest making the sector id that is included in the AAD opaque to the Old OP by hashing it.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-AU"><div><p class="MsoNormal">Authenticating the RP in the Porting check API calls is possible. I was going to add it, but hadn’t worked out any specific attacks that is would prevent so I left it out. It does add the complexity of the RP obtaining a client_id/client_secret for the Old OP, which is non-trivial for the Mobile Connect case. Arne suggests using these credentials directly in the Porting check API (like they are used at the token endpoint), but it would probably be more architecturally correct to use normal OAuth 2.0 and get an access_token from /token for use at the port_check_endpoint (as is used at the user_info_endpoint). That is another request, and another scope value.<u></u><u></u></p><p class="MsoNormal"><u></u></p></div></div></blockquote><div><br></div><div>I'm not sure I see the need for that, to be honest.  If we are going that route, we should probably go all out and use a regular OIDC flow, passing the enc_port_token as a variant of id_token_hint or similar, and present the port_check data in the resulting id_token.  This is certainly a possibility, although I haven't considered all the implications.  It would allow Old OPs to obtain end user consent on a RP-to-RP basis for porting history, if they should so desire, so perhaps it is something we want to consider?  It's going to make the flow for the RP even more complicated, though.<br><br></div><div>BR,<br><br></div><div>Arne.<br><br></div></div></div></div></div>