[Openid-specs-mobile-profile] Account Migration - move vs. link

philippe.clement at orange.com philippe.clement at orange.com
Thu Nov 17 17:26:05 UTC 2016


Hi James,
This seems reasonable to me, thanks
Regards,
philippe

De : Manger, James [mailto:James.H.Manger at team.telstra.com]
Envoyé : dimanche 13 novembre 2016 13:59
À : CLEMENT Philippe IMT TECHNO; Torsten.Lodderstedt at telekom.de; openid-specs-mobile-profile at lists.openid.net
Objet : RE: Account Migration - move vs. link

Hi Philippe & Torsten,

draft-account-porting<https://id.cto.telstra.com/2016/openid/draft-account-porting.html> now supports moving and linking.

In this draft, in the Porting check API response to an RP the Old OP MUST include either:
  "remove": true (for the "move" case - the user will now only login via the New OP so the RP MUST remove the Old OP)
or
  "remove": false (for the "link" case - the user can use New OP or Old OP so the RP SHOULD keep both)

I think "remove" is better than "disabled", despite sounding like it encroaches on the RP's sovereignty. In fact, I think it is reasonable that part of an RP saying it supports porting is that it MUST support this "remove":true signal to cuts ties to the Old OP for this user (ie the Old OP can no longer login as the user to this RP). Users should be able to expect that a move has severed the Old OP's access once they have successfully logged in via the New OP.
For the "link" case ("remove": false) the draft only says the RP "SHOULD" support both Old & New. It doesn't feel totally unreasonable that an RP might only be able to support 1 OP for a user; or even have a policy against multiple OPs per user.

I can (just) imagine a few corner cases where a user ports to a New OP, but only for some RPs. In that case, "remove" feels a bit more accurate than "disabled": the user's account at the Old OP has not been disabled (for all RPs), but this particular RP should remove the link.

I couldn't decide if true or false should be the default if "remove" was absent so the draft says "remove" MUST be present.

--
James Manger

From: philippe.clement at orange.com<mailto:philippe.clement at orange.com> [mailto:philippe.clement at orange.com]
Sent: Monday, 24 October 2016 9:06 PM
To: Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>; Manger, James <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>>; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Subject: RE: Account Migration - move vs. link

Dear James, Torsten,

I'm totally in line with the proposal.
I have a preference for "disabled" rather than "remove":

-       "Disabled" reflects the exact status of the account at old OP, and let to the RP the decision to take regarding the user account it has on the old OP. Likely it will remove all traces of account

-       "remove" describes rather a directive of the old OP  to the RP regarding the account that RP had created for user, and could not seem "convenient" in the sovereignty of the RP regarding things it generates on its side

My 2 cents

Best regards,
Philippe

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é : lundi 24 octobre 2016 11:15
À : James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Objet : Re: [Openid-specs-mobile-profile] Account Migration - move vs. link

Hi James,

+1 for your proposal

I didn't see any further response to the list. So I think we shall go with your proposal.

best regards,
Torsten.

Von: Manger, James [mailto:James.H.Manger at team.telstra.com]
Gesendet: Freitag, 7. Oktober 2016 02:30
An: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Cc: argggh at telenordigital.com<mailto:argggh at telenordigital.com>
Betreff: RE: Account Migration - move vs. link

*         > Shall the spec also support "link"?
Yes.
*         > If so, who decides whether an account is moved or linked?
The Old OP should tell each RP (if it knows).

The Old OP could ask the user (eg during the OAuth consent flow to give a New OP access to porting data), but that seems more of an internal issue for the Old OP. The externally visible part is a signal to RPs.

Suggestion: define a "disabled" member that can be included (alongside "sub") in a response to an RP's call to an Old OP's Porting check API.

"disabled": true - means this account is now disabled at the Old OP; the RP shouldn't expect (so shouldn't accept) any further login for this user via the Old OP so it can remove {Old OP/sub} from this user's account at the RP.

"disabled": false - means this account is still active at the Old OP; the Old OP expects the user to continue logging in from the Old OP; the RP should continue to accept logins via the Old OP. This "porting" event is linking identities from the Old OP and New OP without deprecating either. The RP should accept both as valid login mechanisms for the user.

"disabled" absent - means the Old OP isn't committing either way; or perhaps we make one choice the default so absence means that.

Bike shedding:
Instead of "disabled": true/false, how about "remove": true/false? That makes it clearer that it is asking the RP to do something.

--
James Manger

From: Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de> [mailto:Torsten.Lodderstedt at telekom.de]
Sent: Thursday, 6 October 2016 5:28 PM
To: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Cc: Manger, James <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>>; argggh at telenordigital.com<mailto:argggh at telenordigital.com>
Subject: Account Migration - move vs. link

Hi all,

in Paris we had an extensive discussion about the semantics of the migration. We came up with the consensus that there two use cases move and link:
*         Move: all federated ids of a OP account (or parts of it, e.g. the "Mobile Connect" account) are moved to the new OP and deleted at the old OP. The user won't be able to login to the respective RPs with the old OP account afterwards (except it registers again with the RPs). The lifecycle of the OP account is left at the discretion of the old OP.
*         Link: all federated ids of a OP account (or parts of it, e.g. the "Mobile Connect" account) are _copied_ to the new OP. So the user will be able to login to the respective RPs with both OP accounts, at the old and the new OP.

We learned the Mobile Connect expectation is that the Mobile Connect portion of the old OP account is deleted during (or as result of) the migration. So our spec needs to support this use case.

The following questions are still not yet decided:
*         Shall the spec also support "link"?
*         If so, who decides whether an account is moved or linked?

Please state your opinion on this topic within the next week so we can come to a consensus about this topic.

Thanks in advance,
Torsten.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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


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