A | Error patterns
What does the error message “Serial Number Mismatch. We strongly advise to go through the Pre-Signing Process in order to retrieve the actual StepUp SerialNumber”. This error message indicates that in a PWD/OTP process the password was reset and re-selected without performing a new identification with the corresponding step-up process according to the Reference Guide.
I authenticated correctly with PWD/OTP, Mobile ID or Mobile ID App – but the signature didn’t work … what could be the reason?
- You have set a new password for the PWD/OTP procedure. This may only be carried out in exceptional situations at an internal registration authority and must otherwise always take place as part of a new identification.
- You had previously authenticated with PWD/OTP and you have now activated your MobileID with a Swiss mobile phone number or internationally by use of a Mobile ID App. In this case, a new identification must also take place because the means of authentication belonging to the identity has changed.
- You have changed the SIM or the mobile phone provider. As a result, the MobileID authentication has changed when using a MobileID. A new identification is also necessary for this.
- If none of these causes are present, you should open a ticket.
Often the messages refer to the missing integrity, i.e. the document shows changes after signing the document. For example, elements from the network were downloaded and inserted later. This can be avoided by consistently using the latest version of the PDF/A standard PADES for the signature. In order to build up correct PADES documents please follow this link here: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation
It should be noted that the EU validators are far from harmonised. This means that test portals can present an electronic qualified signature as “invalid”, even though it meets the requirements for eIDAS dating. Harmonisation is being worked on by the EU.
“Signature is valid but the signer’s identity validity could not be verified” is Adobe’s statement if no LTV format was used. The background is that Adobe then tries to check the validity of a 10 minute certificate. If no long-term validation format was used, which stores the validity information at the time of the signature, these can no longer be accessed after some time. Therefore, signatures with short-term certificates (but also signatures with long-term proof) must always be saved in LTV format. You can find more hints here: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation
This message is triggered in two cases:
a) In case you have just been identified with the Swisscom RA app and a change has taken place before with your authentication method (SIM card/contract change, Mobile ID reset, password for the signature has been changed, change from PWD/OTP to Mobile ID)
In this case, everything is OK, and you can continue to sign as usual up to level qualified.
b) In case new Terms & Conditions are available that must be accepted and a change has taken place with your authentication method since the last successful signature (SIM card/contract change, Mobile ID reset, password for the signature has been changed, switching from PWD/OTP to Mobile ID)
In this case, you must be re-identified in order to be able to make qualified signatures.
The verify call which checks if a person is well-known to the RA-Service returns the following error code:
“message”: “Cannot check jurisdiction of unknown user with msisdn XXXXXXXXX”,
B | Identification in general
In Switzerland, Swisscom continously expands the possibilities to enable identification in the Swisscom shops. We will report about this on this main web page. Abroad, identification will only be possible via partners who offer this. In the medium term, Swisscom is looking for a connection to existing identities (e.g. identity verification online by a bank or a state eID, like the German Personalausweis or SwissID).
An RA agency is associated to a storage area (a so-called “tenant”) in which only those persons identified by the RA master agent or other RA agents of its agency are managed. The RA-Master Agent has access to this tenant and can appoint any identified person of this tenant as a RA agent.
If a person was identified by another method of the Smart Registration Service (e.g. video identification in the EU), the RA-Master Agent cannot appoint that person as an RA agent due to the fact that he is associated to another tenant (the SRS tenant). The RA Master Agent must reidentify him by use of the RA-App.
The only exception is the very first RA-Master Agent: He is identified anyway by a person of Swisscom, Swisscom Partner or e.g. a video identification and thus ends up in the “wrong” tenant by default. When the agency is set up, the named RA master agent is searched and moved to the correct new tenant of the RA agency. However, further postponements are not possible.
C | RA-App
Please find a table with all accepted ID documents and passports:
This happens indirectly. In practice, the procedure is as follows: The RA agency first appoints a RA master agent. This agent is identified by Swisscom or a Swisscom partner and undergoes training. He then receives a user interface with which he can turn other persons identified by him alone into RA agents or RA master agents. However, they must also undergo an automated requested e-Learning training.
In principle, Swisscom must retain the data for a very long time (11 years in Switzerland or 35 years in the EU). But persons can be deactivated by the RA master agent or by Swisscom so that they can no longer sign.
On average, an identification is completed within 2 minutes.
Hold the camera up so that the entire ID document is captured by the cut-out (still blurred if necessary). Move the camera slowly closer to the badge and it will start to focus again.
RA agencies act on behalf of the Swisscom registration office. In addition to the duties of careful execution of the registry’s activities, data protection is also a priority. The data protection principles from Art. 28 DSGVO apply, which are reflected in precise form in the technical-organisational measures (TOM) in the RA Agency contract. They are based on 2 sections of Art. 28, which reflect the use of the app on the mobile device:
- The measure must “ensure the ability to ensure the confidentiality, integrity, availability and resilience of the systems and services in connection with the processing on a long-term basis” and
- Include a procedure for regular review, evaluation and evaluation of the effectiveness of technical and organisational measures to ensure the security of processing.
- The controller and the processor shall take steps to ensure that natural persons under their authority who have access to personal data process them only on instructions from the controller, unless they are required to do so by Union or national law.
This means that in addition to the use of carefully selected and trained employees, the protection of the app on the mobile device and also the protection of access must be guaranteed. Are the devices adequately protected against viruses? Will it be prohibited to download programs from other app stores that do not offer sufficient protection? Do employees keep their PINs and passwords secret? Are devices not rooted?
The most important task of the RA agent is the strict examination of the identification documents submitted to him and in particular the strict verification of the field information read out by OCR from the ID card / passport as well as the correct recording of the mobile number.
Based on data protection laws we do not offer any RA Agency contracts with RA Agencies outside of the mentioned jurisdictions. RA Agents working in jurisdictions other than EEA/EU/CH shall not identify people which are residents of EEA/EU/CH.
Make sure that you have not registered the person in the RA-App Demo Mode (mobile number +41001234567, company “demo”).
Check the Service Status page (https://trustservices.swisscom.com/service-status/) to see if there are any faults. If no SMS arrives after another attempt, please inform the support.
If you are already registered (with RA app or the Smart Registration Service), you have to observe the following:
- If you already use the Mobile ID on SIM card and want to use the Mobile ID app, you should use the recovery code when activating or to authenticate with the Mobile ID SIM at activation and not to activate as a “new Mobile ID”. Otherwise, this app will also be considered as a new method of declaration of will and you will need to be re-identified.
- The same happens the other way round if you want to switch from an installed Mobile ID app to the Mobile ID SIM card.
Typical error message in such a case is an error message with “serial mismatch”.
The Smart Registration Services tries 5 times all 3 days to send out the SMS again. Only if all attempts fail after 15 days a reidentification is necessary.
E | Authentication and declaration of intent in general
In Switzerland we switch Mobile ID to PWD/OTP fallback mode by default if the SIM card is not enabled for Mobile ID. In the eIDAS room work per default with the Mobile ID App (https://play.google.com/store/apps/details?id=com.swisscom.mobileid, https://apps.apple.com/de/app/mobile-id/id1500393675), but we can also enable PWD/OTP.
The Mobile ID app is based on the Mobile ID interface, which also offers authentication with fingerprint or face recognition. This app only requires an Internet connection during authentication and can therefore be used internationally. However, an international SIM card (mobile phone number) is still required for the setup of the app. See https://mobileid.ch .
In general, other authentication methods are also possible, but these must be approved by KPMG. This requires the signing of an onboarding support contract, which regulates the implementation concept and the execution of the audit. New methods must be authorized separately for ZertES and eIDAS.
Unfortunately, not. You have a new means of authentication which was not initially recorded with the identification. I.e. you must be newly identified using the MobileID.
No guarantee but it should work nearly everywhere – one can have a closer to this overview:
(Go to “Tarriff Check”, select an arbitrary subscription model contract type and the country)
With the MobileID app as an authentication means, you are independent of the SMS dispatch.
A 2-factor authentication is necessary for the qualified signature: “possession” and “knowledge”, i.e. only the possession (SMS) is not sufficient.
No, OTP is sufficient for advanced signatures.
The loss of the password leads to a new digital identity. The application providers can react to this and, if necessary, demand a new identification of the signer, e.g. with the RA-App.
Since both methods require a secret as well as the possession of the telephone number, no signature for the previously existing digital identity can be triggered once the telephone number has been transferred. This means that the person must be newly identified.
Since a fixed line number can practically not be assigned to a person, this is not possible. The SMS is intended to ensure that something is contacted that is solely and without exception assigned to the person signing the document.
Modern devices are equipped with WIFIcalling. These can also be used to sign in a WIFI zone. Without the Internet, however, remote signatures are not possible.
In the case of a MobileID, you can use a recovery code to transfer the MobileID to the new SIM (https://www.mobileid.ch/en/login). In the case of PWD/OTP and the same phone number, your authentication option also remains.
MobileID is always configured in combination with a PWD/OTP fallback solution, i.e. a password window is automatically sent. You can activate your MobileID on the platform https://mobileid.ch . If the MobileID app is used and activated, the MobileID app is used.
By default, Swisscom currently only offers these methods. However, the extension will be worked out in the future, so that biometric methods may also be possible if approval has been granted. In addition, Swisscom will optionally accompany the customer if it wishes to use an audited solution to permit an additional signature at the recognition authority. Additional costs will be incurred.
The basis of 2-factor authentication is the fact that both factors must be recorded in connection with authentication, i.e. no password may be chosen that only knows the subscriber application, but the subscriber himself has been identified with RA-App. Such an exception could only be imagined if the participant himself carries out a authorized identification by RA delegation and furthermore designs the authentication procedure in such a way that both factors (login, SMS release) are carried out in a short session. Both the own identification procedure and this session procedure must be described in detail in an implementation concept and requires a release by Swisscom and its auditors. Additional costs are incurred here.
If you have been identified and have previously used PWD/OTP:
- If you want to use the Mobile ID app, you must re-identify yourself
- If you want to use Mobile ID (Swiss mobile number), you must re-identify yourself
If you have been identified and have previously used the Mobile ID:
- If you now want to use the Mobile ID app (this will only be possible on a SIM card that does not support Mobile ID) and use the recovery code of the Mobile ID, you can continue to sign
- If you activate the app WITHOUT recovery code, you need to be re-identified
- If you want to use PWD/OTP, you must be re-identified
If you have been identified and have used the Mobile ID app so far:
- If you now want to use the Mobile ID of the SIM card (this will only be possible on a Swiss SIM card) and use the recovery code of the Mobile ID app, you can continue to sign
- If you activate the Mobile ID of the SIM card WITHOUT recovery code, you must be re-identified
- If you want to use PWD/OTP, you must re-identify yourself
This means that Mobile ID and Mobile ID App are coordinated authentication methods, PWD/OTP is a completely different authentication method. The remote signature always requires that the authentication means shall be included during registration (i.e. during identification). Therefore, in some cases, new identification will be necessary.
As RA agent you should inform Swisscom via the support page in the case the mobile phone was not properly protected against malicious attack (like password with 8 chars, etc.) or you were still logged in in the RA App since severe data protection problems could occur. In case of signatures you should cancel your SIM card, eventually change your access data and stop placing signatures till you receive your new SIM card.
Swisscom is not able to sufficiently guarantee the reception of the SMS. The only factor Swisscom is responsible is to send out the SMS as quickly as possible. Neither the reception conditions of the mobile signal nor the performance of the internal or external roaming partner can be controlled and is based on international telecom contracts and standards
The use of the sender’s name like “Swisscom” or similar would be useful for the recipient. But indeed we experienced that such SMS are very often treated as spam SMS by our roaming partners.
F | Validity of certificates
Yes, after 5 years, persons identified for advanced signatures must also be newly identified. However, for advanced signatures it is sufficient if the identity card was valid at the time of identification. If this expires within the 5 years, no new identification is necessary. For qualified signatures, on the other hand, an identification is valid for as long as the ID card was valid or for a maximum of 5 years after this identification. In special cases e.g. when bank identification is used the validity of an identification can also be restricted to a shorter period than 5 years if the regulatory requires it.
G | Possible applications
Yes, this is the sole task of the subscriber application, which then repeatedly sends the hash with the signature request to the All-in Signing Service. Any number of signatures can be generated for the same digital document.
Yes, but this requires 2 communication channels and setups, i.e. the signature must first be authenticated by the person signing via one channel (on demand) and then organizationally signed (with previously created static certificate) by an SSL authentication certificate via a second channel.
Yes, several documents can be signed with one approval within a session. At maximum ca. 250 signatures.
XML signatures according to XADES standard can be done based on seals but not on personal signatures (in the moment). In the client you have to prepare the XADES standard: The call of a “plain signature” must be implemented.
It should be noted that the EU validators are far from harmonised. This means that test portals can present an electronic qualified signature as “invalid”, even though it meets the requirements for eIDAS dating. Harmonisation is being worked on by the EU.
Only QES signatures can be validated. There are no validators for AES signatures.
Two user accounts (ClaimedIdentity) must be opened, each account is related to the respective signature type, i.e. the participant application must decide, over which account it sends a signature inquiry. Both accounts can be addressed via one interface, i.e. the same endpoint. There is a service fee per account. 2 invoices are issued at the end of the month. Therefore 2 service contracts with 2 different configuration and acceptance declarations must be submitted. If you have 2 legal areas and 2 billing types, you still have only one interface (technical), but 4 service access interface point and by this 4 times a service fee. It doubles again to 8 ClaimedIDs, if both signature levels (QES/AES) are planned with both billing types and both jurisdictions.
A lot of examples can also be found on our partner pages: https://trustservices.swisscom.com/partner
In principle, a time stamp also stores the zone (the offset). In this respect, all local programs will display the actual local time.
In principle, Swisscom provides a signed hash and thus supports PADES (PDF) formats and, in the case of organisation certificates, XADES (XML) formats. Word files are not signed and are not intended for this purpose by law.
No, only a common time stamp exists.
H | Interface integration and setup
Principally yes. In case of usage of the surname and given name it must be exactly the same as to be found in the ID or passport. But if this is difficult to implement the template feature can support (https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Distinguished-Name:-Use-of-Evidence-Attributes). This feature allows to take over the exactly first and last name which was used during identification in combination with the RA-Service (SRS).
Swisscom is also able to configure the service in a way that only a pseudonym is used instead of the surname and given name. Furthermore the “Common Name” (CN) could be used with the names usually used for this person (independent from the ID document). The RA-Service verify call verifies in this case the mobile number which was used during identification and the country. The use of the pseudonym in the verifyCall is independant from the use of the pseudonym in the signing request call.
Yes, there are several libraries available on the market that allow a quick implementation of a signature application. All of them also have special support for Swisscom Service:
- Intarsys, Germany: provides various solutions for handling and integrating signatures: https://www.intarsys.de/produkte/fernsignatur
Intarsys is a premium partner of Swisscom and knows the AIS service very well from a technical point of view and can provide consulting support.
- PDF-Tools, Switzerland: 3-Heights PDF Suite. http://www.pdf-tools.com/pdf20/de/produkte/pdf-security-signature/pdf-security/
- iText, Belgium: iTextPDF. https://itextpdf.com/de/products/product-tour. Swisscom uses iText in its examples, but the examples are “out of date”, i.e. some functionalities have changed. But the basic handling can be seen there: https://github.com/SCS-CBU-CED-IAM/itext-ais
- Setasign, Germany: Some customers are using SetaPDF, which also offers a special solution for Swisscom Service: https://www.setasign.com/products/setapdf-signer/demos/swisscom-all-in-signing-service/
- Blocksigner, Schweiz (Skribble.com): https://api.skribble.com/swagger-ui.html, http://doc.skribble.com/
Swisscom rejects any responsibility for the error free operation of these libraries. These may contain errors and require special knowledge and expertise. Use is at the subscriber’s own risk.
There is a test and demo mode that allows you to try out the app, but no data is transmitted. For this purpose, the mobile phone number +41001234567 must be entered in the registration form and the company name “demo”.
There is no support for screen scrapping as an interface. Developers could be confronted with the fact that the screens will be changed. It is also contradictory to the implementation of “sole control” between the signer and the signing certificate.
Yes, but only as iFrame, instructions can be find here: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide
No, see https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide.
Yes, as described in the Reference Guide (www.swisscom.com/signing-service ) under “Step-Up method” in the “Message” field, the text block with the heading to the message for the expression of intent and the language setting with “Language” can be configured within the framework of the protocol. For the SMS input window the language can also be set with the “Language” parameter.
The prerequisite for setup is a “declaration of configuration and acceptance” signed by the customer and verified by the global registration authority. This declaration contains the obligations of the operator of a signature application (e.g. the possibility of displaying the complete document to be signed, securing access to the service), but also the characteristics of the service.
Another prerequisite is an access certificate, which secures the communication of the signature application to the signature service.
After checking the document, our Setup Service receives the order to activate the service with the access certificate sent and the selected specification in the configuration and acceptance declaration. In the case of qualified signatures, the service is initially only activated for “advanced” signatures. Subsequently, the contact named in the configuration and acceptance declaration is asked for an example signature with the advanced signature. If this is faultless, the service is switched to the “qualified” level if required so. The customer will also be notified of this. He now has 10 days to report any irregularities directly to the setup team. If they do not receive any complaints during this time, the connection to the service is accepted. Further incidents can then be reported to Swisscom via 1st Level Support in case of a direct contact to Swisscom or to the reselling partner.
The access certificate can be a self-signed certificate. For example with openssl software.
Requirements for the Distinguished Name:
- CN=<URL of the subscriber system that performs the communication with AIS or other unique identification of the subscriber system>
- O=<Name of organization>
- Email=<E-Mail for notification purposes e.g. in case of end of validity>
- C=<Country of organization>
The following additional requirements shall be considered when preparing the certificate:
- Maximum term 3 years
- Hash algorithm minimum SHA-256
- Key length minimum 2048 bit
Special conditions still apply for access certificates within the framework of regulated (ZertES) or qualified (eIDAS) seal creation: The private key of the access certificate must be created on a cryptographic module in a joint ceremony of a Swisscom registration authority representative. This module must meet the requirements of FIPS 140-2 level 2 or similar, e.g. Yubikey, Feitan key or Microsoft Key Vault. Alternatively, a concept can be submitted on how the assignment of the access certificate to the person responsible for the organisation can be achieved in other ways.
In the case of a seal, in addition to the configuration and acceptance declaration by the operator of the signature platform, it also requires a certificate application for the seal certificate, an organisation certificate. In contrast to the certificate for the personal signature, the seal certificate is issued for three years. The certificate application must be signed by authorized persons of the organization. The authorisation can result from the register (e.g. procuration) or can also be a special power of attorney, which has been issued for example for the operators in the computer centre. Swisscom needs the proof of this power of attorney. These persons are also personally identified in advance by a representative of Swisscom’s registration office using RA-App. This could also be, for example, an RA agent of a reseller who has carried out the personal identification. This enables the person to sign the application using an electronic signature. The application is sent to Swisscom unsigned and Swisscom invites the persons to sign electronically. The next steps now differ depending on the type of seal:
Advanced signature: The applicant sends Swisscom an SSL certificate, which he wants to use as an access certificate for the interface to the seal.
Qualified/regulated signature: The applicant agrees a date with Swisscom for the joint creation of a private key. This must be created on a cryptographic device based on the FIPS 140-2 level 2 qualification or similar (e.g. Yubikey, Feitan Key, Key Vault HSM Microsoft, etc.) An access certificate is then created based on this key. I.e. for the signature process the access must be released by means of this certificate. Alternatively, a concept can be submitted on how the assignment of the access certificate to the person responsible for the organisation can be achieved in other ways.
The embedding of signed hashes should be the task of PDF specialists or corresponding libraries. The space for the signature must be precalculated. Please have a look to https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4.
The following solution can provide a solution. We present this here without guarantee, as Swisscom focuses only on the service and not on the signature application:
- Create a PDF with a blank and pre-filled signature field
- The byte range should be filled with zeros up to the expected size
- Calculate the hash of the document
- Sign the hash with the All-in Signing Service
- Fill the signed hash into the empty signature field
- Iterate to the empty signature field
- Determine the byte range of the empty signature field
- Calculate the offset of the byte range
- Open the document with the empty signature field in read-write mode and find the offset where the hash was inserted
It is also very important to follow the guidelines for the PADES standard and the Long Term Validation: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation
In the returned paramters of the Verify Call, the so-called “serial” is returned. Should this start with “SAS” (i.e. SASxxxxxxx), the customer will use the PWD/OTP authentication. If this starts with “MID” (i.e. MIDxxxxxx), the customer uses the Mobile ID procedure. However, it is not possible to distinguish between Mobile ID App and Mobile ID SIM Card.
Nevertheless, the results can be used, e.g. to provide special help texts (e.g. if the password is forgotten, etc.) to the customer, or to refer to the declaration of will on the mobile phone.
The verifyCall enables you to check if a signatory is already registered or not. If you choose the pseudonym you will need only the mobile number and country of the signatory. https://documents.swisscom.com/product/filestore/lib/4cce2074-46e3-4e43-a1b4-ccf5d5cb7ca5/VerifyID4Signing-de.pdf
PKCS#1 is only supported for CADES format and seals but not for personal signatures.
No, only PADES/CADES for seals and PADES for personal signatures.
It supports Swisscom to find a name for the ClaimedID (access to the signing service).
Yes, just tick the appropriate check box.
I | Performance
At the moment we are in the process of expanding our capacities with other algorithms (pre-generation of keys) and HW expansion. Since several customers use the service, we assume a maximum load of one request per second on average per customer. Higher performance, i.e. especially reserved capacities are optionally possible.
It is limited to 250 due to the security reasons rather than to the capacity of the service.
Please be aware that we installed a WAF in order to protect our service again denial-of-service attacks. If you want to fulfill some mass tests please contact us beforehand.
The signature must be signed with a declaration of will (authorization) by Mobile ID (SIM/App) or PWD/OTP. After sending out the request, the user usually has 80 seconds to enter the authorization. The value is not adjustable.
J | Billing
Each signature is calculated individually, i.e. in this example 5 signatures are calculated.
No, they are offered via two different ClaimedIDs and will be invoiced independantly.
Swisscom does not charge any costs for sending Mobile ID or SMS. Depending on the roaming partner’s tariff, costs may be incurred for roaming (which happens very rarely, e.g. on cruises).
Here two user accounts (ClaimedIdentity) must be opened, each account is connected with a billing method. This means that the subscriber application must decide for itself which account it will use to send a signature request. There is a service fee per account. 2 invoices are issued at the end of the month.
There are no costs for these months.
K | Data protection
The Distinguished Name contains either the person’s first name, surname and country of birth/registration or home country, or a pseudonym with a serial number that can be uniquely traced back to a person by the registry. Organisation names are only permitted in special cases
Switzerland is not in the EU and has therefore not introduced EU legislation, the so-called General Data Protection Regulation (GDPR). In reality, the GDPR is also applicable if the companies are based in Switzerland and offer services in the EU.
Swisscom is therefore subject to the same data handling obligations as all other organizations that have to comply with the GDPR:
- obtain the consent of the person whose data are processed
- “Privacy by design” and “Privacy by default” guarantee
- appoint a data protection representative
- create a list of processing activities
- report violations of data protection to the supervisory authority
- conduct a privacy impact assessment
All applications which concern data protection and are used for data processing, e.g. also the RA-App must be GDPR compliant. Swisscom provides information on this on its pages:
with corresponding data protection declarations according to GDPR.
Switzerland has always been and is considered as a secure third country pursuant to Art. 45 GDPR (data transfer based on an adequacy decision), i.e. the usual authorisations as with other third countries (e.g. the U.S.) are not necessary. Thanks to its Data Protection Act and the ongoing adaptation to the GDPR, Switzerland has an “adequate level of protection for the transfer of personal data” in accordance with EU criteria, i.e. it must in fact be treated as an EU country when transferring data:
As part of its ongoing audits, Swisscom must ensure that all the strict data protection requirements necessary for the issue of digital signatures are complied with, both vis-à-vis the certification authority in Switzerland and vis-à-vis the conformity assessment body in Austria. This means that, in addition to self-declaration, trust service providers and certification services are obliged by legislation and the international standards applied, such as ETSI 319 401, to demonstrate and have audited appropriate data protection for all personal data.
The data protection requirements to be demonstrated and audited also apply to the registration authority activities – a task of a trust service provider and certification service provider. Thus the RA app as part of the registration process must ensure data protection and privacy. The RA-App itself does not store any personal data permanently. No data can be exported either. As soon as the identification has been completed, the data is transferred signed by the RA agent as so-called evidence. This evidence is stored at Swisscom’s RA service under strict security conditions (e.g. 4-eye access). Only a few people have access to this data and may only pass it on based on a court order or are allowed to check the quality of the identification. According to the law, Swisscom has unlimited liability for the proper execution of the signature and thus also the identification.
RA Master Agents have web access to a portal in which they can view all persons identified by RA Agents with their surname, first name, expiry date of the ID document and mobile phone number. The ID documents and photos (so-called “evidence”) are not accessible or exportable.
With the RA app, Swisscom transfers the recording of identity data to an external service provider, which is referred to in the contracts as the “RA agency”. The GDPR requires in this case an order processing contract. The RA agency must therefore comply with the obligations for order data processing.
Compliance with the GDPR order data processing is also required in purely Swiss projects. There are two reasons for this:
- On the one hand, it can rarely be guaranteed that persons identified in Switzerland are not EU citizens who are subject to the market principle of the GDPR,
- On the other hand, the RA app cannot be used in such a way that only persons for Switzerland are identified, i.e. order data processing always takes place for Swisscom IT Services Finance S.E. in Vienna as well.
There are projects in which Swisscom relies on legally recognized and audited identification procedures with third parties. A typical example is a bank that carries out a presence identification of a person as part of its KYC process. In this case, Swisscom receives a copy of the bank’s data for its own business purposes (signature). Order data processing is not necessary here, as there are two parties responsible for the data. Conversely, the Joint Controllership Principle of the GDPR is not applied here either, as the responsiveness of data does not serve the same business purpose and both parties do not act responsibly in the sense of a common business purpose. The bank acts for its business purpose, e.g. opening an account, and Swisscom pursues its business purpose of issuing signatures. Nevertheless, in this case our contracts on the “delegation of registry activity” also contain a minimum of provisions on how to proceed regarding data protection and the GDPR.
In the case of a remote signature, Swisscom keeps and manages the keys to the signature certificates in trust. In the case of a personal signature, the signature certificates are only generated for the signature and lose their validity after approx. 10 minutes. Company certificates for seals are valid for up to 3 years. According to the law, the private key must be stored on a (qualified) signature creation device. The memory for this is a device which is mainly designed for key storage, the HSM (Hardware Security Module). It is subject to strict regulation, auditing, in terms of security standards and access to this device. Signatures in the EU and Switzerland are subject to particularly high security standards, which are only available from a few HSM manufacturers worldwide.
L | Legal and regulatory topics
Adobe is a U.S. American supplier of a software that can display PDF documents. The most prominent and widespread product is the so-called “Adobe Acrobat Reader”. This enables the verification of certificate-based signatures. Whether a signature is valid and thus displayed with a green tick depends on many aspects:
- Adobe has its own set of rules, which classifies issuing CAs from trust providers or certification service providers as “trustworthy”. These are listed in a so-called Adobe Trust List (AATL). Even if not included in the service description, Swisscom always endeavours to be listed here. In addition, the listed companies must pay annual fees for this entry and file in their self-assessment. According to Adobe, eIDAS trust service providers are considered trustworthy if they have also concluded a contract with Adobe.
- Adobe offers a variety of settings that can lead to a completely different validation: For example, instead of Adobe’s trust list, Microsoft Windows’ trust list can also be used, which usually only maintains trust service providers that also issue SSL or e-mail certificates. However, the check can also be based on a time given by the computer clock and not on the time stamp in the document.
This means that you cannot rely on the validity of a signature in Adobe, but you get information about whether changes have been made to the document since the signature was set and how the signature certificate looks like.
Both should be IT people who are familiar with the application. It does not have to be a person with the official role “Privacy Deputy”. Swisscom simply wants to retain the 4-eyes principle here. The roles are: To be able to provide information about the administration of the user application (who has access, what could an administrator manipulate, where might there be a hitch, SSL connection to Swisscom) and about topics such as virus protection, access control in general, etc. at the person responsible for security.
On the one hand, an internal company can become a Swisscom reselling partner for other companies in case there is a huge volume planned. In this case, the payment flow goes directly only through this individual company. One company can also assume complete responsibility for the operation of the subscriber application. Even then, invoices will only go through this company. It can then identify employees of the other companies.
If all companies want to operate the subscriber application independently (with their own liability and responsibility) and also want to provide RA agents themselves, a separate contract is required for each company.
Every year, Swisscom invests large sums in ongoing audits. However, to be able to place the offer of a trust service provider on the market at a reasonable price, this service is offered in a standardised form. That means in particular:
- The customer must adhere to the standard ordering process with the standard contract documents released by the auditors.
- Further assessments by participants and the examination and acceptance of own contract texts are not included in the offer.
Many aspects of the trust service provider are subject not only to conditions in the execution of the service but also in the specification of important obligations, liability regulations and cooperation services in the contract documents. Therefore, these contract documents are also subject to auditing or are also submitted to the state conformity assessment bodies. Therefore, no changes to the legal system can be accepted, nor can contractual enclosures of the participant be accepted, especially if they are subject to foreign, applicable law.
If it is nevertheless necessary to adapt contractual texts, add contractual regulations (e.g. your own Code of Conduct, Data Protection Declaration, NDA, etc.), process special assessment questionnaires or if you have even discovered errors or unclear formulations, please report these to our product management.
If any errors or ambiguities are apparent, a corresponding change process is initiated by product management and implemented as quickly as possible.
For the evaluation of other questions, a processing team is formed that draws on the relevant experts (e.g. legal department, security officer, compliance officer, etc.) and carries out an evaluation of the request. A project specific fee of CHF 6,000 is due for this. If the team of experts was not able to work out a solution directly, it will prepare an answer and an offer, which will present and assess further steps on the part of Swisscom.
No, only for the operation of the signature application no certification and no audit is required. Within the scope of a “configuration and acceptance declaration”, the customer makes a self-declaration to operate the signature application properly, i.e. not to exchange the hash of a document and to actually display the document to be signed to the customer (WYSIWYS = “What you see is what you sign”). Data traffic between the signature application and Swisscom should be encrypted and basic protection against viruses and attacks should be guaranteed as with any other system. An official audit with certification can only be necessary if the system has its own identification, especially in relation to its own authentication method. In Switzerland, identification with Swisscom authentication methods can be dealt with in a simplified manner by means of a suitable “implementation concept” submitted by the customer and approved by Swisscom; in the EU, an official audit is generally necessary. As a rule, an authentication method must always be certified, as this should ensure “sole control” to the signing certificate (called “sole control” in the ETSI context).
In principle, the company must appoint representatives. These representatives should either be the registered representatives according to the commercial or business register, or employees with appropriate powers of attorney signed by the registered representatives. In any case, the persons must be personally identified with our RA-App. In Switzerland, only companies registered in the UID Register can order seals. With the seal, the SSL access certificate between the signature application at the customer and Swisscom serves as authentication of the company. The access certificate must therefore be handed over by the representative of the organisation. With the advanced seal, simple delivery is sufficient; with the qualified seal, a joint handover ceremony takes place at which the access certificate is jointly generated. The private key must be stored on a cryptodevice (FIPS 140-2 level 2 minimum).
In principle, Swisscom has unlimited liability under the law for the incorrect issue of qualified certificates. In the case of advanced certificates, this liability can be limited. Swisscom is also compulsory insured for this purpose. In the event of errors in the signature application (e.g. the exchange of a hash of a document) or errors in identification by third party registries, Swisscom in turn will hold these third parties liable. In order to avoid the risks of liability, high demands are placed on the issuance and contract process and the possibility of auditing the third parties involved is generally required.
Swiss legislation, i.e. the Swiss Federal Electronic Signature Act (ZertES/SCSE), provides the requirements organizations have to fulfill in order to be recognized as a certification service. The accredited accreditation body for the accreditation of Swisscom as a certification service in Switzerland is KPMG (Accreditation No. SCESm 0071). It issues a conformity assessment certificate (available at www.swisscom.com/signing-service). The Swiss Accreditation Service SAS maintains a list of accredited certification services:
With the entry into force of the Regulation on Electronic Identification and Trust Services for Electronic Transactions in the Internal Market of the European Union (eIDAS), the basis has been created for legally valid electronic communication and secure electronic identification throughout Europe. With the help of trust services such as electronic signatures, seals, time stamps, delivery services and certificates for authentication, companies, administrations and private individuals can exchange digital documents such as offers, orders, contracts etc. within the European Union on a uniform legal basis. Thus, the new EU regulation replaces the national signature law and signature regulations.
Under this Regulation (EC) No 910/2014/EU (eIDAS Regulation), national Trusted Lists have a constitutive effect. In other words, a trust service provider and the trust services it provides will be qualified only if it appears in the Trusted Lists. Consequently, the users (citizens, businesses or public administrations) will benefit from the legal effect associated with a given qualified trust service only if the latter is listed (as qualified) in the Trusted Lists.
Swisscom’s subsidiary in Austria “Swisscom IT Services Finance S.E.”, Vienna have been included in this list of trust with qualified certificates and seals:
Swisscom IT Services Finance S.E. has mandated Swisscom (Switzerland) Ltd to operate the trust service and has also delegated the registry authority activities to Swisscom (Switzerland) Ltd. Swisscom (Switzerland) Ltd. thus offers the service to the market and also accepts contractual documents on behalf of Swisscom IT Services Finance S.E..
Swisscom can only confirm that it can issue qualified signatures in both legal systems in accordance with the eIDAS Regulation of the EU and the ZertES Act of Switzerland. The qualified Swiss signatures are only recognised as qualified in Switzerland and the eIDAS qualified signatures in the EU.
Whether the qualified signature is compliant for any contract must always be verified by a lawyer. Swisscom may not provide any legal information in this regard. This is not only related to the signature, but also to other points that may be agreed in contracts. For example, the requirement for “return by registered mail” may mean that an electronic signature cannot be executed at all, as a postal paper route is mandatory.
In both the EU and Switzerland legal systems, the reversal of the burden of proof (and in Germany also prima facie evidence compared to visual evidence) applies in principle to qualified signatures. This means that an opposing party must prove that the qualified signature was not properly executed if it is contested. And, of course, Swisscom can provide KPMG-certified verifications to prove that the qualified signature has been duly executed.
The retention periods for identity verification and the activity journal and thus also the periods of proof are 11 years in Switzerland and 35 years in the EU. Swisscom generally uses the long-term validation standard of ETSI (LTV).
Long term validation means validating a signature in such a way that it remains valid for a long time. The LTV validation only allows validation as long as the root certificate for the timestamp has not expired. It is therefore advisable to time stamp the documents again before expiration if long-term evidence is to be preserved, so that the integrity and meaningfulness of the signature evidence continues to be ensured.
In principle, PDF documents should also be managed in secure archives. A situation can arise in 5, 10 or 20 years in which the signature algorithms are “cracked”, i.e. the integrity or authenticity could no longer be guaranteed. Good archiving systems therefore provide for regular resignation, e.g. with a time stamp, which always uses the latest algorithm and thus ensures the integrity of the document.
The web offers different links with optimized procedures for this, e.g. “Archisig”. The German BSI has also published a technical guideline “Preservation of the evidential value of cryptographically signed documents”. It is the specification of technical security requirements for the long-term preservation of the evidential value of cryptographically signed electronic documents and data together with the associated electronic administrative data (metadata).
A middleware defined for these purposes (TR-ESOR middleware) in the sense of this guideline comprises all those modules and interfaces which are used to secure and maintain the authenticity and to prove the integrity of the stored documents and data.
Experience has shown that transition periods can last from 3 months to 2 years.
After termination of the contract existing valid seal certificates will be revoked.
The way in which such a “shutdown” scenario is to be done is regulated by law: The CP/CPS of the certification service or trust service describes the exact procedures. There must be a shut-down plan, and the notified supervisory authority or OFCOM will usually appoint a successor who could offer the service to customers. This successor will normally also receive the Certificate Revocation List and thus the list of validity of the certificates, provided that Swisscom does not publish them itself. The list will continue to operate for years, so that the validity of signatures can continue to be verified. The evidence on the registrations for the service must be kept according to the retention periods even after termination over 11 or even 35 years, Swisscom or a designated successor must establish an archiving system for this, so that this information can also be used in legal negotiations. The identifications provided can no longer be used with a possible successor, i.e. new registrations are necessary in this case.
Electronic signatures may be presented as evidence in litigation. As a rule, with the exception of the qualified signature, they are subject to the free assessment of evidence. Since “simple” and “advanced” electronic signatures are hardly or only roughly defined by law, it is the court’s responsibility to accept such a signature or not. The party wishing to present these signatures as valid must provide the relevant evidence. In the case of Swisscom, it is helpful that the advanced signatures are also subject to a very strict audit according to the ETSI standard for “NCP+” signatures and thus such audit reports can be used. In the case of a qualified signature, the reversal of evidence shall apply. Since the qualified signature is precisely determined by law and, for example, both Switzerland and Austria offer validators for the validity of such signatures on the web, these signatures are considered valid until a party proves otherwise and thus also proves that the supervisory authority or OFCOM as well as the auditors have not complied with their obligations. After 11 years in Switzerland or 35 years in Austria, proof can also cause difficulties in the qualified field, as the documents for registration have to be destroyed. Nevertheless, the signature is still visible as “qualified”.
In the context of an evidence after many years, it should also be noted that electronically archived documents should be repeatedly time-stamped from time to time. It may happen that algorithms are no longer as robust. A timestamp seals the document with the latest algorithms, protecting the integrity of the document, including signatures.
Qualified eIDAS signatures are only considered “qualified” in the EU (and EEA) area, and ZertES/SigE signatures are also considered qualified only in the Swiss jurisdiction. This means that when a third state chooses the law, these signatures can no longer achieve their “qualified” effect or, if necessary, become. not even recognised.
Switzerland (QES), ZertES:
The CP/CPS provides that the identification and the stored documentation can be used for a maximum of 5 years, shorter if the validity period of the presented ID card/passport ends before the five-year period or if the identification procedure on the part of the auditor does not allow 5 years.
The retention period in accordance with Article 11.1 of the Ordinance of SigE/ZertES (activity journal) applies: “The recognised providers shall keep the registrations relating to their activities and the supporting documents relating to them for eleven years.” Swisscom also understands this period as a retention period for the documents submitted in the ID process, in particular a copy of the ID.
1 year reserve was added as a “safety buffer” in order to avoid Swisscom RA agencies being able to calculate the 11 years differently, which would mean that Swisscom would no longer have documentation in specific cases, especially in the application of Article 17 of the SigE/ZertES (Unlimited Liability).
Europe, (QES), eIDAS:
This is the same justification and derivation as in the case of QES in Switzerland only with the difference that in Austria the legal retention period is 30 years. Article 10.1 of the SVG (Signature and Trust Services Act) provides:
Access rights and retention period
10. (1) At the request of courts or other authorities, a qualified TSP shall grant access to the documentation in accordance with Article 24(2) lit. h eIDAS-VO and its certificate database.
(3) The documentation is provided by the qualified TSP for 30 years, calculated from the date qualified certificate entered at the end of the validity or, in the absence of such, 30 years from the date on which relevant information on the data issued and received by the qualified VDA in the course of its activities is incurred.
Advanced Signatures (eIDAS, ZertES)
The CP/CPS provides that the identification and the archived documentation can be used for a maximum of 5 years, shorter if the validity period of the submitted card ends before the five-year period or if the identification procedure does not allow 5 years.
There are no legal retention periods in the area of AES, as the retention periods are not regulated by law. However, the ETSI standards provide for a period of 7 years. This information is derived from ETSI Directive EN 319 411-01:
6.4.6 Records archival
The following particular requirements apply:
NOTE: ETSI TS 101 533-1 [i.13] suggests provisions on how to preserve digital data objects.
a) The TSP shall retain the following for at least seven years after any certificate based on these records ceases to be valid:
i) log of all events relating to the life cycle of keys managed by the CA, including any subject key pairs
generated by the CA (see clause 6.4.5, item g));
ii) documentation as identified in clause 6.3.4.
1 year reserve was added as a “safety buffer” in order to avoid that Swisscom RA agencies could calculate the 11 years differently.
In the case of personal certificates, Swisscom only issues short-term certificates (so-called “one-shot” certificates) that have a lifetime of 10 minutes and are only used for one signature request. The probability that the certificate was compromised during these 10 minutes is practically non-existent. After that the certificate is invalid and cannot be compromised. Thanks to the long-term validation, the signatures with this certificate remain valid and can also be validated for periods of time after expiry.
If the entire CA (i.e. the root certificate) of the certification and trust service has been compromised, there is a process that Swisscom describes in its CP/CPS (see Downloads Area – Repository).
If a signatory loses his authentication medium or discovers that his identity has been determined incorrectly, our support team must be informed immediately. In a contractual relationship with one of our partners, please contact the partner with whom you have provided your signature or identification. He will then take further steps to block this identification. If a seal certificate has been compromised, please use the contact details provided at https://www.swisscom.ch/de/business/enterprise/angebot/security/digital_certificate_service.html#tab-revozierung.
- Contract orally closed: Very difficult to proof (only with witness of other persons)
- Signed by simple signature, e.g. a scanned signature image: Same problem. The process of generation of this signature must be analysed in court and due to the weakness of the procedure witness of other persons or other hints will play a major rule to proof the power of attorney.
- AES: for verification of a valid signature the parties have again to go to court. The court will ask a specialist to investigate the advanced electronic signature of Swisscom. Due to the audits Swisscom performed the specialist can benefit from it. Nevertheless the AES is more weak as the QES e.g. concerning the way to identify/register persons, the time of archival (only 7 years), and the 1 factor authentication for the signature in contrast to a 2-factor authentication (thus a stolen mobile smartphone could be used for a signature)
- QES: the verification of a valid signature can be done directly via https://validator.ch or https://www.signatur.rtr.at/de/vd/Pruefung.htmlParties have not to go to court in case of doubt. Only if somebody doubts generally the audited trust service and this will be a hard proof …. QES signature evidences and logs will be stored as long as foreseen for all commercial and tax documents in the business record: more than 10 years in Switzerland and 35 years in the EU.
Due to the GDPR regulations and the fact that subsidiaries are not automatically part of any data processing agreement we need to sign with each subsidiary an extra RA Agency contract.
We recommend the use of the PAdES LTA standard (see ETSI TS 103 172) for purpose of longterm validation. Please find more hints here: https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation . PDFs should be in compliance with the PDF/A standard.
In the case of a remote signature, Swisscom manages your keys for the signature certificates in trust. With a personal signature, the signature certificates are only generated for the signature and lose their validity after approx. 10 minutes. Hereby we avoid the notification of a compromise of the certificate by the signatory, i.e. a certificate cannot be compromised. The procedure has several advantages:
The end user does not need to contact Swisscom (e.g. a user account to revoke certificates).
The recipients of signed documents do not have to deal with revocation lists and OCSP (online certificate validity check).
Security problems with applications that only rely on regular revocation list updates are avoided.
OCSP queries lead to time delays for the recipient.
In addition, a short-term certificate always provides a positive response – an OCSP query can only ever provide a negative response.
Important, the signature that was made with the QES is of course still valid, regardless of the certificate.
The short-term certificates are issued based on registrations of the registration service, i.e. they are based on strong authentication. A short-term certificate is only generated if there is authentication (release) in the 2FA procedure.
Example for analogy in the paper environment: I sign a contract with an ink pen. The ink in the pen is empty after the signature. The contract remains valid, of course.
When signing with a QES, the following evidence archival periods apply:
The retention periods for the identification evidence and the activity journal for EU signatures in Austria (where we are accredited) are 35 years and 10 years in Switzerland.
Due to the PAdES B LTA standard, signatures can also be validated a long time after expiry on the basis of short-term certificates.
The algorithms for hashing (checksum formation) and encryption of the hash follow the recommendations of the ETSI standard ETSI TS 119 312, which in turn also follow the NIS standards. These algorithms have certain assumptions about periods of 1->6 years in which they are stable. However, developments (e.g. cracking of algorithms) can also quickly lead to changes here. Swisscom Trust Services, for example, is now changing its root CA again to comply with the requirements > 6 years. A new edition of the specification is expected again this autumn.
For long-term validation, it is therefore necessary to regularly ensure integrity on the basis of the latest algorithms, e.g. annual time stamping of all documents or use of appropriate archiving solutions. Keyword “preservation of evidentiary value” – see DIN 31647:2015-05.
M | Mobile ID and Mobile ID app
N | Docusign Connector
Beyond the general Docusign license you have to purchase via Docusign or a Docusign reseller the “Docusign Express SKU” and ask the Docusign support to enable the Swisscom PEN in the UI (this is the selection box for the Swisscom QES/AES). Additionally you need to sign a Swisscom Signing Service contract and order the Docusign connector.
“You don’t have the correct assurance level to sign this document. Please contact the RA Agent of your company” will be shown as error message.
The complete check of all signatures in the validator shows that at least one signature is not valid and does not follow the rules of eIDAS regulation or SigE/ZertES law. This is the reason because the Docusign application adds in addition to the Swisscom QES an Entrust seal which does not follow the legal rules. In the total check conclusion the result is negative because one invalid signature was found. Nevertheless the QES signature is of course valid at court. If wanted you can ask Docusign support to eliminate the Entrust seal.
The Docusign validator will be no longer maintained and is in the moment not capable to support any Swiss electronic signature.
Please discuss with your Docusign support. Swisscom offers always one connector per “Docusign Customer Account ID”
Signaturprobleme selbst beheben
Certificate generation with OpenSSL
What is a claimed identity
It is a pity that we have not yet been able to provide you with the answer you need. Our support team will be happy to help you.
We are glad that we could help you.