[Openid-specs-mobile-profile] Alternative account porting design

GONZALO FERNANDEZ RODRIGUEZ gonzalo.fernandezrodriguez at telefonica.com
Wed Aug 17 06:58:23 UTC 2016

Hi James,

First of all, thank you a lot for such good contribution. I guess that make a call from the RP to the old MNO is an alternative to avoid keeping a migration key for a long time. However, I am wondering if it is worth it to add the complexity in the MNO side that implies to keep all the migration data for years, even for users that can be already migrated to a third operator, and I think that it isn't.

From my perspective, when a user decides to be migrated to another MNO, the migration process should have an "end" milestone well defined that would be the moment when the user executes the action an all of their data are migrated to the new operator. I don't see it is a big problem for the RP to parse a JWT with the migration data, and of course the migration key should be keep for some reasonable time, but I also think that if a user is not logged in a web site for a long time (more than one year) it wouldn't be a big problem for him to loose their account and create a new one, because at the end is an account that is not used.


From: Openid-specs-mobile-profile on behalf of "Manger, James"
Date: Tuesday 16 August 2016 at 09:17
To: "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>"
Subject: [Openid-specs-mobile-profile] Alternative account porting design


Attached is an alternative technical design to support porting between OPs.

  OpenID Connect Account Porting

  Abstract: This document specifies mechanisms to support a user porting from
  one OpenID Connect Provider to another, such that relying parties can
 automatically recognize and verify the change.

It requires an RP to make an API call to the Old OP to confirm a port, instead of handling an extra JWT signed by the Old OP.

It use a port_token (per user per RP) to link a porting event across interactions from the Old OP to the New OP, then to the RP, then back to the Old OP. A port_token is opaque to the New OP and RP so it could be a structured value (such as a JWT) if desired by the Old OP to minimize state in an implementation; otherwise a 256-bit base64url-encoded random value referencing the porting state will do.

It does NOT require an OAuth 2.0 dance by the RP to confirm a port. It assumes the port_token acts like a capability (not unlike a bearer access token).

It uses Sector Ids to identify (groups of related) RPs.

It supports chaining of multiple ports if required.

The Security Considerations are copied unchanged from draft-account-migration-02.

Annex A is an example in the form of a sequence diagram (embedded with a data: URL).

It does require that an Old OP remains available until RPs have confirmed ports (which could be months later). However, those responses could be implemented with a static web site if required so I do think this need be an onerous burden or risk.

[1] Torsten’s current draft design using JWTs: http://openid.net/wordpress-content/uploads/2016/08/draft-account-migration-02.html

James Manger


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160817/71be810a/attachment.html>

More information about the Openid-specs-mobile-profile mailing list