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:
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 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 chould 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:
- Commercial name,
- Signature Operation (or PKI Operation),
- Level of Assurance, and
- 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:
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). |
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 |
MID Switzerland | |
---|---|
SIM as SSCD | |
http://www.swisscom.ch/mid/v1/AuthenticationProfile | mss:mid.ch:authn:LoA4:sim#v1 |
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 |