Closed Bug 832215 Opened 11 years ago Closed 6 years ago

Verified, MSISDN-based identity auth app flow

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-b2g -

People

(Reporter: kamituel, Unassigned)

Details

(Keywords: feature, Whiteboard: [triaged:1/22]) 

We need to allow certain apps to be able to authenticate themselves using SIM's MSISDN (see note below regarding privacy) as an identity.  Specific requirements are:
1. App is able to obtain MSISDN of the SIM card.
2. App is able to use  this MSISDN to authenticate itself against backend.
3. Backend is able to verify that MSISDN received is valid and indeed is associated with SIM present in app's device.

We can decompose this problem into two layers:
1. Getting the correct, trusted value of MSISDN (and additional auth tokens).
2. Exposing this information to the apps.

Lower layer (getting the correct, trusted value of MSISDN):
- mozMobileConnection in the current form cannot be used, because it relies on MSISDN value stored on the SIM card. This value is often null, because many SIM cards does not have MSISDN file present.
- it can be done by Gecko sending SMS to a trusted party able to establish user's identity (ex. carrier). This party would than response with another SMS containing valid MSISDN and token (T).
- it can also be done by forcing device to switch to carrier's data connection, not WLAN, and then performing authentication (by mapping IP address to MSISDN). As soon as this is performed, device could return to using WLAN connection if desired.

Upper layer (exposing identity to the apps) can be done as follows:
- via some kind of Web API (extending mozMobileConnection, or something new). MSISDN and token should be exposed. 
- by using Persona, although it is not clear how it could be done. Any suggestions?

Privacy:
- identity information should be available to preinstalled (certified) apps, but also to apps which will be installed by user during normal device usage. Does this mean that this API should be available to non-certified apps also?
- if privacy concerns would be stopping us from exposing MSISDN, we can consider using some kind of unique identifier mapped to MSISDN by carrier's backend. This approach is not described above, although seems to be viable option.
I wonder if Ben Adida would have any thoughts on something like this. Hmm...
Yes, this is something we spent a long time working on with carriers, and so far there is no reasonable way for us to get a verified value of the MSISDN that can be passed to apps.

