Deutsche Telekom AG

j.connotte@telekom.de

Ping Identity

jbradley@pingidentity.com

OpenID Mobile Profile Working Group 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 messge parameter intended to serve as an interlock between the user's consumpution device and authentication device.

OpenID Connect MODRNA Authentication Profile 1.0 is a profile of the OpenID Connect Core 1.0 specification that defines common authentication contexts and further extensions to OpenID Connect Core to be used when requesting authentication from MNO's. Moreover it defines Mandatory to Implement features for MNOs to assure interoperability of clients across MNO's.

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 . 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 termn "OpenID Provider (OP)" and "Relying Party (RP)" as defined by OpenID Connect Core. This specification also defines the following terms: A provider of wireless communication services that owns or controls the wireless network elements necessary to sell and deliver services to an end user. A telephone number uniquely identifying a subscription in a mobile network. A user agent, most probably a browser, on which the user consumes the actual service provided by the Relying Party. A mobile device on which the user will authenticate the actual login.

This specification serves as a profile based on OpenID Connect Core . It defines additional request parameters in the Authentication Request. It also specifies authentication class reference values based on the ISO/IEC DIS 29115 to be used for the "acr_values" request parameter.

MODRNA supports all request parameters as specified in OpenID Connect Core 3.1.2.1 . In addition the following parameters are defined or made REQUIRED for clients to send. All additional paramaters are REQUIRED for OP to support. REQUIRED. In this parameter is specified as OPTIONAL. For MODRNA this parameter is REQUIRED in order to enable the Relying Party to indicate a MODRNA conform authentication request to the OP. Allowed values are defined in . OPTIONAL. This is a new parameter. The login_hint_token is used to transport a user identifier from the Discovery Service to the OpenID Provider without revealing this identifier to the client. specifies the structure of this parameter. Protection of the login_hint_token's content is specified in . OPTIONAL. This is a new parameter. An Interlock message to tie the consumption device and the authentication device together. How to ensure that the message is actually shown on all relevant devices is out of the scope of this document. Possible values and constraints are specified in . Ways to protect the integrity of the binding_message are discussed in .

The service's terms of service will specify a trust framework for Identity Providers to follow for general business processes and other related account security issues. This specification defines an initial set of acr values that clients can use to request the IdP mitigate specific authentication risks. The initial set of acr values contain no requirements for the IdP to make any guarantee of identity proofing the subject of the authentication beyond what is required by business practices for account recovery and customer service as defined in the trust framework. Prepaid anonymous users may be included in responses conforming to these values. The IANA Level of Assurance (LoA) Profiles Registry will be used to register the short names for these LoA, and any future additional LoA. Short-Name: mod-pr This mitigates phishing of credentials. The user is authenticated via possession of a device (phone) containing a secret key. The user is required to provide no additional authentication information to use the key. The user is interactively prompted to confirm the authentication. The storage mechanism for the secret key and other relevant authentication information is returned via the amr. The user is not re-prompted for credentials if the value of prompt is not login and max_age is more than the elapsed time since the user last authenticated at the requested acr. Short-Name: mod-mf This mitigates phishing and proves the device is recently in the possession of the authorised user via pin or device unlock. The user is authenticated via possession of a device (phone) containing a secret key. The user is required to provide additional authentication information via a biometric, pin code or other appropriate factors such as bluetooth paring with a watch. Given suitable Mobile device management unlocking the device is also sufficient along with user confirmation of desire to authenticate. The storage mechanism for the secret key and other relevant authentication information is returned via the amr value. The user is not re-prompted for credentials if the value of prompt is not login and max_age is more than the elapsed time since the user last authenticated at the requested acr. Identity Providers MUST recognize and process short registered forms of the authentication context strings. They may recognize and process long forms for custom authentication contexts. Clients MUST send the short registered forms of the authentication context strings, if the authentication context is registered. The OP MUST support receiving acr_values as a space separated list in order of preference per OpenID Connect Core 3.1.2.1 . The OP MUST support receiving acr as a claim request in a signed request per OpenID Connect Core 5.5.1 . This method prevents the request from being modified by the user, and allows the requested acr valued to be considered essential claims causing the IdP to respond with an authentication error if no requested acr value can be fulfilled. Depending on the authentication capabilities of the users device, the OP must attempt to match the highest requested acr value that the AD is capable of. If the acr claim is not marked as essential in the request object, the OP may return another acr value that the device is capable of rather than an error if it cannot match any of the requested acr_values.

The amr claim OpenID Connect Core Sec 2 SHOULD be returned in the id_token if a acr value is specified in the request. The amr claim is a JSON array containing one or more string values indicating the authentication methods used in the authentication. The values for the strings in the amr claim are registered in a IANA registry defined in Authentication Method Reference Values. This specification recommends the use of several of the values, to provide a standard way for clients to understand the authentication User presence test. A Personal Identification Number or pattern (Not restricted to numbers only) that a user used to unlock a key on the device. This mechanism SHOULD have a way to deter an attacker from guessing the pin by making multiple guesses. Fingerprint biometric Confirmation by responding to a SMS sent to a known device. Proof-of-possession (PoP) of a software-secured key. Proof-of-possession (PoP) of a hardware-secured key. Geo-Location of the authentication device.

