| B. Hjelm | |
| Verizon | |
| T. Lodderstedt | |
| Deutsche Telekom AG | |
| J. Bradley | |
| Ping Identity | |
| October 29, 2015 |
OpenID Connect Mobile Registration Profile 1.0
draft-mobile-registration-01
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.
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.
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.
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:
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": "https://registry.exampleregistry.com", "aud": ["https://accounts.operator1.com","https://accounts.operator2.com","https://accounts.operator3.com"], "software_id": "4NRB1-0XZABZI9E6-5SM3R", "software_version": "2.2", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/", "redirect_uris": ["https://client.example.org/callback", ...
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.
The Client Registration Endpoint is an OAuth 2.0 Protected Resource through which a new Client registration can be requested.
The following is a non-normative example of a Software Statement:
{
"iss": "https://registry.exampleregistry.com",
"aud": ["https://accounts.operator1.com","https://accounts.operator2.com","https://accounts.operator3.com"],
"exp": "1311281970",
"iat": "1311280970",
"jti": "id12345685439487678",
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"software_version": "2.2",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/",
"redirect_uris": ["https://client.example.org/callback",
"https://client.example.org/callback2"],
"token_endpoint_auth_method": "client_secret_basic",
"grant_types": ["authorization_code"],
"response_types": ["code"],
"logo_uri": "https://client.example.org/logo.png",
"scope": "openid",
"contacts": ["ve7jtb@example.org", "mary@example.org"],
"tos_uri": "https://client.example.org/tos.html",
"policy_uri": "https://client.example.org/policy.html",
"application_type": "web",
"sector_identifier_uri": "https://other.example.net/file_of_redirect_uris.json",
"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": "https://registry.exampleregistry.com/tos.html"
}
[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?.
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
Host: accounts.operator1.com
{
"software_statement": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXV
CJ9.eyJpc3MiOiJodHRwczovL3JlZ2lzdHJ5LmV4YW1wbGVyZWdpc3RyeS5jb20
iLCJhdWQiOlsiaHR0cHM6Ly9hY2NvdW50cy5vcGVyYXRvcjEuY29tIiwiaHR0cH
M6Ly9hY2NvdW50cy5vcGVyYXRvcjIuY29tIiwiaHR0cHM6Ly9hY2NvdW50cy5vc
GVyYXRvcjMuY29tIl0sImV4cCI6IjEzMTEyODE5NzAiLCJpYXQiOiIxMzExMjgw
OTcwIiwianRpIjoiaWQxMjM0NTY4NTQzOTQ4NzY3OCIsInNvZnR3YXJlX2lkIjo
iNE5SQjEtMFhaQUJaSTlFNi01U00zUiIsInNvZnR3YXJlX3ZlcnNpb24iOiIyLj
IiLCJjbGllbnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVud
CIsImNsaWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8iLCJy
ZWRpcmVjdF91cmlzIjpbImh0dHBzOi8vY2xpZW50LmV4YW1wbGUub3JnL2NhbGx
iYWNrIiwiaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5vcmcvY2FsbGJhY2syIl0sIn
Rva2VuX2VuZHBvaW50X2F1dGhfbWV0aG9kIjoiY2xpZW50X3NlY3JldF9iYXNpY
yIsImdyYW50X3R5cGVzIjpbImF1dGhvcml6YXRpb25fY29kZSJdLCJyZXNwb25z
ZV90eXBlcyI6WyJjb2RlIl0sImxvZ29fdXJpIjoiaHR0cHM6Ly9jbGllbnQuZXh
hbXBsZS5vcmcvbG9nby5wbmciLCJzY29wZSI6Im9wZW5pZCIsImNvbnRhY3RzIj
pbInZlN2p0YkBleGFtcGxlLm9yZyIsIm1hcnlAZXhhbXBsZS5vcmciXSwidG9zX
3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUub3JnL3Rvcy5odG1sIiwicG9s
aWN5X3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUub3JnL3BvbGljeS5odG1
sIiwiYXBwbGljYXRpb25fdHlwZSI6IndlYiIsInNlY3Rvcl9pZGVudGlmaWVyX3
VyaSI6Imh0dHBzOi8vb3RoZXIuZXhhbXBsZS5uZXQvZmlsZV9vZl9yZWRpcmVjd
F91cmlzLmpzb24iLCJzdWJqZWN0X3R5cGUiOiJwYWlyd2lzZSIsImlkX3Rva2Vu
X3NpZ25lZF9yZXNwb25zZV9hbGciOiJSUzI1NiIsImFsbG93ZWRfY2xhaW1zIjp
bIm5hbWUiLCJmYW1pbHlfbmFtZSIsInBob25lX251bWJlciIsInBob25lX251bW
Jlcl92ZXJpZmllZCJdLCJhbGxvd2VkX2FjcnMiOlsidXJuOm1vZHJuYTphY3I6Y
3JlZGVudGlhbDpsb2EyIiwidXJuOm1vZHJuYTphY3I6Y3JlZGVudGlhbDpsb2Ez
Il0sInJlZ2lzdHJ5X3RvcyI6Imh0dHBzOi8vcmVnaXN0cnkuZXhhbXBsZXJlZ2l
zdHJ5LmNvbS90b3MuaHRtbCJ9.Ei47Uuo-pbV15Y2595kj8V4EAJAPJPmHz2XuK
PVSbgR-DpjVt9eWz_cyI0ksnnsh61i6mdUf1glpzFHd9x7Qvgl-s22bKRmqa1cl
Y2HjgTg4h_RsNJL6oYufxfBy2pATrqTbTdXCRNo9CbxLcxF5b-jnZcvZvlOVdlr
HOPK__6s"
}
...
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_secret":
"ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
"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.
[Editor's note:] Error message should include the scenario when an OP blocks a RP.
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?
[Editor's note:] Define authentication mechanism. Start with RSA and define minimum and maximum key length.
TBD
This document makes no requests of IANA.
The OpenID Community would like to thank the following people for their contributions to the development of this specification:
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.
[[ To be removed from the final specification ]]
-01
-02
-03