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

[Manger, James]

Hi Arne,
> Section 3. port_token vs port_token_plain:
> Do we need both flows?
The idea was to avoid the encrypt/decrypt complexity when public (not pairwise) subs were being used. Thinking about it more, that only works if both Old and New OPs use public subs. Even if the Old OP uses public subs, it should still use port_token_plain (to be encrypted/decrypted) in case the New OP uses pairwise subs — and the Old OP doesn’t really know what type of subs the New OP will use.

So I agree we should drop the port_token option from the port_data endpoint.


> port_token_plain … Can we call it port_token_seed, perhaps?

…_seed doesn’t have quite the right connotation to me. How about:
port_token (renaming port_token_plain in port_data_endpoint response); and
enc_port_token (renaming port_token in aka member)?

--
James Manger

From: Arne Georg Gleditsch [mailto:argggh at telenordigital.com]
Sent: Tuesday, 27 September 2016 3:18 AM
Subject: Re: [Openid-specs-mobile-profile] Account porting: draft -01: New OP encrypting port_token

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?

…
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160927/7b8049d3/attachment-0001.html>