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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Aug 24 10:56:07 UTC 2016

Hi James,

Am 24.08.2016 um 01:16 schrieb Manger, James:
> A single porting token from the Old OP to the New OP would be nice.
> I don’t think we can simply send that one token in “aka” to every RP 
> in step 2b below because it defeats the reason for using pairwise 
> subject ids. It would enable any pair of RPs to correlate a user’s 
> accounts.

You are right - I oversaw this consequence.

> Perhaps a slight variant could work:
> 2b) the New OP adds to the id_token an "aka" member identifying the 
> Old OP and holding an encrypted version of the port_token. The 
> port_token is encrypted with the Old OP’s public key (or possibly a 
> symmetric key shared by Old & New OPs). The encryption needs to be 
> performed separately for each RP with a per-RP nonce. (Formatted as a 
> JWE I guess.)
> This way each RP sees a different encrypted_port_token that 
> (hopefully) cannot be correlated to those seen by other RPs. (An Old 
> OP might need to be careful that port_tokens are all the same length 
> so ciphertext length cannot be used as a correlation handle).
> The Old RP can decrypt the port_token then proceed as below.
> One downside of the Old OP not indicating known RPs for a specific 
> user to the New OP is that the New OP has to send the 
> encrypted_port_token to every RP. Every RP will check with the Old OP 
> (except an RP that knows it has no users using that Old OP). 
> Consequently the Old OP learns about new RPs that the user starts 
> using after they ported, which is a bit unfortunate. The New OP could 
> ask the user (with a checkbox on a login/consent page) if he or she 
> already has an account at a given RP federated from the Old OP, but 
> that isn’t too appealing.

I think this is a reasonable solution (and potentially the only one).

I think even the old OP cannot always decide whether it asserted a 
certain account to a particular RP. So we somehow need to account for 
this uncertainity. In my draft, the old OP would use the public subject 
(if available). In your proposal, the old OP can decide (based on RP 
policy, user data, user consent...., whatever logic it wants to apply) 
if and what subject to assert.

best regards,

> --
> James Manger
> *From:*Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
> *Sent:* Wednesday, 24 August 2016 1:21 AM
> *To:* Manger, James <James.H.Manger at team.telstra.com>; 
> openid-specs-mobile-profile at lists.openid.net
> *Subject:* Re: [Openid-specs-mobile-profile] Alternative account 
> porting design
> Hi James,
> thanks for writing down your proposal.
> One question directly popped up in my mind: Why does the old OP issue 
> per RP/sector id porting tokens? This requires the new OP to correctly 
> co-relate RPs and the corresponding porting tokens (which in turn 
> seems to correspond to particular subject values). Identifying RPs is 
> one of the open issues of my draft and it retains an open issue in 
> your draft as well. It won't reliably work for native apps (and in the 
> end break encapsulation of the old OP). Your design has the potential 
> to deal with it by just letting the old OP do this part of the job.
> Let me explain how:
> I personally think a single porting token representing the old OP 
> account should suffice. Everything else can be done by the old OP 
> using the data/credentials at hand (because the RP is also known to 
> the old OP!).
> 1) old OP issues a single porting token (related to the ported OP 
> account) to the new OP
> 2) the new OP stores this porting token (along with the iss value of 
> the old OP) with its corresponding OP account
> 2b) new OP adds "aka" (I like that name :-)) to the ID token with 
> every login response for such an account
> 3) RP sends request to porting check API at the old OP, including the 
> porting token + the credentials it regularily uses to 
> identify/authenticate with the tokens endpoint of this particular OP 
> (it must have an identity with this OP as it is a RP for this OP as well)
> 4) the old OP applies the same logic as for a regular login request, 
> i.e. it authenticates the RP and determines the appropriate subject 
> value (based on its RP-specific policy and other data)
> 5) the old OP returns this subject value (public or pairwise) to the RP
> 6) RP uses the subject value to find local account
> Benefit: the old OP is able to determine the RP's identity and the 
> correct subject value. Moreover, it stays in full control of which 
> data is handed of to what RP. The new OP does not need to know 
> anything about the different local accounts associated with the ported 
> OP account.
> What do you think?
> best regards,
> Torsten.
> Am 16.08.2016 um 09:17 schrieb Manger, James:
>     Hi MODRNA,
>     Attached is an alternative technical design to support porting
>     between OPs.
>       OpenID Connect Account Porting
>       draft-account-porting-00
>       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
>     _______________________________________________
>     Openid-specs-mobile-profile mailing list
>     Openid-specs-mobile-profile at lists.openid.net
>     <mailto:Openid-specs-mobile-profile at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160824/2f4875ab/attachment-0001.html>

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