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

Arne Georg Gleditsch argggh at telenordigital.com
Tue Aug 23 05:56:54 UTC 2016

"Manger, James" <James.H.Manger at team.telstra.com> writes:
> Attached is an alternative technical design to support porting between OPs.

We touched upon this briefly in the Mobile Connect call yesterday, and
one attractive property of requiring the old OP to hold on to a minimum
of user data also after the user has ported out is that we could also
rearrange the information flow slightly so that port_tokens are
exchanged between the old and new OP on-demand.  The transaction in
section 3 James' proposal could then go something like this

  GET /connect/port_data/me?sector_identifier=rp.example.org
  Host: oldop.example.net
  Authorization: Bearer E3yyDiR5_i8CFCVDo3h8T5qgKpAdu8XkGZBv81vn428

  HTTP/1.1 200 OK
  Content-Type: application/json

    "port_token": "3O9YHawMDXLpKb-FVjQ1_qSS9R9wbwb0TWbUxLvqAAI",
    "extra_stuff": 34

This would enable OPs that generate subject ids algorithmically based on
user identity and sector id (and thus may not be able to enumerate all
sector ids it has handed out subject ids for at migration time) to still
supply accurate port_tokens.  The new OP would need to hold on to
access_tokens and refresh_tokens for the port_data endpoint for an
extensive period of time, but that should not really be a problem.

I am not sure if this is functionality that is useful; it would be
instructive to know if any of the parties participating in the
discussion here are actually unable to exhaustively enumerate the set of
sector ids and subject ids supplied for a given user.  I.e do they today
generate subject ids that are algorithmically derived from (some part of)
the user identity and the sector id (without recording the sector id)?




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