[Openid-specs-mobile-profile] Account porting within the same OP

[Manger, James]

Hi Torsten,

While Marcos has quite a simple use case (OP wants to use a different sub for its user), you have quite a complex use case (a central authority vouches for a change from Old OP to New OP).

A solution for Marcos (same OP, diff sub) is fairly easy: just include the old sub(s) in the id_token. The main issues are syntax and process.
Should the id_token become:
  { "sub":"new789", ..., "subs": ["old123", "old456"] }
Or
  { "sub":"new789", ..., "aka": {"subs": ["old123", "old456"]} }
Or
  { "sub":"new789", ..., "old": [ { "sub":"old123", "remove":true}, { "sub":"old456", "remove":false } ] }
Should it be specified in openid-connect-account-porting-1_0, or a separate (quite short and simple) spec?

One option for the "Old OP no longer exists" use case could be for the New OP to take over the Old OP domain name.
RPs process id_tokens as per Account Porting. RPs don't know, nor need to know, that the Old OP has been completely replaced. The New OP needs to host a static openid-configuration file at the Old OP's domain (https://oldop.example.net/.well-known/openid-configuration), though the 
"port_check_endpoint" can point to a New OP domain. That endpoint probably needs to support RP credentials established with the Old OP.
No spec changes are needed.

--
James Manger

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net] 
Sent: Saturday, 2 June 2018 12:29 AM
To: Manger, James <James.H.Manger at team.telstra.com>
Cc: Marcos Sanz <sanz at denic.de>; openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] Account porting within the same OP

Hi James,

> Am 01.06.2018 um 09:04 schrieb Manger, James <James.H.Manger at team.telstra.com>:
> 
> it will be too tempting for a developer to just use it without checking with Old OP.

I agree, this is a serious risk. 

I nevertheless support this additional feature. I have a porting case where the old IDP no longer exists when the actual porting with the RP takes place. Instead another IDP takes responsibility for ALL user accounts of the old IDP. This also allows to migrate all user data to the new IDP in a chunk before the old IDP is turned off. 

In our case, the new IDP must tell the RP the old sub and iss values. We prevent account take over by having a central authority, which tells the RP what IDP „officially“ took over for the old IDP. 

kind regards,
Torsten.