FAQ

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?

Causes are:

• 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:

{

“statusCode”: 404,

“message”: “Cannot check jurisdiction of unknown user with msisdn XXXXXXXXX”,

“exceptionClass”: “EvidenceVerificationException”

}

This means that the person is unknown to the RA-Service. It could be that this person is probably identified but did not accept the SMS with the Terms of Use. After a short while (ca. 2 weeks) the person’s data will be deleted.

On this Signature Check page you can check at any time whether you can sign electronically or whether you need a new registration:

https://check-signature.scapp.swisscom.com/

If the result is positive, you will be shown with which signature type (QES, FES) and in which legal area (EU, Switzerland) you can sign electronically.

In case of a negative result, the reason for a new registration and identification for the electronic signature is displayed.

Translated with www.DeepL.com/Translator (free version)

To be able to sign electronically, you must be registered with a trust service. This service must uniquely identify you with special auditing procedures on site or remotely and give you a means with which you can approve signatures in the future, a “digital pen” for signing, so to speak. This saves you having to identify yourself every time.

The approval means (technical language also “authentication means”) can be the following:

• An app on your mobile phone that is automatically activated every time you want to perform an electronic signature. This asks you, for example, for a fingerprint on your mobile phone’s fingerprint reader (“Fingerprint”) or a picture of your face (“Face-ID”). One such app is e.g. Mobile ID, which Swisscom provides to you free of charge. If you do not live in Switzerland, you must first download the Mobile ID app from your app store and install it on your mobile phone before you can use it to register. In Switzerland, a Mobile ID application is very often already installed on Swiss SIM cards, which may only need to be activated via the Mobile ID website.
• If you do not want to install an app, the signature app will ask you for a password instead and send you an SMS with a one-time code that you must enter in a suitable input field of the signature app. The password is set for the first time in the registration process. You can use this procedure directly to start the identification process with our partners, but you always have to know your password well for each signature!

You therefore often have to deal with 2 apps or two programmes:

• The app or programme of our identification partners that identifies you. You will not have anything to do with the app or programme for a long time after In the case of an app, you can also uninstall it from your mobile phone again, provided your registration went well!
• The app or password-one-time code combination you will need later to approve the signature. This is used for the first time during the identification process so that your identification is linked to your personal approval So it is ensured that the “digital pen” belongs to you!

The law also stipulates that you must accept the terms of use of the trust service. We take advantage of this circumstance and will have you sign these terms of use electronically during the registration process. This is the first time you use your means of approval and you can use it, for example, to set the password for the first time or to use the Mobile ID for the first time. The terms of use will be

• either already accepted during registration (e.g. in the Auto-Ident procedure of the company NECT in the EU),
• or following registration by means of a SMS message that we send you and in which there is a link to a website where the terms of use can be accepted.

Please note that some procedures have to check your data manually again in parallel in the background. A free operator must be available for this. For this reason, you may have to wait 15 minutes or longer for some automatic procedures.

Problems can occur at different points in the identification process, which is why an individual analysis can be very time-consuming and requires many specialists. Examples are:

• with our partner who carries out your identification,
• at our website host, which does not start your registration request correctly,
• when sending, delivering or receiving SMS by the respective telephone company(ies),
• when recognising your ID document, the camera, the NFC receiver module,
• with the app for identification or the operating system of your mobile device,
• on the release app,
• in the event of a rejection due to regulatory risk assessments,
• when transmitting & matching registration data ,
• etc.

As you can see, many bodies are involved in the process and finding individual errors can be extremely time-consuming and is not always possible in terms of time and personnel. Unfortunately, the procedures are also so complex from a regulatory point of view that, as a rule, 5-10% cannot always be completely registered remotely. With electronic identity, all countries are currently creating the conditions for this to improve in the future.

Please note that residence permits (CH), driving licences/driver’s licences, copies of ID cards are NOT accepted for identification, but only machine-readable ID cards/ID cards from the EU/EEA and Switzerland and otherwise only machine-readable passports. In the eID procedure for Germany, only the German identity card is accepted.

However, it is also possible that the security features or the data of your ID card could not be read correctly. Make sure that the illumination is good and try the identification again (free of charge) using the link in the confirmation e-mail (sender “Support Trust Services – GSD- TS”) that you received from us.

