Methics registers “mss” URI Scheme

IANA today registered provisional URI scheme “mss” published by Methics. The “mss” scheme defines the URI for SignatureProfiles used in 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:

Operation Definition
Signature Request The relying party (or AP) is requesting this signature profile to be used in the processing of the transaction
Signature Request: Signature Profile Comparison If set to “exact”, then the MSSP is asked to match at least one of the specified <SignatureProfile> elements of the MSS_SignatureReq message exactly; If set to “minimum”, the MSSP is asked to use a profile that he feels is at least as good as any specified in the <SignatureProfile> element; If set to “better”, the MSSP is asked to use any profile better than any that were supplied.
Signature Response The MSSP should make a statement of the Signature Profile that was used (optional).
ProfileQuery One or several Mobile Signature profiles supported by this MSSP for the mobile user.

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
Signature Profile consists of four major security aspects.

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

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:

LoAs Description Notes
LoA2 LoA2 [.extension] Extensions may define additional
LoA3 LoA3 [.extension] requirements like specify identity attributes
LoA4 LoA4 [.extension] or registration mechanism
PKI Operation Description Notes
sign Plain text signing
authn Authentication
encrypt Encryption
pop PKCS#10 PoP
popo CMP/CRMF PoPo
consent Consent signing
anonymous Authentication Restricts identity attributes (e.g. Age)
digest Digest signing



SSCDs Description Notes
sim UICC and SIM cards Including eSIM etc
app Mobile App
se Integrated token (USB, SSP) Removable token
server Server-side signing



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.

FICOM Finland
Anonymous authentication Current URI New URI
http://mss.ficom.fi/TS102206/v1.0.0/anonymous-profile.xml mss:ficom.fi:anonymous:loa4:sim
Authentication
http://mss.ficom.fi/TS102206/v1.0.0/authenticationprofile.xml mss:ficom.fi:authn:loa4:sim
Signature of plain text content
http://mss.ficom.fi/TS102206/v1.0.0/signature-profile.xml mss:ficom.fi:sign:loa4:sim
Signature of digested content
http://mss.ficom.fi/TS102206/v1.0.0/digestive-signatureprofile.xml mss:ficom.fi:digest:loa4:sim
Issuing consent
http://mss.ficom.fi/TS102206/v1.0.0/consent-profile.xml mss:ficom.fi:consent:loa4:sim
Operator authentication service (operator’s internal service)
http://mss.ficom.fi/TS102206/v1.0.0/operauth-profile.xml mss:operator:authn:loa4:sim
(or use MNO’s name as the brand).
MID Switzerland
SIM as SSCD
http://www.swisscom.ch/mid/v1/AuthenticationProfile mss:mid.ch:authn:LoA4:sim#v1


GSMA Mobile Connect
Mobile Connect LoA2
http://mobileconnect/something/LoA2 mss:mobileconnect:authn:loa2:sim

mss:mobileconnect:authn:loa2:app
Mobile Connect LoA3
http://mobileconnect/something/LoA3 mss:mobileconnect:authn:loa3:sim

mss:mobileconnect:authn:loa3:app

Simplest interoperable URI examples

Smallest Signature Profiles which match every previous schemes
Authentication LoA2 mss::authn:loa2
Authentication LoA3 mss::authn:loa3
Signature LoA3 mss::sign:loa3

Tagged with: , ,