[Openid-specs-mobile-profile] Account porting: draft -01: New OP encrypting port_token

[Arne Georg Gleditsch]

Hi James, group,

I think this proposal is starting to look really solid.  My reflections on
the current version:

Section 3. port_token vs port_token_plain:

Do we need both flows?  I recognize that the mechanics of encrypting and
decrypting the port token represent additional complexity that some IdP
implementors would prefer to avoid, and that only supplying port_token
results for the port_data endpoint would allow them to skip implementing
the decryption part for when they act in the capacity of "Old OP".
However, when acting in the capacity of "New OP", every OP needs to be
prepared to deal with both port_token and port_token_plain, so all of the
heavy lifting in terms of dealing with the described encryption scheme must
be implemented anyway.

I suggest dropping the currently specified port_token result type from the
port_data endpoint, unless we envision scenarios where (a significant numer
of) OPs will act only as "Old OP" and never "New OP", or there are other
arguments for keeping it.

Also, I understand that the implication of the port_token_plain field name
is that the given token has not been encrypted *yet*, but I still find it a
bit confusing, seeing as it signals that the encryption flow should be
triggered.  Can we call it port_token_seed, perhaps?

Section 5. Porting check API:

I think allowing the RPs to specify the sector id explicitly is a security
risk, and suggest that we mandate that RPs authenticate towards the Old OP
using HTTP Basic Auth (in the same way as they would towards the
token_endpoint), and that the Old OP resolves the sector id based on the
authenticated client id.  Alternatively, we could mandate that the Old OP
somehow verifies the given sector id towards the encrypted port_token, but
that would introduce a coupling between the pairwise subject id algorithms
of Old and New OP that I understood we wanted to avoid.

(For the Mobile Connect specific scenario, adding authentication to this
invocation requires that the RPs are able to resolve their Operator
Discovery-provided credentials towards the Old OP based solely on the iss
value. I suggest that we presume that the Operator Discovery facility will
be able to assist with this at some point in the future.  Should that turn
out to not be possible, a fallback strategy could be to make the OPs
include a member mc_od_identity in their configuration document, with
values like e.g "
https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01
". Mobile Connect RPs could then invoke this endpoint using their Operator
Discovery credentials to obtain credentials appropriate for use towards the
Old OP's port_check endpoint.)

BR,

Arne.


On Thu, Sep 22, 2016 at 10:30 AM, Manger, James <
James.H.Manger at team.telstra.com> wrote:

> Attached is an updated draft of OpenID Connect Account Porting:
> draft-account-porting-01.
>
>
>
> Or read it at https://id.cto.telstra.com/2016/openid/draft-account-
> porting.html
>
>
>
> I will put it in the Bitbucket repo
> <https://bitbucket.org/openid/mobile/src/>, once I have sorted out some
> glitches. [There are 2 “default” branches after Gonzalo’s recent commits,
> which is hiding earlier commits by John, Joerg, and I. A merge should do
> it, if I can work out how.]
>
>
>
>
>
> The main change in this draft is that the New OP collects a single token
> from the Old OP representing a porting event. The New OP needs to bind it
> to a sector_id and anonymizes it before passing it to RPs — which is done
> by applying symmetric authenticated encryption, keyed with H(client_secret).
>
>
>
> This draft does NOT require RPs to authenticate to the Old OP. It assume
> the encrypted port token can act as a bearer token (ie a capability).
>
>
>
> There is a pretty flow diagram in appendix A. This time in SVG instead of
> a PNG.
>
>
>
> Comments welcome, indeed required.
>
>
>
> --
>
> James Manger
>
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160926/906e0578/attachment.html>