First try to access the Smartflow website and enter your mobile phone number. You will need a one-time code to log in, which will be sent to you by SMS. If this SMS does not reach you either, we are unfortunately unable to help you because your mobile number or your telephone company cannot or does not want to receive our SMS at the moment. You will be refunded your identification expenses. Nevertheless, please provide us with your mobile number so that we can contact the telephone companies accordingly for the next time.

If the SMS has been received, you can accept the terms of use on the page indicated.

First try again free of charge via the link in the confirmation e-mail (sender “Support Trust Services – GSD-TS”).

If the identification does not work again, ask for a voucher for a video identification free of charge according to the 3-step self-support procedure or get a refund of the amount paid when paying by card. An operator can guide you through the process of video identification better than an automated procedure can.

Have you already received an SMS with a link to the terms of use of Swisscom Trust Services and have you already accepted them? If you cannot find the SMS, go to the Smartflow website and log in with your mobile number and try to accept the terms of use there. If this is not possible, repeat the entire process free of charge via the link in the confirmation e-mail (sender “Support Trust Services – GSD-TS”).

If the identification does not work one more time, ask for a voucher for a video identification free of charge according to the 3-Step Self-Support or have the amount paid refunded when paying by card. An operator can guide you through the process of video identification better than an automated procedure can.

After triggering an identification, you will receive a confirmation e-mail from us (sender “Support Trust Services – GSD-TS”). This also contains a link to repeat the identification free of charge. If you do not find this e-mail, please check the “SPAM” folder in your e-mail box. Perhaps it was mistakenly classified as “SPAM”. Otherwise, there may have been a technical problem. Get a new voucher via the 3-step support procedure.

You can test free of charge whether you are ready to sign: Check Signature (swisscom.com)

We know that especially the repayment is of course not very satisfying for you, because you want to sign electronically. Many partners also offer personal identification in the face2face procedure at their offices or branches. If necessary, ask your partner about this possibility. In Switzerland, citizens can also benefit from this free of charge at Swisscom branches or at the partner Ylex. But here, too, you must be able to present at least a machine-readable passport or ID card from the EU/EEA or Switzerland.

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).

During identification, the means of authentication (e.g. specifically the mobile phone number) is queried. With this, a first signature is already executed (step-up authentication), typically the signature of the terms of use that have been accepted. This signature is transferred to the All-in Signing Service. This means that the All-in Signing System knows exactly the means of authentication.

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.

On this Signature Check page you can check at any time whether you can sign electronically or whether you need a new registration:

https://check-signing.trustservices.swisscom.com/

If the result is positive, you will see with which signature type (QES, FES) and in which legal area (EU, Switzerland) you can sign electronically.

In case of a negative result, you will find out the reason for a new registration and identification for the electronic signature.

Please find a table with all accepted ID documents and passports:

List of documents suported by the RA App

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.

There are no special instructions necessary, because the process is exactly the same as for a “live” identification with the RA App. The demo mode is described in the basic training for RA agents.

You can access the demo mode of the RA App by logging in with the following information:

• Mobile number: +41123456789
• Company name: demo

Correct. If a person does not have a machine-readable ID or passport, they cannot get identified with the RA app for electronic signature and therefore cannot use the signing service.

No. It is prohibited to scan copies of ID documents or passports with the RA App. The reason is that the security features cannot be checked on a copy.

No, this is not permitted. The RA App has been certified for face-to-face identification and may accordingly only be used in personal contact.

As Mobile ID is a personal authentication method, the user must activate it himself. The user should always activate Mobile ID prior to identification with the RA App or Smart Registration Service so that the user can use Mobile ID as an authentication method for signature. The user should follow the instructions on www.mobileid.ch menu item “MY MOBILE ID”. User can also find a detailed FAQ on the Mobile ID website

Notify your RA-Master agent and ask him to search the portal for the mobile number. You can resend the SMS with the terms of use by clicking on the link with the PDF symbol:

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 have confirmed the terms of use with PWD/OTP during identification, you have defined this method as a declaration of will method. Now, if you enable the Mobile ID app as a method, you can no longer sign until you have been newly identified.
• 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.