In addition, I suggest we look carefully at the use case and see what the user experience would be. In what exact case would this be something that the user agrees to? (Not saying there aren't any, just that we need to understand exactly what they are for prioritization.)
blocking-b2g: --- → shira?
One problem in particular here is how can the app (and by extension the server that the app is authenticating to) trust the value that we are getting from the simcard?

Does the simcard support any challange/response type protocols?
(In reply to Jonas Sicking (:sicking) from comment #3)
> One problem in particular here is how can the app (and by extension the
> server that the app is authenticating to) trust the value that we are
> getting from the simcard?
> 
> Does the simcard support any challange/response type protocols?

That's exactly the problem I was referring to.

As best as I can tell, SIM authentication is only useful to authenticate to the network. Then, carriers use this network authentication to bootstrap other processes.

So, briefly: I don't know of a way for the simcard to attest to the phone # in a way that can be independently verified. In addition, this is a heavily regulated area, so even if it were possible, we have big privacy complexities. That's why the identity solution for FXOS v1 does not use phone numbers.
> In addition, I suggest we look carefully at the use case and see what the
> user experience would be. In what exact case would this be something that
> the user agrees to? (Not saying there aren't any, just that we need to
> understand exactly what they are for prioritization.)

Ben, I’ve briefly noted several usecases we had already stumbled upon when developing apps for other platforms (iOS, Android mostly):
- selfcare app for our customers. 
- music store 
- etc.
Basically most of our apps need to authenticate, and from end user’s perspective the best way to do this is the simplest way. Since we have an opportunity not to relay on any passwords, we are using it whenever possible; we’d like to do this on FxOS as well.

Right now we’re doing it in basically three ways:
1. Displaying input to the user, where he puts his MSISDN. We then send him a SMS with some token, and he is putting this token into the app to authenticate (iOS) or incoming SMS is being caught by the app itself (Android).
2. Sending SMS with some token by the app, on example with GCM (Google Cloud Messaging) token. Server then uses this token to send final credentials.
3. Forcing device to switch to 3G and then performing auth using IP -> MSISDN mapping.

We want to have one solution implemented on OS level to get it right across all apps.

It is fairly obvious that user should agree on this, so this API should be permission-protected in an explicit way.
Triage: leo? shira is to be as close to tef as possible. this seems like a major feature request
blocking-b2g: shira? → leo?
Whiteboard: [triaged:1/22]
It looks like a feature request to me. Chris, should we put this in any version of Firefox OS? Thanks.
Flags: needinfo?(clee)
(In reply to Kamil Leszczuk from comment #5)
> Ben, I’ve briefly noted several usecases we had already stumbled upon when
> developing apps for other platforms (iOS, Android mostly):
> - selfcare app for our customers. 

I can see this being useful, but this is a special case, as I'm guessing this is the carrier's app?

The other use cases:

> - music store 
> - etc.

from the UX and privacy reviews that we did, should use the Persona account that is set up when users visit the marketplace. There's no need (and in fact it makes little sense for users) to use a phone number as identity here.

> Basically most of our apps need to authenticate, and from end user’s
> perspective the best way to do this is the simplest way.

No disagreement there, just saying that using the phone # is not the simplest way. In particular, we were told by tef that the privacy laws are so strict that even the Persona account couldn't get the phone# from TEF, let alone individual apps. Also, from the user's point of view, our UX team confirms that logging in with a phone# makes little sense to users.

> We want to have one solution implemented on OS level to get it right across
> all apps.

I think we can work towards that, but there are a number of deep issues to resolve first. Longer term, this is probably an attribute of the Persona account that the carrier is certifying, and that apps can ask for. But it sounds like a 2.0 feature for sure.

> It is fairly obvious that user should agree on this, so this API should be
> permission-protected in an explicit way.

From what we were told, that's not enough, thus the need for a deeper review.
> I can see this being useful, but this is a special case, as I'm guessing
> this is the carrier's app?
> 

Usually it's a carrier app, but can also be an app from 3rd party.

> There's no need (and in
> fact it makes little sense for users) to use a phone number as identity here.

> No disagreement there, just saying that using the phone # is not the
> simplest way. 

I would say it's not the simplest way from our perspective, but we believe from end user's point of view it is the simplest way, as it could be done automatically and could allow users to use apps with no setup required.

> In particular, we were told by tef that the privacy laws are
> so strict that even the Persona account couldn't get the phone# from TEF,
> let alone individual apps. Also, from the user's point of view, our UX team
> confirms that logging in with a phone# makes little sense to users.
> 

Agree, privacy laws are a thing to always watch out. Our requirements can be solved using some other identifier, but it should be mapped to MSISDN on carrier's premises. 
In particular this solution seems to fit our needs: 
https://docs.google.com/document/d/13CZqSbOdf_W7Wb-r7cLFLA_XwdDNVT8T9LMLpul4iYs/edit?pli=1#. 
What is the status of this one?
(In reply to Kamil Leszczuk from comment #9)
> > I can see this being useful, but this is a special case, as I'm guessing
> > this is the carrier's app? 
> 
> Usually it's a carrier app, but can also be an app from 3rd party.

So, again to be clear: we have very strong UX evidence that users do not want to log in with a phone #. That's a high level of disclosure that is almost never necessary.

> > No disagreement there, just saying that using the phone # is not the
> > simplest way. 
> 
> I would say it's not the simplest way from our perspective, but we believe
> from end user's point of view it is the simplest way,

I don't think so. This is a high level of commitment. Remember that users will have a Persona account, which maps more closely to the disclosure users are accustomed to on the web (just an email address).

> In particular this solution seems to fit our needs: 
> https://docs.google.com/document/d/13CZqSbOdf_W7Wb-
> r7cLFLA_XwdDNVT8T9LMLpul4iYs/edit?pli=1#. 

That solution was not approved because of privacy issues. That's what I was referring to earlier. Even Mozilla cannot receive the user's phone number.

I suggest we lay out exact user stories before we make this a requirement. Every time we've looked at this (and we've done it a lot over the last year), this ends up not being a requirement or being too difficult from a privacy perspective that we find a different approach.
In Spain in particular, and I believe in Europe in general (although YMMV) the phone number is considered Personally Identifiable Information, and falls under the protection of the data protection laws. Thus, for the carrier (or any party that has that data) to pass that data to any other party there are some strict regulations. In short, it's a PITA, and generally not worth doing for something that doesn't strictly require that data to be exposed.

One use case on which that data could be seen as needed is Whatsapp, since the phone number isn't used only as identifier, but also as a way to automatically build your network of contacts. And even so, it could have been replaced with a dissociated identifier (an identifier that's not the phone number and from which the phone number cannot be obtained, but that's unique for each user). 

Giving dissociated identifiers to third parties is allowed by the Spanish legislation at least, without having to apply the Data Protection laws and regulations, according to the answer to a question we submitted to our Data Protection Office. But even so I'm not sure if giving the same dissociated answer for the same phone number always would be good enough to comply with the intent of the law (since you could use that to track/correlate users). 

If the user is the one that gives you the data (as in your example from c5), then it's a completely different issue. You would still need to comply with the data privacy laws if you're in Europe, but at least there's no sharing of private data (since the data belongs to the user and she gives it to you directly).
Ben, I think the best way to proceed now would be for me to update myself with information you have regarding this topic, so we're on the same page. It would be easier then to talk and not to repeat the same discussion you already had last year.

Can you share information you have, like previous discussions, notes etc? Especially the specific reasons why, on example, TEF's solution has been dropped. Possibly also UX feedback you mentioned - have you done user studies on this?

(one more thing regarding: for 3rd party apps you may be right it is not the most obvious thing for users to authenticate via MSISDN, but it's a different thing when it comes to using carrier apps).
As commented by Ben and explained by Antonio, regulations are tough with regard to disclosure of the MSISDN.

From Telefónica, what we can do is to provide an opaque id mapping to the MSISDN based on the IP address that we see from the device. We are already providing that for the payment flow (we give the opaque id to the payment aggregator). This opaqueId changes each time the procedure is launched, but we can configure to provide a second id which is always the same for a given MSISDN. This latter is configurable in order to tweak it according to the specific partner and other constraints.
Exactly, we can use what you call "opaque id". This is the idea I was talking about. Thanks to that, we can avoid storing MSISDN on device, Mozilla's or any 3rd party premises. Does this approach have any security issues?

David, can you share more details on how did you implement that? 

Ben, David, do you know if Persona supports this flow (with opaque id)? If so, is there any documentation for this?

I would really appreciate helping me be more up-to-date on this, thanks!
Leo-, seeing that there's no requirement in the 1.1 release for this so far. Kamil, we can work with Kev to figure out the right release to slot this into.
blocking-b2g: leo? → -
This seems like a new feature request.  Deferring to Sandip decide as part of backlog grooming.
Flags: needinfo?(clee) → needinfo?(skamat)
Whiteboard: [triaged:1/22] → [triaged:1/22][Feature]
Keywords: feature
Whiteboard: [triaged:1/22][Feature] → [triaged:1/22]
moving to backlog for now. Has anyone identified the components affected with this change? Is it RIL (+some other components)? Best to have it owned by the component with majority changes.
Flags: needinfo?(skamat) → needinfo?(kchang)
(In reply to Sandip Kamat from comment #17)
> with this change? Is it RIL (+some other components)?
It depends on the design for this bug. If we would like expose MSISDN, we should do something in RIL for this bug. But Major implementations of this bug is not in RIL, RIL seems not to be a appropriate component for this bug. By the way, there is no MSISDN in some sim cards. I wonder if it is a good way to use MSISDN.
Flags: needinfo?(kchang)
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.