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

Torsten Lodderstedt torsten at lodderstedt.net
Tue Aug 23 14:24:09 UTC 2016


Hi James,

I just assigned you write permission on the repo, so you can upload your 
draft.

best regards,
Torsten.

Am 23.08.2016 um 14:58 schrieb 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 26^th 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
>
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> 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/20160823/8a7ef36f/attachment-0001.html>


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