As far as you did not already accept the terms of use there is always the possibility to deny the terms of use. If you accepted the terms of use and also used our service we must record your usage log and registration data for a retention period of 35 years in the EU and 11 years in Switzerland. But you could easily stop issuing electronic signatures.

With the password/SMS code method, there is unfortunately no possibility of recovery; a user must be re-identified in any case after he has changed his password.

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:

https://www.swisscom.ch/en/residential/plans-rates/inone-mobile/roaming.html

(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.

The service is basically supplied for residents in the EU/EEA and Switzerland with mobile numbers from these countries. Reception on mobile numbers from other countries may not work or may be prevented by various countries. Within the framework of a project, Swisscom can be ordered to ensure reception in these countries via special SMS providers.

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.

In the standard case, after identification, the customer first receives the terms of use for Swisscom’s signature service. The customer confirms this and thereby triggers an initial signature of these conditions, in the context of which he can also define the password for the first time. So called “step-up authentication”.

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.

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.

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.

For signatures in the Swiss legal area: www.validator.ch  (Attention, the validator is not always up to date). For signatures in the EU legal area: https://www.signatur.rtr.at/de/vd/Pruefung.html

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.

Yes, e.g:

https://www.seantis.ch/blog/digitale-signatur-onegov-cloud/

https://www.bcge.ch/pdf/conditions-self-en.pdf

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

No, only a common time stamp exists.

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

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.

See https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4

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”.

No. Swisscom even requires that, when the PWD/OTP screen is integrated as an “iFrame”, an external person can check that it originates from Swisscom. E.g. the standard browser functions can be used which Swisscom publishes under its website link in accordance with Chapter 4 of the Terms of Use. For iFrame integration have a look to https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

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 3072 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.

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.

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.

Yes, a distinction is made between whether the signatories have agreed to the terms of use of Switzerland or the EU or both. All data is also processed by Swisscom (Schweiz) AG for Swisscom IT Services Finance S.E. in Vienna.

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:

Switzerland: www.swisscom.com/signing-service

Austria: www.swisscom.at

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:

https://ec.europa.eu/info/law/law-topic/data-protection/data-transfers-outside-eu/adequacy-protection-personal-data-non-eu-countries_en

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.

Swisscom is legally obliged to record personal data for the signature. It is therefore responsible for this data. This means that Swisscom cannot play the role of a data processor, even if it receives e.g. employee data from a customer company for the signature. Swisscom has a legal mandate like that of telecoms or postal service providers. Furthermore Swisscom has a legal contractual relationship with the signatories with the terms of use. In this agreement, the signatory also accepts the use of data.

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.

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: Link

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:

https://webgate.ec.europa.eu/tl-browser/#/tl/AT

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.

No.

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).

• As a summary the archival time is 17 years, which are also disclosed in the terms of use.

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.

(2) […].

(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.

• As a summary the archival time is 36 years, which are also disclosed in the eIDAS Terms of Use.

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.

• As a summary the archival time is 13 years, which are also disclosed in the eIDAS Terms of Use.

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.

1. Contract orally closed: Very difficult to proof (only with witness of other persons)
2. 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.
3. 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)
4. 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.

According to the eIDAS regulation, TSPs must be accredited nationally and follow the national laws, rules, and regulations given by the national Supervisory Body as far as no other EU-wide regulation has set out some rules, like the implementing decisions of the EU commission, e.g., for the ADES standards or the security levels of the eID or some rules from the eIDAS regulation itself. By this, every country has different national standards for their TSPs; for example, in Germany, the BSI must approve some aspects, or in France, the institute ANSII. In some countries, e.g., video identification is fully allowed. In others forbidden, and in third countries, only permitted with short-term certificates.

But the EU regulation eIDAS foresees that all qualified electronic signatures from any nationally accredited TSP in any EU country must be accepted by all EU members. Thus, a TSP accredited in France may sell their QES based on the French rules and regulations in Germany, and an Austrian TSP, such as Swisscom, has only to follow up the Austrian rules and regulations and may sell their qualified signatures in other EU countries. The EU trusted list is the standard anchor and confirms that a qualified signature issued by one of the TSPs listed there must be accepted.

With version 2 of the eIDAS regulations, the EU countries will try to harmonize more and more the parts of accreditation, e.g., the way to be registered for a service, and they even want to create an EU e-Wallet as a base for future identification for any trusted service.

