When talking about Bug 1022678 this question arrive. What happend to people already having valid sessionTokens for a number and they change their number and somebody else takes it. We could have people receiving call from a number they don't own anymore. Also the client can handle that.

Any thought about that? Should we add an endpoint to drop all MSISDN related sessionToken?

I think we need a mechanism on the client side to revoke a number. Not sure what should be the UX story there... ferjm? So yeah, in any case, on the server side it sounds like a good idea to be able to wipe all the data related to a given MSISDN (if you own it)

Argh... this is a tricky scenario... (In reply to Rémy Hubscher (:natim) from comment #0) > When talking about Bug 1022678 this question arrive. > > What happend to people already having valid sessionTokens for a number and > they change their number and somebody else takes it. > > We could have people receiving call from a number they don't own anymore. > > Also the client can handle that. The client can notice a SIM change, but we are not deleting the session token in that case. We are only asking to the user what to do in that case and only if the API consumer requests a new assertion. If the user wants to keep using her old phone number, she can do it. And anyway that wouldn't work for external phone numbers. For Loop, I believe the problem here is only when a new user registers in Loop with a phone number that used to belong to another user that happens to also be a Loop user and keeps her login with her old phone number ( ... which of course is not an edge case... :D ). To solve this scenario, I think we might need a session token revocation mechanism. I am thinking about something like: 1. The clients need to provide an UUID per device. 2. When the server generates and stores the session token associated to a specific phone number, it should also store and associate the UUID provided by the client. 3. Every time a /sign request is done, the client will also provide its UUID. 4. The server needs to check if this is the first time that the client with the given UUID is trying to get a signed certificate for that phone number. 5. If that is the case, we will generate a new session token for that client and will revoke all the other session tokens associated with that phone number, so the clients holding these session tokens will be required to repeat the verification. And because the user holding the login with the old phone number no longer has that phone number, the verification process won't be possible for her. But this might not be enough for other consumers, like a payment provider for instance. Let's say that a payment provider charges the user via her operator bill, the user changes her phone number and another user is given that phone number. In that case, we shouldn't allow the old phone number owner to keep using that number to make payments as this charges will be done to the new owner of that phone number. So we probably need a way to allow consumers of this API to tell us that they don't want to allow SIM changes (which implies also not allowing external phone numbers) and if we detect a SIM change in that case, we should remove the session token.

The above token revocation proposal assumes that the server is storing a session token <-> phone number relation.

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #3) > > 5. If that is the case, we will generate a new session token for that client > and will revoke all the other session tokens associated with that phone > number, so the clients holding these session tokens will be required to > repeat the verification. And because the user holding the login with the old > phone number no longer has that phone number, the verification process won't > be possible for her. > An alternative to automatically revoking the session token would be to notify the user about her mobile identity being used in another device. This would require more changes in the server though and we would need to relay on SimplePush notifications for this, but I believe the UX would be much better.

We could also return this information with the certificate so we will not need a Simple Push url. I like this idea. So the plan I propose is: - Add a /unregister/all number endpoint from a validated certificate - Add a information on /certificate/sign with a boolean for already existing tokens or not Then if the client want to handle that it can.

(In reply to Rémy Hubscher (:natim) from comment #6) > We could also return this information with the certificate so we will not > need a Simple Push url. > That means that the user won't notice that her old phone number is being used in other device until she uses an app that asks for a mobile ID assertion. > I like this idea. > > So the plan I propose is: > > - Add a /unregister/all number endpoint from a validated certificate I guess this one would wipe all the session tokens associated to that number except the one used to make this call. > - Add a information on /certificate/sign with a boolean for already > existing tokens or not > If we do the SimplePush solution we won't need this change. Also from the proposal at comment 3 other API changes are the addition of the client UUID in the /register and in the /certificate/sign calls. Chris, does this proposal make sense for you?

> I guess this one would wipe all the session tokens associated to that number except the one used to make this call. Yes exactly. > Also from the proposal at comment 3 other API changes are the addition of the client UUID in the /register and in the /certificate/sign calls. Yes I think we can have both flow and let the client decide.

Hmm didn't we talk about this also on the bug about the expiration time of the tokens? That's Bug 1022678. On comment 5 there, what I was suggesting was: > I think that we could: > * give this as an option (when registering a new device for a number that already has a device > registered, ask the user if he wants to unregister the other devices or not) > * Automatically call /unregister on a device when the iccID of the SIM that was present when > the registration was done changes. > Note that this is an inclusive or (we can do one, the other, or preferably both :)). The first bullet was, precisely, to deal with MSISDN ownership changes. When the *new* owner of the MSISDN registers it's MSISDN the client (OS, not Loop!) tells him that "Your phone number is already being used on other device(s). Would you like to remove your number from all the other devices now?" (wording pending :P). And if he says yes then we call unregister/all. This doesn't need SimplePush, it just needs the server informing the client of any other possible devices at registration time. Of course, that leaves two problems: * Payments... I don't think this can be fixed here, and I don't think this is even a problem that belongs here. If payments can be done without a recent proof of ownership and authorization, that's a security problem of the payment provider. By the way, if the payment provider is the operator (and it should if he's doing direct charges on the associated phone account) he should know of any ownership change on the MSISDN and check that against the proof of ownership age. * What if the new owner of the MSISDN doesn't ever register his number with us? (or what if he doesn't even get a Firefox phone?). And... unfortunately I can only think of two solutions for that. One isn't very palatable, and the other one costs money. The first one is just let it self-regulate. In other words, do nothing and just hope that the original owner will deregister his old number/stop using it at some point. And just for reference, I know some people that are still using Whatsapp with their old number after they released/stopped paying for it. So long as the new user doesn't use it, the worst problem is that he might get some messages addressed to the new owner. The second one costs money as I said, and it's just send a periodic reminder via SMS of the devices registered with that MSISDN: "Hey there, we would like to let you know that your number 123456789 is currently registered on three devices. If you want to revoke the authorization from those devices, press on this nice OTP link: http://will.unlink.all/nice/otp/here" Actually there's a third possible solution, but it requires the collaboration of the operators (if they publish a MSISDN status change list we can use that to revoke authorizations).

