G. Fernandez | |
Telefonica | |
F. Walter | |
A. Nennker | |
Deutsche Telekom AG | |
D. Tonge | |
Moneyhub | |
B. Hjelm | |
Verizon | |
April 30, 2020 |
MODRNA: Client Initiated Backchannel Authentication Profile 1.0 draft-03
openid-connect-modrna-client-initiated-backchannel-authentication-profile-03
OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core] is an authentication flow like OpenID Connect but with a direct Relying Party to OpenID Provider communication without redirects through the user's browser. The MODRNA Client Initiated Backchannel Authentication (CIBA) Profile is a profile of OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core] to be used when requesting authentication from Mobile Network Operators (MNOs).
OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core] is an authentication flow like OpenID Connect in which a Relying Party, that can obtain a valid identifier for the user they want to authenticate, will be able to initiate an interaction flow to authenticate their users without having end-user interaction from the consumption device. The flow involves direct communication from the Client to the OpenID Provider without redirect through the user's browser (consumption device).
This specification is a MODRNA profile of the OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA.Core] to be used when requesting authentication from Mobile Network Operators (MNOs) and includes guidance specific to that context.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
This specification uses the terms "OpenID Provider (OP)" and "Relying Party (RP)" as defined by OpenID Connect Core [OpenID.Core]. Furthermore, it uses the term "Client" as defined by OAuth 2.0. OAuth 2.0 Authorization Servers implementing OpenID Connect and CIBA are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect and CIBA are also referred to as Relying Parties (RPs). This specification also uses the following terms:
Client Initiated Backchannel Authentication (CIBA) enables a Client to initiate the authentication of an end-user by means of out-of-band mechanisms. The OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core] defines three ways to deliver the tokens and step 3 will cover the requirements for this profile.
The following use cases are non-normative examples to illustrate the usage of this specification.
The Authentication Request has the following differences from the OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core]:
Note: While the structure of a login_hint is undefined, in a mobile context a login_hint is likely to contain a MSISDN.
Note: An ecosystem can protect the pricacy of a user's MSISDN and other personally identifiable information through the use of a discovery service. The discovery service can return an encrypted login_hint_token for use in a CIBA flow.
While this profile suports CIBA push mode, implementers should only implement that mode if the constraints of an environment require it, e.g. high latency environments. Poll mode is preferred as this method of token delivery is the same as other OAuth 2.0 based flows, and therefore more likely to have had appropriate security review.
Using MODRNA CIBA Profile it is possible for the Client to authenticate a user without knowing e.g. the MSISDN of the user. Users might be reluctant to provide their MSISDN to Clients because they fear misuse through automated calls or their number being leaked. The login hint token can be encrypted in order to protect the user's MSISDN from being revealed to the Client unintentionally.
The section Example Flow shows an example to illustrate the usage of MODRNA CIBA Profile specification to authenticate a user with a SIM Applet Authenticator.
[ETSI102204] | (2003-08), ETSI., "Mobile Commerce (M-COMM) Mobile Signature Service; Web Service Interface", 2003. |
[I-D.ietf-oauth-device-flow] | Denniss, W., Bradley, J., Jones, M. and H. Tschofenig, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", Internet-Draft draft-ietf-oauth-device-flow-13, October 2018. |
[RFC6749] | Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012. |
[RFC7591] | Richer, J., Jones, M., Bradley, J., Machulak, M. and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015. |
[RFC8414] | Jones, M., Sakimura, N. and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018. |
This is a non-normative example where a challenge authentication is launched by the OP to an applet that is running in the end-user device's SIM. Such applet implements an authenticator that validates a Pin Code entered by the end-user.
This authenticator would be implemented through the so-called MSSP (Mobile Signature Subscriber Provider) Server. When the Backchannel Authentication Endpoint receives the request to authenticate the user and once it knows the user's MSISDN, it makes a call to the MSSP Server which builds a binary Class 2 SMS that is sent to the SIM card of the user where the applet is located.
This Class 2 SMS is not really sent directly from the MSSP but through the OTA (Over the air) platform which in turn signs and encrypts the message using a pair of keys (kyc, kyd) unique per each SIM Card.
Once the message reaches the SIM Card, it is decrypted by the CardManager and the signature is verified (thanks to the same pair of keys: kyc, kyd). If everything is ok, the CardManager gives the message to the applet that checks the signature (the another one made by the MSSP) and displays the challenge through a popup using the mobile phone native interface) and the user is prompted to enter a Pin Code that is validated locally. If the Pin Code is correct, the applet builds an OK response and signs it with the same key used by the MSSP to sign the request, this response is sent as a Class 3 message to the MSSP that checks the signature, and builds the id_token and the access_token to be returned to the Client.
+-----+ +-----+ +-------+ +-----------+ +-------+ | RP | | OP | | MSSP | | SIMApplet | | User | +-----+ +-----+ +-------+ +-----------+ +-------+ | | | | | | 1. POST /bc-authorize | | | | |------------------------->| | | | | | | | | | 2. HTTP 200 OK | | | | |<-------------------------| | | | | | | | | | | 3. Authenticate(MSISDN) | | | | |---------------------------->| | | | | | | | | | | 4. Challenge | | | | |-------------------------->| | | | | | | | | | | 7. Verify Req | | | | |-------------- | | | | | | | | | | |<------------- | | | | | | | | | | 8. Challenge | | | | |------------------->| | | | | | | | | | 9. Pin Code | | | | |<-------------------| | | | | | | | | | 10. Verify Pin | | | | |--------------- | | | | | | | | | | |<-------------- | | | | | | | | | 11. Response OK | | | | |<--------------------------| | | | | | | | | | 13. Verify Response | | | | |-------------------- | | | | | | | | | | |<------------------- | | | | | | | | | 14. Authentication OK | | | | |<----------------------------| | | | | | | | | | 15. Generate Tokens | | | | |-------------------- | | | | | | | | | | |<------------------- | | | | | | | | | 16. POST /cb | | | | |<-------------------------| | | | | | | | |
Many of the details have advisedly been excluded in order to simplify the flow described. To go into details of how to implement a Mobile Signature Service look at Mobile Commerce (M-COMM) Mobile Signature Service; Web Service Interface.
The following have contributed to the development of this specification.
Copyright (c) 2020 The OpenID Foundation.
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
[[ To be removed from the final specification ]]
-01
-02
-03