You can find a detailed FAQ on the Mobile ID website for your troubleshooting.

Please have a look at the Mobile ID FAQ, where you can find answers to many questions about Mobile ID.

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”

It is possible to choose following languages  in the SRS-Video identification: German, English, Croatian, French and Spanish. The language par ameter must be added to the request. See the explanation in the integration guide: LINK

Please note also the service hours for french (8:00-16:00 Mo.-Fr) and (14:00-21:00 Mo.-Fr.) for Spanish . The wainting time can be for these two language up to 6 minutes.

No, after clicking the button, the process starts immediately. It is also not about whether the RA agent  “wants” to complete the e-learning. It is rather a question of whether you, as the responsible Master RA Agent, are of the opinion that further training would do the RA Agent good, as you have identified knowledge gaps.

In the Admin Portal, you can only view the users who have been identified by your “own” RA agents with the RA App. If you cannot find an identified person in your RA agency, then this person is either not yet identified for the electronic signature or has been identified by an RA agent of another RA agency, e.g. in a Swisscom shop or via video identification.

For data protection reasons, you can only  search users in the admin portal using their mobile number. When searching, you need to enter the mobile number of the person that was stored during his*her identification process.

No, it is not possible to obtain a list of all users of an RA agency from the Admin Portal for data protection reasons.

As a Master RA Agent, you will only see the RA Agents and Users of the RA Agency you are currently logged in to. The name of the RA agency is displayed at the top right of the Admin Portal. For legal reasons, the two RA agencies must be kept separate.

There is no “Resend T&C” button in the menu tab of the “RA Agents”. The “Resend T&C”- button only exists in the menu item “User” to remind the user to accept the terms of use of the signing service.
Note: The RA service automatically sends reminders to the identified persons for the acceptance of the terms of use, every 3 days, up to a maximum of 5 SMS. An identified person therefore has a total of 15 days to accept the terms of use. If they do not do so, the record is deleted and the person must be identified again.

In the list of “RA Agents” there are the green little boxes with a link, e.g.:

If you click on this box, the link to the e-learning or to the duties is copied to your clipboard and you can send the to the prospective RA agent, e.g. via e-mail, chat, etc.
However, the RA Service automatically sends reminder SMS’s for the e-learning to the prospective RA agents every 3 days, up to a maximum of 5 SMS. If the prospective RA agent does not complete the e-learning and has not accepted the duties within 15 days, the role assignment is deleted by the system and you as Master RA agent have to repeat it.

Yes. The date of the identification (“created date”) is relevant, whether a user entry is displayed in the admin portal.

You can only click on the button “Register as agent” when the user has been identified, he*she has accepted the terms of use of the signing service and there is at least one green bar in his*her user entry. The user must have the status “Confirmed & Signed”.

Yes. That is possible.

No, all entries and also entries in the Admin Portal are not case-sensitive.

It is not necessary to withdraw a user’s authorisation to sign electronically (archive), as the registration is personal and the user can also use his registration with other signature portals.
If you still want to revoke the user’s authorisation, click on the small red server symbol next to the corresponding user entry; the entry will then be archived and the user will no longer be able to sign.

Yes, you can remove an RA agent by clicking the “Delete agent” button in the RA agent entry in the admin portal.

Yes, people from outside the organisation can register for the QES in the selected Swisscom Shops. As an RA agent, you can of course also register persons from outside the organisation with the RA App. As a Master RA Agent, however, you may not assign the RA Agent role in your RA Agency to persons from outside the organisation.

Option 1: Register the person again with the RA App. Then, this person will appear in the admin portal of your RA agency among your users and you can assign the desired RA agent role to them.

Option 2: The person registers via video identification or in the Swisscom Shop and reports it to you. Then you inform us via the contact form [link] that this person should become an RA agent in your RA agency (select option: appoint “invisible” user as RA agent). Please be sure to include the name and mobile number of this person. Then, we will take over the role assignment and give you feedback.

As a Master RA agent, you cannot assign the person to another RA agency yourself, but we can assign users the role of “Master RA Agent” in your RA agency. To do so, please give us the name and mobile number of this user via our contact form [link] (select option: appoint “invisible” user as RA agent). We will then take over the role assignment and give you feedback.

