MODRNA WG update presented at OpenID Foundation pre-EIC 2019 workshop, May 14, 2019.

2. MODRNA WG
The interface of MODRNA (Mobile Profile of OpenID Connect) and GSMA Mobile
Connect
May 14, 2019
Bjorn Hjelm
Verizon
John Bradley
Yubico
http://openid.net/wg/mobile/

3. Purpose
• Support GSMA technical development of
Mobile Connect
• Enable Mobile Network Operators (MNOs) to
become Identity Providers
• Developing (1) a profile of and (2) an
extension to OpenID Connect for use by MNOs
providing identity services.

4. Participants

5. What is Mobile Connect?
• Mobile phone number as user identifier
• Mobile phone as authenticator
• MNO as authentication/identity provider
• Replace passwords and hardware security
tokens

6. Example Use Case

7. Mobile Connect Services

8. Mobile Connect Reference
Architecture
2. The service provider requests the
authenticating operator from the API
Exchange.
3. The service provider makes a
request for authentication.
4. The operator selects the appropriate
authenticator depending on the request for
assurance and capabilities
1. The user clicks on a Mobile
Connect button to access a
service.
• SIM Applet
• USSD
• SMS
• Smartphone App
• FIDO
MNO
Service access request
Authentication
Service Provider
Authentication
request
Authentication
server
Identity
Gateway
MNO Discovery

9. MODRNA WG
2. The service provider requests the
authenticating operator from the API
Exchange.
3. The service provider makes a
request for authentication.
4. The operator selects the appropriate
authenticator depending on the request for
assurance and capabilities
1. The user clicks on a Mobile
Connect button to access a
service.
• SIM Applet
• USSD
• SMS
• Smartphone App
• FIDO
MNO
Service access request
Authentication
Service Provider
Authentication
request
Authentication
server
Identity
Gateway
MNO Discovery
1
2 3
Set up
credentials

10. MODRNA Specifications
Core Specifications Status
Authentication Profile Implementer’s Draft
Discovery Profile Draft
Registration Profile Draft
Auxiliary Specifications Status
User Questioning API Implementer’s Draft
Client Initiated Backchannel Authentication (CIBA) Flow - Core Implementer’s Draft
MODRNA CIBA Profile Draft
Account Porting Implementer’s Draft
More information available at https://openid.net/wg/mobile/status/

11. MODRNA Core Specifications
• Discovery Profile
– http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-discovery-01.html
– Specifies a way to normalize a user identifier applicable to a mobile environment and MNO.
The specification defines discovery flow for both web and native applications residing on
mobile device.
• Registration Profile
– http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-registration-01.html
– Defines how a RP (client) dynamically registers with a MNO by extending the OpenID Connect
Dynamic Client Registration with software statements (RFC 7591).
• Authentication Profile
– http://openid.net/specs/openid-connect-modrna-authentication-1_0.html
– Specify how RP’s request a certain level of assurance (LoA) for the authentication and an
encrypted login hint token to allow for the transport of user identifiers to the MNO in a
privacy preserving fashion. The specification also specify an additional message parameter to
bind the user’s consumption device and authentication device.

12. MODRNA Auxiliary
Specifications
• User Questioning API
– http://openid.net/specs/openid-connect-user-questioning-api-1_0.html
– Defines a mechanism to perform transaction authorizations.
– Defines additional OpenID Connect endpoint (Resource Server) that RP would use
(server-to-server) to initiate transaction authorization processes.
• Account Porting
– http://openid.net/specs/openid-connect-account-porting-1_0.html
– Defines a mechanism to allow the migration of user account from old to new OP.
– Protocol allowing new OP to obtain the necessary user data from the old OP and provide
every RP with the necessary data to migrate the RP's local user account data in a secure
way.

13. CIBA Development
• Initial work on Client Initiated Backchannel Authentication (CIBA) specification defined
a mechanism to perform authentication (out-of-band) when there is no user agent
available and the authentication process needs to initiated via server-to-server
communication.
• As part of the collaboration with Financial-grade API (FAPI) WG, the CIBA specification
was spilt into Core and Profile specifications to support multiple use cases.
– The CIBA Core specification defines the CIBA flows for various use cases and defines the token delivery
modes for the Client (Poll, Ping or Push) determined at registration time.
– The MODRNA: Client Initiated Backchannel Authentication Profile addresses the MODRNA requirements
for CIBA.
• CIBA Core specification approved as Implementer’s Draft on Feb. 4, 2019.
– https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-ID1.html
• MODRNA CIBA Profile is currently in development.

14. CIBA Core Overview
CIBA enables a Client to initiate the authentication of an
end-user by means of out-of-band mechanisms.
1. Client make an "HTTP POST" request to the
Backchannel Authentication Endpoint to ask for
end-user authentication.
2. OpenID Connect Provider (OP) will respond with a
unique identifier that identifies that authentication
while it tries to authenticate the user in the
background.
3. The Client will receive ID Token, Access Token and
optionally Refresh Token through either Poll, Ping
or Push modes (established by the Client at
registration time).
5/7/2019 OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-02
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html 1/23
G. Fernandez
Telefonica
F. Walter
A. Nennker
Deutsche Telekom AG
D. Tonge
Moneyhub
B. Campbell
Ping Identity
January 16, 2019
OpenID Connect Client Initiated Backchannel
Authentication Flow ­ Core 1.0 draft­02
openid­client­initiated­backchannel­authentication­core­02
Abstract
OpenID Connect Client Initiated Backchannel Authentication Flow is an authentication flow like
OpenID Connect. However, unlike OpenID Connect, there is direct Relying Party to OpenID Provider
communication without redirects through the user's browser. This specification allows a Relying
Party that knows the user's identifier to obtain tokens from the OpenID Provider. The user consent is
given at the user's Authentication Device mediated by the OpenID Provider.

15. MODRNA WG Status
• Currently working on post-Implementer’s Draft issues for
CIBA Core spec. and completing MODRNA CIBA Profile.
• Additional specifications in development
– Plans to progress Authentication Profile towards Final
Specification.
– Discovery Profile to progress towards Implementer’s Draft status
in support of market deployment.
– Continue the Account Porting discussions to address options in
the first part of the porting flow.

16. MODRNA - GSMA CPAS Status
• User Questioning API adopted by Mobile Connect as an enabler
based on work done in MODRNA WG.
– Mobile Connect product definition and technical effort led by Orange.
• Possible impact to Mobile Connect from new CIBA development.
– Mobile Connect currently support back-channel authentication in the
Server-initiated Profile specification.
• New work started to add support in Mobile Connect for Token
Binding.
– Based on recent IETF approved RFCs and work aligning with OpenID
Connect Token Bound Authentication specification in EAP (Enhanced
Authentication Profile) WG.

17. Thank you
http://openid.net/wg/mobile/