If the authentication is performed by sending the users mobile device a SMS with a URI and having the user click on the link to confirm, it SHOULD have a amr value of ["sms","user"] If the authentication is by sending a secure message to a hardware element in mobile device's and the HW element signs a authentication challenge only after the user has entered a local PIN then it SHOULD have a amr value of ["hpop","pin"] If the authentication is by sending a secure message to a software application in the mobile device that signs a authentication challenge only after the user has entered a local fingerprint biometric then it SHOULD have a amr value of ["pop","fpt"] If the authentication is by sending a secure message to a hardware element in mobile device's and the HW element signs a authentication challenge only after the user has entered a local fingerprint biometric, and the IdP has preformed additional passive analytics based on geo location, then it SHOULD have a amr value of ["hpop","fpt","geo"] Note that if two or more authentication factors are used the MNO may include the amr value mfa and optionally not include the specific factors. Note: that the order of elements in the amr array is not significant.

The login_hint_token is used to pass a user hint into the authentication process at the OP. This hint is opaque to the client by design. There are several ways for a client to obtain a login hint token. To start with, the MODRNA discovery service creates a hint if the user has entered their MSISDN in the course of the MNO discovery process. In the case of a login_hint_token produced by the MODRNA Discovery Service it is an encrypted Json Web Token JWT that contains a user hint for the OP. The login_hint_token SHALL be used by the client as login hint with OP identified by the MODRNA discovery service. In this case, the login hint token is supposed to be a signed and encrypted JWT. The Authorization server may produce login_hint_token tokens in other formats for use in Account Chooser or other discovery profiles, as long as they are confidentiality protected from the client. The login_hint_token produced by the MODRNA discovery service has the following elements: REQUIRED. The party creating the token. This value MUST be used by the IdP receiving the token to obtain the JWK file required to validate the tokens's signature (see ). REQUIRED. The party to receive the token, typically the users OpenID Provider. The value MUST be the issuer URI of the OP as exposed in the IdP's openid-configuration meta-data. REQUIRED. When the token was issued. REQUIRED. The Subscriber identifier formated according to ITU-T recommendation

The following is a non-normative example of JWT body (with line wraps within values for display purposes only):

The login_hint token MUST be encrypted using the public key of the OpenID Provider designated by the claim "aud" in the login_hint_token. The appropriate public key is obtained using the rules defined in OpenID Connect Discovery. In the first step, the openid-configuration for the IdP is retrieved by performing discovery Per Section 4 of using the issuer string for the users IdP as the input. In the next step, the value of the "jwks_uri" claim Per Section 3 of is used to retrieve the OP's JWK. A public key in the JWK with a use paramater of "enc" per Section 4.2 of JWK is used as the encryption key. The login_hint_token is then encrypted as a JWE using that key. The login_hint token MUST be signed using the private key of the Discovery Service. It is best practice to sign then encrypt tokens, as signatures over encrypted information may leak information in the envelope, and may not be considered legally valid. For an example of a nested JWT that is signed and then encrypted see Appendix 2 of JWT. NOTE: The login_hint_token is opaque to the client by design. The Authorization server may produce login_hint_token tokens in other formats for use in Account Chooser or other discovery profiles, as long as they are confidentiality protected from the client.

The binding_message parameter is a text provided by the RP intended to be shown to the user on the consumption device as well as on the authentication device as an interlock between RP and OP. The binding_message MUST be plain text using the "application/x-www-form-urlencoded" format as the authentication device in particular may have limited abilities to show text or formats. The binding_message SHOULD be displayable on all participating devices. The RP SHOULD consider that some authentication devices e.g. as SIM-Applets are able to show only a very limited number of characters.

All MODRNA compliant OP's MUST accept the acr_values specified in

The login hint token SHOULD be digitally signed by the issuer. This ensures authenticity of the data and reduces the threat of an injection attack. The signature allows the OP to authenicate and authorize the sender of the hint and prevent collecting of phone numbers by rogue clients. To prevent modification of the binding_message value, the RP SHOULD send the parameter to the OP using a signed OpenID Connect Request Object (section 6.3.2 of ). The OP MUST sanitize the binding_message value in order to prevent injection attacks. The binding_message value being displayed on the consumption and authentication device SHOULD contain a random value (e.g. an authorization code) of reasonable entropy. This is a countermeasure against session fixation type attacks, where the attacker initiates an authentication process on a consumption device under his control, which will result in the same text being displayed on the authentication device as for legitimate transactions.

The login hint token is encrypted in order to protect the user's MSISDN from being revealed to the client unintentionally.

TBD: Find out about how to correctly add entries to IANA for: https://www.iana.org/assignment/loa-profiles/loa-profiles.xhtml

Nomura Research Institute, Ltd. Ping Identity Microsoft Google Salesforce Nomura Research Institute, Ltd. Ping Identity Microsoft Illumila ISO ITU-T ITU-T Deutsche Telekom AG Ping Identity

The following have contributed to the development of this specification. Matthieu Verdier (matthieu.verdier@orange.com), Orange Gonzalo Fernandez Rodriguez (gonzalo.fernandezrodriguez@telefonica.com), Telefonica

Copyright (c) 2017 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 ]] -06 update reference to amr spec Make Date current for implementers draft -01 Initial draft Added OIDF Standard Notice changed references to amr specification