Tech

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.

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”