> Actually there's a third possible solution, but it requires the collaboration of the operators (if they publish a MSISDN status change list we can use that to revoke authorizations). Nexmo is already able to provide us this kind of information with their API. > * give this as an option (when registering a new device for a number that already has a device > registered, ask the user if he wants to unregister the other devices or not) From a UX point of view we don't want to ask every user at looging. But it could be an option if it was only when it happens to have already registered phones for that number. > What if the new owner of the MSISDN doesn't ever register his number with us? (or what if he doesn't even get a Firefox phone?). And... unfortunately I can only think of two solutions for that. One isn't very palatable, and the other one costs money. If the user is still using an old number that nobody else uses it may not be a problem?

It's unclear to me, whether are discussing revocation of sessionTokens for the MSISDN verification API or sessionTokens for the Loop server. In https://bugzilla.mozilla.org/show_bug.cgi?id=1022678, several people had convinced me that the MSISDN verification API should not directly address revocation. It should allow multiple valid sessionTokens for the same MSISDN. The reason is the the MSISDN verification API could be relied on by multiple services, and a single MSISDN owner could be using those services. Enforcing a strict revocation policy in this case could create frustrating UX, requiring frequent re-verification (I believe both ferjm and antonio pointed this out). This implies that relying services must decide on their own policies for whether a single MSISDN can be associated with multiple (application) sessions. For Loop this probably means whether a single MSISDN can be associated with multiple push URLs. The simplest answer to this question in the FxA-less/MSISDN-verification-only world is "no", the last verifier wins (as Antonio says, "Whats app" style). I.e., there is only a single push URL ever associated with a MSISDN in the Loop server, and it's the client that has provided the most recent "verifiedAt" time in the certificate backing their assertion. My opinion is to do the above simple thing for this version of the product, but ultimately, this is a product and UX question. FWIW, I recognize the use case of an MSISDN being associated with multiple devices, but to achieve this, I argue we should require login via FxA. When we support "MSISDN as a property of your account", then we can easily handle this case. Because the user has logged in, we can safely "ring" all her devices associated with account/MSISDN. (Of course, we'll still need revocation policies in that world, but I'll defer that discussion.) (:ferjm, I didn't really address your proposal directly, but I believe the MSISDN sessionToken and the principal in the certificate can both serve as a device identifier, depending on which service needs it.)

There we are talking about MSISDN sessionTokens. But I start to understand your point. You don't want the MSISDN server to manage tokens or linked devices. You want to let the Loop server or any other application to handle this on an application basis. That makes sense for many reason: - We don't want to be logged out from the marketplace by logging to the Loop client and revoking all the tokens. So the conclusion is that we cannot revoke any tokens remotely from the MSISDN Gateway. You can only unregister a token and that's it. Loop can add a device manager to handle its devices tokens. The bias here is that even if loop drop all device tokens, the user can still ask a new Hawk token using a validated MSISDN. To address this, we should store the last Loop device token cleanup date and check if the certificate lastVerifiedDate is younger than the last revocation date. It makes sense. thanks.