[Openid-specs-mobile-profile] Preliminary minutes of MODRNA WG Call on August 10th 2016

[Manger, James]

Hi Philippe,

My alternative porting proposal is quite different from the flow you list. See my 16 Aug email<http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20160815/000512.html> and attached draft spec<http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160816/17846b84/attachment-0003.html>. It involves OP2 getting per-RP porting info from OP1, including it when the user next logs into the RP (this time via OP2), and the RP confirming the port with an API call to OP1.

A useful feature of your flow below is that it considers the cached info an RP has about a user's old OP (OP1) and how this interacts with the porting process. Neither draft-account-porting-00 (mine) nor draft-account-migration-02 (Torsten's) consider that; they silently assume that authentication with OP2 occurs after any error from being "mistakenly" redirected to OP1 after the port.

I don't think the flow below works.
At step 8 OP1 hasn't authenticated the user so it cannot send the RP "all the necessary subject values".
Even if OP1 does authenticate the user at step 8, this flow isn't great as it requires the user to login to OP1 (at step 8) and login to OP2 (at step 11) for every RP. The main value of a porting process was to leverage a single dual-login event to be able to inform every RP; not to have to repeat a dual-login for every RP.

The flow doesn't seem to work when the RP no longer has a cached secure hint for a user (eg cleared cookies or new device). The RP starts with discovery (step 9) so it never learns about OP1.


P.S. Can I (or someone else) upload draft-account-porting-00 to the group's bitbucket so it can be viewed properly, instead of seeing the raw HTML that the email archive delivers?

--
James Manger


From: philippe.clement at orange.com [mailto:philippe.clement at orange.com]
Sent: Tuesday, 23 August 2016 7:21 PM
To: openid-specs-mobile-profile at lists.openid.net; Manger, James <James.H.Manger at team.telstra.com>
Cc: Torsten.Lodderstedt at telekom.de; philippe.clement.ft at gmail.com
Subject: RE: [Openid-specs-mobile-profile] Preliminary minutes of MODRNA WG Call on August 10th 2016

Dear all,

Back from vacations today ...
James: regarding the alternative on Account Migration, it seems to me that this has something to do with the proposal of an alternative flow that I presented on July 26th on the list (copy below). Could you confirm ?

Best regards,
Philippe



Prerequisite:

1-    User had an account on a previous MNO (OP1)

2-    User's account on OP1 is closed

3-    User has an account on a new MNO (OP2)

4-    Eventually, OP1 knows that user has migrated to OP2

5-    RP knows former MNO (OP1)
Use Case:

6-    User visits his usual RP and starts authentication to access the service

7-    RP starts the OIDC flow with OP1 with usual secured hints regarding the user

8-    OP1 answer's with an error code "account migrated" and sends back to the RP all the necessary subject values. If OP1 knows what OP user has migrated to, it is inserted in the answer

9-    RP interacts with the user to get his new OP (discovery process), unless RP already knows what OP user has migrated to.

10- RP starts the authentication process with OP2

11- According to the success of authentication on OP2, RP migrates subject values for his RP's account

This Use case would take place in one shot, at the moment where user needs to authenticate at RP to get the service, so it would be very efficient in terms of migration
It minimizes the situation of cascading OPs
It avoids to install a dialog between OP1 and OP2 and privacy concerns regarding transfer of personal information from OP1 to OP2.
Then it avoids some situations where user will not start the migration process by accessing a specific service to be developped on OP2.
It avoids limitations in Authorization Grant lifetime.



De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>
Envoyé : jeudi 11 août 2016 12:16
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Objet : [Openid-specs-mobile-profile] Preliminary minutes of MODRNA WG Call on August 10th 2016

·         ...
2.       Account migration
·         James Manger explained an alternative proposal for handling of migration data. The basic idea is to instead of transferring it via a signed JWT, the old OP exposes an endpoint where the RP can directly call and determine whether and where a particular account has been migrated to
·         The RP should be able to authenticate with the old OP since it is a RP of this OP as well (since it uses the old OP for logins)
·         pro: no issue regarding signing key expiration
·         James will post a more detailed description on the list so we can have a discussion of which way to go


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