MSISDN as discovery parameter?
Issue #23
resolved
Sebastian's comment on the current discovery design: I also think we should add msisdn as optional parameter to both, user interaction endpoint and issuer endpoint. For the POST based flow because the app may already have the permission to query the msisdn from the device and then the user experience can be enhanced. See also Johns comment on https://bitbucket.org/openid/mobile/issues/6/general-questions For the redirect based flow, because the RP may already know the msisdn and only wants a secure attestation for it. I know that mobile connect is aware of privacy and designed not to tell every RP the msisdn. But I'm sure that for some RPs this will become a valid use case and then the usability can be improved. The Discovery Service may deny the request if the client is not authorized to discover the mno by msisdn.
Comments (5)
-
reporter
-
The use of the MSISDN as a hint, should help onboard global legacy Service Provider to Mobile Connect. MSISDN based Service Provider will be able to gradually convert their Customer Data Bases from the MSISDN to the PPID identifier returned by the ID_Token. They should find value in using the PPID since it should have a longer life-cycle independent from SIM or MSISDN change.
-
reporter
Hi Matthieu,
good point. Does this also mean we need to find a way to pass a PPID as login hint to the OP? This is something we came across while discussing re-login use cases in the German trial.
best regards, Torsten.
-
reporter
Decision in the WG call: add the MSISDN to the discovery service
-
reporter
- changed status to resolved
added parameter and additional explanation regarding authorization
- Log in to comment
Philippe's comment: I think that in some cases, the RP will have this MSISDN, and that this one will be secured at the RP by a real secured process (challenge with a phone call, confirmation by OTP...). Case of banks for example, but they are not alone. As this MSISDN at RP exist, we should use it to simplify the user journey at the discovery stage and not risk to re-ask to the user some information regarding his MNO. Indeed, in some cases, the discovery service will have, in absence of user/MNO data, to ask to the user pieces of information (MSISDN, MCC/MNC...). This could be added in § 2.1 C : "Moreover, the client may pass MCC, MNC or IMSI as part of the discovery request."