MODRNA Working Group - Specifications

The MODRNA working group is developing a profile of OpenID Connect designed for use by mobile network operators (MNOs) providing identity services to relying parties (RPs) and for RPs in consuming these services in an interoperable manner.

MODRNA Working Group OVERVIEW

MODRNA Working Group CHARTER

MODRNA Working Group
SPECIFICATIONS

MODRNA Working Group
REPOSITORY

Based on an initial proposal for the MODRNA profile of OpenID Connect as well as an alternative proposal for mobile discovery and other inputs, the working group has been developing the following specifications.

Final Specifications

  • OpenID Connect Client Initiated Backchannel Authentication Flow – Core (replacing OpenID Connect Backchannel Authentication) –

    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 has the concept of a Consumption Device (on which the user interacts with the Relying Party) and an Authentication Device (on which the user authenticates with the OpenID Provider and grants consent). This specification allows a Relying Party that has an identifier for a user to obtain tokens from the OpenID Provider. The user starts the flow with the Relying Party at the Consumption Device, but authenticates and grants consent on the Authentication Device.

Implementer's Drafts

  • OpenID Connect MODRNA Authentication Profile – RPs are keen to use high quality authentication methods, which can be provided by Mobile Network Operators (MNO). However a RP must be able to describe its demands for an authentication request and it must be able to do this in an interoperable way. The MODRNA Authentication Profile will specify how RP’s request a certain level of assurance for the authentication. In addition, the profile will specify an encrypted login hint token to allow for the transport of user identifiers to the OP in a privacy preserving fashion. Lastly, the profile will specify an additional message parameter intended to serve as an interlock between the user’s consumption device and authentication device.
    – Most recent Implementer’s Draft 
  • OpenID Connect Account Porting – This specification defines mechanisms to support a user porting from one OpenID Connect Provider to another, such that relying parties can automatically recognize and verify the change.
    – Most recent Implementer’s Draft 
  • OpenID Connect User Questioning API – This specification defines an API offered by an OpenID Provider (OP) that can be used by an application to send a question to a user of the OP. The user does not need to be interacting with the application when the question is asked. The user’s answer is returned asynchronously, digitally-signed by the OP.

    – Most recent Implementer’s Draft

Drafts