Standard RA agents: can identify and register persons for the electronic signature with the RA App.

Master RA agents: can also log into the admin portal and manage the users, RA agents and Master RA agents of their own RA agency. Furthermore, Master RA Agents are first point of contact for their Standard RA Agents, if they have any questions or problems. Master RA agents can contact us with questions and issues via the contact form [Link].

Having two Master RA agents is very useful. You do not necessarily need to appoint more Standard RA Agents, as Master RA Agents can also identify people with the RA App. However, we generally recommend a good mix of Standard and Master RA agents in your RA agency.

Yes, this is possible without any problems. To become a Master RA Agent, the person must be identified via the RA App. It does not matter which RA agency the RA agent who performs the identification belongs to.

It is just that you will not see the user entry of this person under your own users in the admin portal afterwards. Therefore, you cannot assign the role of Master RA Agent to this person yourself; we would have to do this for you. A notification can be made via the contact form [link] (option: appoint “invisible” user as RA agent).

No, a Master RA Agent may never assign the role of RA Agent in his RA Agency to persons outside the organisation. If desired, the client could conclude a separate RA agency contract with Swisscom.

As a Master RA Agent, you can appoint external (e.g. temporary) employees as Standard RA Agents if the said employee works on behalf of your organisation and also has a valid contract with your company or organisation.

Please do not forget to delete the role “RA Agent” for this external employee if he or she is no longer working for your organisation.

You may act for the company that has a valid RA agency contract with Swisscom and whose Master RA agent has appointed you as RA agent. The prerequisite in each case is that they have a current contract with this company, e.g. an employment contract, temporary or fixed, a project assignment or similar. If a person works for two companies, then both companies must have an RA agency contract and that person must have an RA agent role in both RA agencies so that they can also identify people for both RA agencies.

Please note: As an RA agent, you can identify people as you wish, including people from outside companies or individuals. It is simply not allowed to have non-company RA agents working for an RA agency.

It often happens that an RA agent reports to the Master RA Agent on his own initiative because he is unsure afterwards, e.g. because he has “tricked” the RA App. Or you as the Master RA Agent see names in your users’ data in the Admin Portal that cannot be correct, e.g. “Dtt” instead of “Ott”, or “Alexan” instead of “Alexandra”. In such cases, the identification must be repeated and you should remind the RA agent of his duties, possibly even trigger a training again.

Unfortunately, there is no reliable method to detect faulty registrations, except for the concrete check of user entries based on the ID documents presented during identification. However, we at Swisscom or our auditors only carry out such checks on a random basis.

We have a few colleagues and also partners in Germany who carry out identifications with the RA App. Of course, it would be easier to use the video identification procedure, SRS Bank, SRS eID or SRS Selfie Ident to register persons in the EU area for QES. Unfortunately, these identifications are not permitted for QES in Switzerland, where it is mandatory to register using the RA app.

You can find more information on SRS Direct

Try the following:

• Restart your mobile phone: as we all know, a reboot is always good for you!
• For Mobile users: Test your Mobile ID at mobileid.ch/login.

In the following situations, you need to be identified again:
You have:

• A new mobile number
• A new SIM card
• A new mobile phone
• Switched to eSIM
• Activated your Mobile ID (SIM) or Mobile ID App without using the recovery code.
• Changed your authentication method, e.g. from Mobile ID SIM to Mobile ID App or vice versa; from password SMS code procedure to Mobile ID and vice versa.
• changed your secure password when using the password/SMS code procedure
• Transferred your mobile phone contract, e.g. also changed provider
• Got a new passport or ID card because the old document had expired.

Please check here if you are correctly registered: https://check-signing.trustservices.swisscom.com/

You must have a successful result on this page to be able to login, otherwise you need to get identified again.

After re-identification, you must also be reassigned the Master RA Agent role, as there is a new user entry.

For users in Switzerland, the Mobile ID SIM method has priority over the Mobile ID app. We recommend that you choose one Mobile ID method and deactivate the other. You can deactivate the respective Mobile ID method in the Mobile ID Dashboard: www.mobileid.ch/login

