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

[Manger, James]

That's a reasonable extension, Arne, if there are OPs that are unable (or unwilling?) to enumerate RPs.


Minor technical details: I'd suggest returning the same JSON structure {"pairwise":{...}}, just filtered to only include the selected RP(s); and define a "more":true top-level member to indicate that not all RPs are enumerated but can be queried.

--
James Manger


-----Original Message-----
From: Arne Georg Gleditsch [mailto:argggh at telenordigital.com] 
Sent: Tuesday, 23 August 2016 3:57 PM
To: Manger, James <James.H.Manger at team.telstra.com>
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] Alternative account porting design

"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)?

Regards,

-- 

							Arne.