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

[Manger, James]

> So I have been putting thought into the Porting scenario. I agree with Torsten that RP/SP will always choose the lazy path and won't bother with calling a porting endpoint. 

Are you suggesting an id_token MUST NOT include sub1 in the clear as it will be too tempting to skip the necessary security check? (this is the choice made in the current spec)
Or are you suggesting an id_token MUST include a protected version of sub1 as RPs will not implement the protocol at all if they need to make another API call?

> When sub1 on mno1 ports to sub2 on mno2 then the RP/SP will be getting an ID token containing an AKA.  I also like the idea that the RP has everything within the id_token. My suggestion (in combination with brainstorming with Shahram) is that the AKA should contain an encrypted version of the old sub.
> The RP can use the JWK encryption public key from MNO1 to decrypt the old subject.

Decryption needs a private key, not a public key.

>   This would give the RP confirmation that MNO1 consented to the port out. 
> The only other variation I have not figured out yet is a better method to have mno1 explicitly say the user ported TO mno2.

> {
>   Sub:sub2
>   Aka:
>       Mno1:
>       Old_sub:{encrypted sub1}
> } 


There can be designs where the id_token from mno2 contains a protected blob containing sub1. That protection needs mno1's signature (to be verified with mno1's public key) so the RP can confirm the port. That can be awkward for mno1 to provide to mno2 at the time of the port. It requires a signature per RP given sub1 can be a pairwise id. That implies that the data sent from mno1 to mno2 during a port, and that mno2 has to store, scales with the (potentially unlimited) number of RPs the user has ever signed-in to. It also implies that mno1 remembers all of a user's RPs. If, instead of a DB lookup for sub1 given an RP id, mno1 dynamically *derives* sub1 from the RP id, then mno1 might not even have a readily available list of all the user's RPs. This design also tells mno2 about all the RPs the user ever used in the past, even if the user has no intention of ever using an RP again, which is poor for privacy; though this could theoretically be addressed by mno1 asking the user which RPs to include in the port.

One alternative to avoid the RP-to-mno1 port_check_endpoint call might be for mno2 to make an equivalent call to mno1 then include the result in the id_token. That shifts a bit of privacy control from mno1 to mno2. This could allow some optimisations that would not affect the RP: mno1's per-user-per-RP signature could be collected by mno2 as the user logs into an RP after the port; or it could be collected at the time of porting, depending on the capabilities and arrangements between mno1 & mno2.

Note: To process a "self-contained" id_token from mno2 the RP may still need to call mno1 to get mno1's public key to verify the signed porting statement.

Note: If mno1's signatures confirming the port need to last from the time of the port until the time the user next logs into an RP (perhaps months later), then they probably need a revocation mechanism that basically implies an extra API call anyway.

--
James Manger


-----Original Message-----
From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Marcos Sanz
Sent: Tuesday, June 05, 2018 4:00 AM
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] Account porting within the same OP

Hi James,

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

if you ask me, this
a) is in scope of openid-connect-account-porting-1_0,
b) would be a pretty easy addendum to section 5,
c) makes the standards more unclear/confusing if it'd become a separate 
spec (I am still confused by the trilogy session-management/frontchannel 
logout/backchannel logout).

How to move along? Do we want to talk about it during next Tuesday's 
telco?

Best,
Marcos

> 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. 
> 
> 
> 

_______________________________________________
Openid-specs-mobile-profile mailing list
Openid-specs-mobile-profile at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile