OpenID Connect Mobile Registration Profile 1.0
B. Hjelm
T. Lodderstedt
Deutsche Telekom AG
J. Bradley
Ping Identity
October 29, 2015

OpenID Connect Mobile Registration Profile 1.0


OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] defines how an OpenID Connect Relying Party (RP) can dynamically register with the End-User's OpenID Provider, providing information about itself to the OpenID Provider, and obtaining information needed to use it.

The OpenID Connect Mobile Registration Profile specification defines how a RP dynamically registers with a mobile network operator (MNO) to access identity services provided by the MNO. The RP shall be able to access identity services from multiple MNOs withour requiring the RP to register with all individual MNOs. To achieve this, the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] will be extended with Software Statement as specified in OAuth2.0 [RFC 7591].

It is beyond the scope of this specification how the RP will obtain original legitimation. It is assumed that some trustworthy party validates the RP and issues the software statement to the RP. It is also beyond the scope of this specification how an OpenID Provider validates the software statement.

Table of Contents

1. Introduction

OpenID Connect Mobile Registration Profile 1.0 is a profile of the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification that that allows a RP to dynamically register with multiple Mobile Network Operators (MNOs) based on information asserted by a trusted entity e.g. a primary MNO that the client has a relationship with.

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.

1.2. Terminology

This specification uses the terms "OpenID Provider (OP)" and Relying Party (RP) defined by OpenID Connect Core [OpenID.Core].

This specification also defines the following terms:

2. Overview

This specification defines the dynamic client registration process for OpenID Connect Mobile Profile and describes how an OpenID Connect Relying Party can dynamically register with the End-User's Mobile Network Operator (MNO) and obtain the information needed to use it with multiple MNOs.

The following figure shows a high-level flow for the business process of registration. The Registry acts on behalf of all the MNO OPs Mobile Connect system. The assumption is that the Registry verifies the Service Provider. The Service Provider is required to accept the terms and conditions for the MNOs OPs. Registry issues a Software Statement that represents credentials to establish a trust relationship with the MNO's OP.

+----------+                                +--------------+
| Service  |---(A)- registration request -->|   Registry   |
| Provider |<--(B)-- Software Statement ---|              |
+----------+                                +--------------+

(A) The Service Provider sends a registration request to the Registry.

(B) The Registry responds with a Software Statement. The Software Statement serves two purposes: (1) authorizes client to register with MNO's OP and (2) puts limitations on the client. Below is an example of such Software Statement.

"iss": "",
"aud": ["","",""], 
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"software_version": "2.2",
"client_name": "Example Statement-based Client",
"client_uri": "",
"redirect_uris": ["",

The Relaying Party sends a Registration Request with any Client Metadata parameters that the Client chooses to specify for itself during the registration. The assumptions is that evey instant of a Client would register with the MNO OP.

+----------+                                 +----------------+
|          |                                 |    MNO's OP    |
|          |                                 |--------------| |
| Relaying |---(A)-- Registration Request -->| Registration | |
| Party    |<--(B)-- Registration Response --| Endpoint     | |
|          |                                 |--------------| |
|          |                                 |                |
+----------+                                 +----------------+

[Editor's note:] It is assumed that the RP needs to agree to the MNO-specific or regional/global Terms and Conditions and that the respective information are carried to the MNO at runtime via the software statement.

[Editor's note:] MODRNA OP is able to process OpenID Connect Client Registration requests with software statements, so MODRNA RPs can use this mechanism instead of plain request parameters. Difference: entitlement to register with MODNRA OP may depend on external assertion (software statement) -> introduces concept of protected OP to OIDC.

3. Client Registration

The Client Registration Endpoint is an OAuth 2.0 Protected Resource through which a new Client registration can be requested.

3.1. Software Statement

The following is a non-normative example of a Software Statement:

       "iss": "",
       "aud": ["","",""], 
       "exp": "1311281970",
       "iat": "1311280970",
       "jti": "id12345685439487678",
      "software_id": "4NRB1-0XZABZI9E6-5SM3R",
      "software_version": "2.2",
      "client_name": "Example Statement-based Client",
      "client_uri": "",
      "redirect_uris": ["",
      "token_endpoint_auth_method": "client_secret_basic",
      "grant_types": ["authorization_code"],
      "response_types": ["code"],
      "logo_uri": "",
      "scope": "openid",
      "contacts": ["", ""],
      "tos_uri": "",
      "policy_uri": "",
      "application_type": "web",
      "sector_identifier_uri": "",
      "subject_type": "pairwise",
      "id_token_signed_response_alg": "RS256", 
      "allowed_claims": ["name", "family_name", "phone_number", "phone_number_verified"],
      "allowed_acrs": ["urn:modrna:acr:credential:loa2", "urn:modrna:acr:credential:loa3"],
      "registry_tos": ""

[Editor's note:] Cross-check with HEART and Blue Button Plus. Multiple Software Statement per Software ID.

[Editor's note:] Proposal to is to limit the signature algorithm to RSA to start with.

[Editor's note:] What claims are required to carry information about MNO T&Cs or more general authz data?.

3.2. Client Registration Request

A valide OAuth client_id and Client secret are issued during client registration with the MNO's OP. The client_id is unique within MNO.

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
  "software_statement": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXV


3.3. Client Registration Response

A valid OAuth client_id and Client secret are issued during client registration with the MNO. The MNO MAY use a stateless client credential management.

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

 "client_id": "s6BhdRkqt3",
 "client_id_issued_at": 2893256800,
 "client_secret_expires_at": 1577858400,

If the client is registered with another MNO, a new version of the Client_ID is required.

Verify life cycle of the Software Statement with OAuth spec.

3.4. Error Response

[Editor's note:] Error message should include the scenario when an OP blocks a RP.

4. Implementation Considerations

The MNO May use a stateless client credential management.

[Editor's note:] Should the options (use Software Statement as client_id, encode client data within the client_id or secret) be defined in this section?

[Editor's note:] What are the scalability issues with the MNO implementation that should be addressed in the implementation guidelines?

5. Security Considerations

[Editor's note:] Define authentication mechanism. Start with RSA and define minimum and maximum key length.

6. Privacy Considerations


7. IANA Considerations

This document makes no requests of IANA.

8. Normative References

[RFC7519] Jones, M., J. Bradley, and Sakimura, N., "JSON Web Token (JWT)", May 2015.
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B. and C. Mortimore, "OpenID Connect Core 1.0", November 2014.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M. and E. Jay, "OpenID Connect Discovery 1.0", November 2014.
[OpenID.Registration] Sakimura, N., Bradley, J., and Jones, M., "OpenID Connect Discovery 1.0", November 2014.
[RFC7591] Richer, J., , Jones, M., Bradley, J., Machulak, M., and Hunt, P., OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2246] Dierks, T. and Allen, C., The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC5246] Dierks, T. and Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.2", RFC5246, August 2008.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.

Appendix A. Acknowledgements

The OpenID Community would like to thank the following people for their contributions to the development of this specification:

Appendix B. Notices

Copyright (c) 2014 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 C. Document History

[[ To be removed from the final specification ]]




Authors' Addresses

Bjorn Hjelm Verizon EMail:
Torsten Lodderstedt Deutsche Telekom AG EMail:
John Bradley Ping Identity EMail: