MODRNA: Client Initiated Backchannel Authentication Profile 1.0 draft-03
openid-connect-modrna-client-initiated-backchannel-authentication-profile-03

Abstract

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).

Table of Contents

• 1. Introduction
• 1.1. Requirements Notation and Conventions
• 2. Terminology
• 3. Overview
• 3.1. Examples of Use Cases
• 4. Authentication Request
• 5. Security Considerations
• 6. Privacy Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Example Flow
• Appendix B. Acknowledgements
• Appendix C. Notices
• Appendix D. Document History
• Authors' Addresses

1. Introduction

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.

1.1. Requirements Notation and Conventions

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.

2. Terminology

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:

Mobile Network Operator (MNO)

A provider of wireless communication services that owns or controls the wireless network elements necessary to sell and deliver services to an end user.

Mobile Station International Subscriber Directory Number (MSISDN)

A telephone number uniquely identifying a subscription in a mobile network.

Consumption Device (CD)

The Consumption Device is the device that helps the user consume the service. In the CIBA use case, the user is not necessarily in control of the CD. For example, the CD may be in the control of an RP agent (e.g. at a bank teller) or may be an RP controlled device (e.g. a petrol pump).

Authentication Device (AD)

The device on which the user will authenticate and authorize the request, often a smartphone.

3. Overview

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.

1. The Client shall make an "HTTP POST" request to the Backchannel Authentication Endpoint to ask for end-user authentication.
2. The OP will respond immediately with a unique identifier that identifies that authentication while it tries to authenticate the user in the background.
3. The Client will receive the ID Token, Access Token and optionally Refresh Token by means of either the Poll or Push modes. This choice MUST be established by the Client at registration time.

   Poll Mode

   When configured in Poll mode, the Client will poll the token endpoint to get a response with the tokens.

   Push Mode

   When configured in Push mode, the OP will send a request with the tokens to a callback URI previously registered by the Client.

3.1. Examples of Use Cases

The following use cases are non-normative examples to illustrate the usage of this specification.

1. A call center agent wants to authenticate a caller. Using additional scopes like e.g. "profile" or "phone" the call center agent would get access to claims about the user like "phone_number" and "phone_number_verified".
2. An IDP wants to offer the ability for its relying parties to request "step-up" authorisation via a decoupled device

4. Authentication Request

The Authentication Request has the following differences from the OpenID Connect Client Initiated Backchannel Authentication Flow [CIBA Core]:

acr_values

REQUIRED. This value is required as defined in OpenID Connect MODRNA Authentication Profile [MODRNA.Authentication].

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.

5. Security Considerations

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.

6. Privacy Considerations

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.

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Example Flow

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.

Appendix B. Acknowledgements

The following have contributed to the development of this specification.

Appendix C. Notices

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.

Appendix D. Document History

[[ To be removed from the final specification ]]

-01

• Initial draft of mobile profile

-02

• Tidied up draft, removing todos

-03

• Updated title, version numbering and authors.
• Updated text in the abstract and introduction sections.
• Added terminology section.
• Updated reference section with CIBA Core and MODRNA spec. and added the references throughout the spec.
• Added Overview section and included examples of use cases.
• Removed ping mode based on initial version of CIBA.

Authors' Addresses