SlideShare a Scribd company logo
MODRNA WG
The interface of MODRNA (Mobile Profile of OpenID Connect) and GSMA Mobile
Connect
September 30, 2019
Bjorn Hjelm
Verizon
John Bradley
Yubico
http://openid.net/wg/mobile/
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.
Participants
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
Example Use Case
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
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
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/
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.
Ancillary MODRNA Spec.
• 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.
• 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.
CIBA Development
• OpenID Connect Client Initiated Backchannel
Authentication (CIBA) flow is an authentication flow
initiated via server-to-server communication between
an Relying Party (RP) and OpenID Provider (OP) without
redirects through the user’s browser.
• 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.
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.
MODRNA WG Work Status
• Currently addressing remaining open issues for CIBA Core spec.
in preparation of a second Implementer’s Draft vote.
• Completing MODRNA CIBA Profile is also a priority.
• 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 based on feedback from market
deployment.
GSMA MOBILE CONNECT
DEVELOPMENT
External Organizations Update
Transition to Mobile
Connect Interest Group
Mobile Connect Interest Group (MCIG) replaces the
previous efforts provided by the GSMA Identity
Program.
MCIG is a forum for GSMA members to collaborate on
matters relating to the operation and commercial
growth of Mobile Connect and Identity services.
The forum is member led and we focus on topics such
as:
• Commercial case studies with the best-completed
work supported by measurable results that show
how Mobile Connect solved a client problem.
• Best practice deployment of Mobile Connect service
MNO cooperation/internal processes
• New product ideas and change request based on
market input.
What is Mobile Connect Interest Group?
Sample of members:
Bics
BOKU
Boloro
Bouygues Telecom
CallSign
China Mobile
Deutsche Telekom
Dimoco
EE/BT
Ericsson
Evolve
ForgeRock
G+D Group
Gemalto
Google
HPE
Hutchison
Idemia
IMImobile
Infobip
JT Global
KDDI
KPN
LinkMobility
MTS
Oracle
Orange
Payfone
SFR
Synverse
Telcel
Telia
Telefonica
Telstra
T-Mobile
Turkcell
Verizon
Vodafone
The MCIG Technical subgroup (TSG) is responsible for maintaining the MC Product and Core framework
specifications including items such as:
• Corrections/clarifications and bugfixes to the specifications based on feedback from implementers.
• Enhancements to improve performance and/or functionality to meet market demands.
• Incorporation of new features or updates specified within relevant standards bodies (OIDF, IETF etc.).
• Addressing security weaknesses as they arise.
Mobile Connect Interest Group Technical Sub-working Group
Mobile Connect Product Portfolio
Authentication Network attributesIdentityAuthorisation
Simple and convenient log-in
or step-up authentication
Insights about the device
and user’s mobile account
Provision or verification of user
identity
User authorisation of SP
requests
Thank you
http://openid.net/wg/mobile/

More Related Content

OpenID Foundation MODRNA WG Overview

  • 1. MODRNA WG The interface of MODRNA (Mobile Profile of OpenID Connect) and GSMA Mobile Connect September 30, 2019 Bjorn Hjelm Verizon John Bradley Yubico http://openid.net/wg/mobile/
  • 2. 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. 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. 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
  • 7. 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
  • 8. 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/
  • 9. 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.
  • 10. Ancillary MODRNA Spec. • 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. • 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.
  • 11. CIBA Development • OpenID Connect Client Initiated Backchannel Authentication (CIBA) flow is an authentication flow initiated via server-to-server communication between an Relying Party (RP) and OpenID Provider (OP) without redirects through the user’s browser. • 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. 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.
  • 12. MODRNA WG Work Status • Currently addressing remaining open issues for CIBA Core spec. in preparation of a second Implementer’s Draft vote. • Completing MODRNA CIBA Profile is also a priority. • 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 based on feedback from market deployment.
  • 15. Mobile Connect Interest Group (MCIG) replaces the previous efforts provided by the GSMA Identity Program. MCIG is a forum for GSMA members to collaborate on matters relating to the operation and commercial growth of Mobile Connect and Identity services. The forum is member led and we focus on topics such as: • Commercial case studies with the best-completed work supported by measurable results that show how Mobile Connect solved a client problem. • Best practice deployment of Mobile Connect service MNO cooperation/internal processes • New product ideas and change request based on market input. What is Mobile Connect Interest Group? Sample of members: Bics BOKU Boloro Bouygues Telecom CallSign China Mobile Deutsche Telekom Dimoco EE/BT Ericsson Evolve ForgeRock G+D Group Gemalto Google HPE Hutchison Idemia IMImobile Infobip JT Global KDDI KPN LinkMobility MTS Oracle Orange Payfone SFR Synverse Telcel Telia Telefonica Telstra T-Mobile Turkcell Verizon Vodafone
  • 16. The MCIG Technical subgroup (TSG) is responsible for maintaining the MC Product and Core framework specifications including items such as: • Corrections/clarifications and bugfixes to the specifications based on feedback from implementers. • Enhancements to improve performance and/or functionality to meet market demands. • Incorporation of new features or updates specified within relevant standards bodies (OIDF, IETF etc.). • Addressing security weaknesses as they arise. Mobile Connect Interest Group Technical Sub-working Group
  • 17. Mobile Connect Product Portfolio Authentication Network attributesIdentityAuthorisation Simple and convenient log-in or step-up authentication Insights about the device and user’s mobile account Provision or verification of user identity User authorisation of SP requests