You will not receive any notification in the Admin Portal. Users get a notification by SMS 3 months and again 1 month before the expiry of their ID card or passport. And as a Master RA Agent, you are also a user.

Option 1: You have not answered all knowledge questions, therefore the e-learning is not yet completed. Please answer all knowledge questions so that you reach the green cup. Afterwards you will receive another SMS with the link to the duties of RA agents. Only after you have accepted these duties, you can log in to the RA App.

Option 2: You have

• changed or reset your password for the password/SMS code procedure
• activated the MobileID (SIM or App) after you identified yourself
• Re-activated MobileID or changed the Mobile PIN without using the Mobile ID Recovery Code.
• Received a new SIM card, eSIM, mobile phone number or mobile phone, changed your provider

For any of these events, Swisscom can no longer guarantee that the same person is in possession of the phone number that was validated during the identification by the RA agent. For security reasons, you will need to re-identify yourself and ask your Master RA Agent to reassign the RA Agent role to you.

Please note: the RA Agent role must first be deleted and then completely reassigned in the admin portal.

A prospective RA agent has 15 days to complete the RA agent basic e-learning. If the RA Agent misses this deadline for completing the basic e-learning, the role assignment is deleted from the system and the Master RA Agent must reassign the RA Agent role.

Standard RA agents have no insight into the users they identify.

It also works without. For users and RA agents who do not want to or cannot use the Mobile ID, we offer the password – SMS code method as an authentication method. You set up this procedure after identification when accepting the terms of use for the signing service.

If a security incident occurs, Swisscom analyses what exactly happened. Then Swisscom performs an assessment of the impact as well as the risk for their services and any persons affected. After this assessment, measures are derived to remedy the security incident and avoid similar incidents. The affected customers are notified and sensitised when certain measures are implemented and appy to them.

Example:

A customer has appointed persons from outside the organisation as RA agents in his RA agency. Swisscom has become aware of this and has opened a security incident, as this is not permitted due to compliance requirements. Swisscom’s assessment and evaluation showed that this was a security incident (minor incident) for the service. Swisscom then raised awareness of this issue with the customer and asked them to remove the RA agent role from all non-organisation personnel. In addition, Swisscom has sharpened the topic in the training documents.

Once RA agents are “deposited” in the agency, the name of the RA agency can no longer be adjusted. If the company name is changed, we have to create a new RA agency and the network of RA agents has to be rebuilt.

This depends on which terms of use a person has accepted after registration. In principle, we recommend that customers accept both terms of use of the signing service for the legal areas of Switzerland (in accordance with the ZertES Federal Act) and the EU/EEA (in accordance with the eIDAS Regulation) so that they keep all their options open.

And then it depends on which signature application of our partners the person wants to use for their electronic signature

We recommend that you first apply the handwritten signature, then scan the document (as a PDF) and finally apply the electronic signature.

However, it should be clarified beforehand whether this is also accepted by the legal services of the parties involved. It is important to keep both versions (the one with the handwritten signature and the electronic version) afterwards.

“Advanced” and “Qualified” are expressions from the signature laws and designate the “quality” or evidential value of electronic signatures and digital certificates.

Qualified electronic signatures are the highest quality and are equivalent to handwritten signatures according to the law. For the identification for this level as well as for the creation of electronic signatures and the underlying digital certificates, there are strict rules, detailed instructions for the design of the signature and high requirements, which Swisscom fulfils. We are also certified in this regard.

Advanced electronic signatures are not of such high quality and are also not regulated by law. They are only permitted as evidence in court, it must then be verified during court proceedings, for example, and the court must assess the effect of the signature after a precise analysis. However, there are ETSI (European Standards Institute) regulations that support advanced signatures in various qualities (LCP, NCP, NCP+) even for this level. Swisscom fulfils the highest standard “NCP+” and is therefore also audited. Swisscom is also listed with this with a green tick in the Adobe Trust List. Such an audit can then help as important evidence in an assessment of evidence.

This means that with the qualified signature you are always on the safe side. It therefore depends on the specific case and the associated risk whether one foregoes a QES. In the past, too, contracts were concluded on a handshake (possibly with witnesses) or simply with an exchange of e-mails, where one was sure that these contracts would hardly be dealt with in court. Similarly, an assessment for or against a QES must be carried out here.