Methics registers “mss” URI Scheme

IANA today registered provisional URI scheme “mss” published by Methics. The “mss” scheme defines the URI for SignatureProfiles used for requesting mobile signature services from the MSSP Platform. You can find the scheme from: https://www.iana.org/assignments/uri-schemes/prov/mss

Signature Profile in Mobile Signature Service

The success of Mobile Signature Service (MSS) is reliant on a feature where an Application Provider (AP) does not need to know, in which mobile operator’s network a user can be found. This feature is called “signature roaming”.

If all reachable mobile users in various mobile networks do not have the same signature capabilities, it is hard for an AP to determine what kind of mobile signature to request from different mobile users. Especially when several different mobile signature services are available. The MSSP can define different mobile signature capabilities of mobile users, but AP should be able to indicate some kind of a signature type/quality to the MSSP. This capability is called the Signature Profile.

By using the ProfileQuery mechanism, the AP can request any mobile user’s Mobile Signature Profiles from a MSSP. Additionally, the AP can use any specific Signature Profile assigned to the user in the Mobile Signature Request.

Usage of Signature Profile

Signature Profile is used in the following mobile signature service operations:

Additionally, the Signature Profile is linked with two other profiles: Registration Profile and Certificate Profile. Registration Profile defines requirements for the registration process and Certificate Profile defines what kind of certificate is created.

Analysis of Signature Profile

ETSI TR 102 206 provides analysis of what is the meaning of the Signature Profile. Basically, the Signature Profile can be described by any means that is found appropriate by both parties (the MSSP and the AP), which can be defined by using URI representation. General requirements for the content of Signature Profiles can be defined as follows:

Information about the registration method and assurance such as:

• Face to face or remote registration
• Level of security of user credentials or related protocols
• Verification and issuance of user’s identity
• Quality and issuance of keys

Information on the Secure Signature Creation Device (SSCD) technical assurance:

• Signature policy
• Technical protection of the SSCD and platform
  • the Mobile SSCD (e.g. SIM card or other secure element), the Mobile Signature Creation Application (e.g. Mobile App) or the MSSP platform (e.g. server-side signature).
• Accreditation or declaration of conformity with a formal profile
• User Authentication mechanisms (password, biometric, etc.)

Uniform Resource Identifier (URI) generic syntax has been defined in the IETF RFC 3986.

Signature Profile URI

Conventionally Signature Profile URIs follow the “http URI-scheme (e.g. http://www.ficom.fi/something). Alternatively, there are a great number of other schemes available, which could be more descriptive than the http-scheme.

Unifying Signature Profile URI scheme

Today there are no semantic rules on how to construct the Signature Profile URI. Therefore, we need to consider what aspects could define a self-descriptive Signature Profile.

We have found four major aspects, which are:

1. Commercial name,
2. Signature Operation (or PKI Operation),
3. Level of Assurance, and
4. Secure Signature Creation Device

By using these four characteristics, we can define existing Signature Profile URIs, these URIs are conveniently short and easy to understand.

Therefore, we recommend to use the new mss-scheme base URI, which would be constructed as follows:

mss:<Commercial service name>:PKI operation:LoA:SSCD

Cryptographic algorithms (RSA, ECC or key lengths) are not included in the base URI. Related details can be added as URI extensions using either query strings (for example “?ECC=true, AlgECC=NIST-256, RSA=true, RSAkeylen=2048”) or URI fragment (#ECC etc.)

Signature Roaming and Signature Profile

It is easier for the AP that they do not need to know the MNO who provides the service. That means that the MSSP can redirect a mobile signature to the correct MNO and use the correct Signature Profile regardless of the number of available Signature Profiles. Therefore we recommend that if the commercial name differs then the MSSP can convert the commercial service name when roaming between MNOs.

Therefore, we recommend that the mobile signature functions, LoAs and SSCDs would be unified at least in same market areas. Basis for these definitions would be:

Conversion from different commercial names to a complete base URI may also be possible even though we do not recommend it. This would mean easily lots of confusions when the commercial names would need to define all mobile signature capabilities.

Simplest interoperable URI examples