Enable NemID in your services
To enable NemID login through E-Signing, we need a VOCES certificate issued to your organisation and some information. The information will be gathered in the dialogue with support.
More information about NemID:
VOCES certificate
All customers must order a new NemID VOCES (“virksomhedscertifikat”) certificate to be used with E-Ident and/or E-Signing in production. In test, your configuration will be set up with a general test VOCES.
Ordering a NemID company certificate (called production-VOCES)
- Order the production-VOCES from the link below. Note: The production-VOCES must be ordered by a company administrator at the NemID Self Service:
- When the production-VOCES is issued, an installation code will be shown. Send this code to agreed contact at support.esecurity@nets.eu.
- If you forgot to retrieve the installation code, return to the "Administrer virksomhetssignatur" menu to retrieve the code again. Please note that this will generate a new code, and invalidate the old code.
PID agreement
NemID offers a PID cpr-service that can match a user’s PID with a CPR number. This will be ordered for you during configuration in E-Ident and/or E-Signing.
- Support will send you the prepared agreement. Please verify the information and let an authorised officer sign it.
- Return the signed agreement to support.esecurity@nets.eu as a scanned PDF.
Info about PID can be found here:
http://www.nets.eu/dk-da/Produkter/Sikkerhed/NemID-tjenesteudbyder/supplerende-produkter/PID-RID-cpr-tjenester/Pages/default.aspx#tab1
Note: RID CPR matching is not supported due to the low number of user's with a CPR connected to their employee certificate.
Production access
NemID production access (only applicable if customer already have a TU-agreement)
If you already have a TU-agreement (“tjenesteudbyder”), a request for production access for your new production-VOCES will be done upon configuration in E-Ident and/or E-Signing.
- Support will request a new Friendly name from you. Note: The Friendly name must be different from any of your other production-VOCES certificates.
NemID production access (if no TU-agreement is in place)
If you do not have a TU-agreement, support will fill out the agreement to be a service provider on behalf of the customer.
- Support will request some information from you and you will receive information about the standard and general terms according to the TU-agreement. You will also receive a form to accept that support makes a TU-agreement on your behalf.
Test users
Information about test users and how to create them can be found
here.
SSN in SDO
The signer’s SSN (CPR) may be added to the SDO to connect a signer’s signature with the signer’s SSN. To add the SSN to the SDO, the following prerequisites exists:
- The SSN (CPR) must be added to the
SignerID element in the InsertOrder message for this particular signer. When the SSN is added to this element, a comparison (match) between the CPR and the unique ID in the signer certificate will be done towards NemID after the signing is completed.
- This function must be activated in your E-Signing configuration at Nets. To activate the function,
contact support.
If all prerequisites are in place, the following elements will be added to the SDO:
<ds:SignatureProperty Target="signature">
<openoces:Name>cpr</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">1234561234</openoces:Value>
</ds:SignatureProperty>
User experience
NemID offers two clients for end users; the Javascript client used with a code card or
code app and the CodeFile client used with a code file. The Javascript client offers the possibility to sign with either personal (POCES) or employee (MOCES) certificates while the CodeFile client is used for signing with employee (MOCES) certificates only.
NemID Javascript client
Step 1:
Step 2:
NemID transaction text in the code app
It is possible to add a transaction text to the NemID code app. This is added by appending the transactiontext parameter to the sign URL. The text is visible in the code app as the "This is the input to the transaction text parameter" text in the screen shot example below.
Read more about sign URL parameters.
NemID CodeFile client
Step 1:
Step 2:
Step 3:
NemID youth certificates
A NemID youth certificate is issued to people in the age between 15-18 years. Users above 18 years with a youth certificate can enforce renewal to a certificate without the youth indication. This is done in the self-service on
https://www.nemid.nu/dk-da/. A youth certificate is valid for 3 years, and since the certificate is not automatically renewed, people up to 21 can have a valid youth certificate.
The E-Signing service allows signing using NemID youth certificates. To avoid unintended usage of documents signed with youth certificates, implement a document and signature acceptance procedure based on one of the following two methods:
- Check the CPR number if you have access to that prior to initiating a signing order to E-Signing.
- Check the certificate used to sign a document prior to accepting the signature. This can be done by following these steps:
- After a document has been signed, the signed document can be fetched from the E-Signing service using the
GetSDO XML message.
- The SDO can be un-packed using the
GetSDODetails XML message. The response will include the certificate used to sign a document. The DN part of the certificate will clearly state that it is signed by a youth, and actions related to this have to be taken by the customer.
NemID error codes
Explanation of NemID error codes may be found in the “NemID Error Codes” document on this page:
NemID pseudonum
A NemID user can select to not include their name in the NemID certificate, which will cause the name to be set to “Pseudonum”. This can be changed through the self-service portal at nemid.nu.
NemID logo
If needed, the NemID logo can be downloaded from
https://www.nemid.nu/dk-da/om-nemid/presse/logo_og_grafik/.
Document types and sizes
The following document formats are supported using NemID:
The size limit of a document is set to 10 MB base64 encoded document. An encoded document adds approximately 30 % extra to a non-encoded document.
PDF validation
NemID has a whitelist of elements that are allowed used in PDF documents. The E-Signing service uses the whitelists to validate PDF documents prior to accepting a sign order. There are currently two validation methods used. The method used depends on which NemID client is configured in your customer configuration, and which AcceptedPKIs that are defined in the sign order.
NemID Javascript
For customers using NemID JS only, the “Sign Text validator tool” is used for validation.
NemID OpenSign/CodeFile
For customers using NemID OpenSign/Codefile only, the “PDF validator” is used.
Note: If the document may be signed using either the NemID Javascript client or the NemID CodeFile client, both validators are used.
Both validation tools can be downloaded here:
You can also read more about the PDF whitelisting in appendix C of this document:
Metadata in the SDO
For NemID signings, there is a possibility to receive extra metadata information about the signer and the sign environment in the SDO. This is a configurable setting in E-Signing for each customer configuration. Please contact support to enable the setting.
The metadata information in the SDO:
| useragent | The signer’s user agent. | For NemID JS: base64 encoded
For NemID CodeFile: Double base64 encoded |
| useripaddress | The signer’s IP address. | For NemID CodeFile: Double base64 encoded |
| apposversion | The E-Signing server OS version. | For NemID CodeFile: Double base64 encoded |
| appjavaversion | The E-Signing server Java version. | For NemID CodeFile: Double base64 encoded |
This is how it may look like when the signer has signed with NemID JS:
<openoces:Name>useragent</openoces:Name>
<openoces:Value Encoding="base64" VisibleToSigner="no">TW96aWxsYS81LjAgRsOkcnRtZWlzdGVy</openoces:Value>
</ds:SignatureProperty>
<ds:SignatureProperty Target="signature">
<openoces:Name>useripaddress</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">172.21.65.2</openoces:Value>
</ds:SignatureProperty>
<ds:SignatureProperty Target="signature">
<openoces:Name>apposversion</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">Linux 2.6.32-431.el6.x86_64</openoces:Value>
</ds:SignatureProperty>
<ds:SignatureProperty Target="signature">
<openoces:Name>appjavaversion</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">1.8.0_45</openoces:Value>
</ds:SignatureProperty>
<ds:SignatureProperty Target="signature">
<openoces:Name>appversion</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">ts_idp_dk_nemid 1.2.12</openoces:Value>
</ds:SignatureProperty>
Private NemID - on behalf of company
A signer may choose to use his or hers private NemID (POCES) when acting on behalf of a company. This is also possible through the E-Signing service.
Read more about the usage of private NemID in a company setting: https://digst.dk/it-loesninger/nemlog-in/om-loesningen/initiativer/
Prerequisites
To use this functionality in E-Signing, you must:
- know the organisation the signer will sign on behalf of
- update to the latest
TrustSignMessage scheme
- optionally, know the signer's CPR (national identity number)
Defining the sign order
To use this functionality, the specified sign process (a sign process is the technical connection with one signer and one document in a sign order to E-Signing) must be updated with a reference to an organization.
<Organizations>
<Organization>
<LocalOrganizationRef>org-ref-1</LocalOrganizationRef>
<OrganizationNumber>999999987</OrganizationNumber>
<AttachBusinessCertificateToSDO>false</AttachBusinessCertificateToSDO>
<Country>DK</Country>
</Organization>
</Organizations>
The sign order must be updated with the
Organization element. There can be one or more
Organization elements in a sign order. The CVR number shall be added to the
OrganizationNumber, the
LocalOrganizationRef should be a unique reference inside the sign order, the
AttachBusinessCertificateToSDO shall be set to false and the
Country shall be used and set to
DK.
<ExecutionDetails>
<OrderDeadline>2018-11-17T17:45:27+00:00</OrderDeadline>
<DisplayProcessInfo>NameStatusTime</DisplayProcessInfo>
<GenerateOneTimeURLs>false</GenerateOneTimeURLs>
<Steps>
<Step>
<StepNumber>1</StepNumber>
<SigningProcess>
<LocalDocumentReference>doc-ref-1</LocalDocumentReference>
<LocalSignerReference>signer-ref-1</LocalSignerReference>
<LocalOrganizationRef>org-ref-1</LocalOrganizationRef>
<TerminateOrderOnSignerRejection>true</TerminateOrderOnSignerRejection>
</SigningProcess>
<SigningProcess>
<LocalDocumentReference>doc-ref-1</LocalDocumentReference>
<LocalSignerReference>signer-ref-2</LocalSignerReference>
<TerminateOrderOnSignerRejection>true</TerminateOrderOnSignerRejection>
</SigningProcess>
</Step>
</Steps>
</ExecutionDetails>
User choice of either private or employee NemID
The
Signer element in the sign order must define the different eIDs that the signer shall be able to choose among. If you would like to give the signer the choice of either signing with private NemID (POCES) or employee NemID (MOCES), you need to define a
NemID and a
NemID-OpenSign element.
The
NemID element should specify one SignerID for private NemID and one for employee NemID.
The private NemID
SignerID must have
CertificatePolicy set to
Personal, and the
IDType must be set to
SSN. The
IDValue may be set to the person’s CPR number. If
IDValue is not set, the end user will be prompted for his/hers CPR number prior to signing.
The employee NemID
SignerID must have a
CertificatePolicy set to
Employee. You can choose to add
RID as
IDType and give the CVR and/or RID number of the signer as value. The certificate used during signing will be verified towards the CVR (and RID if included).
The
NemID-OpenSign element should be defined with
CertificatePolicy set to
Employee. You can also here choose to add
RID as
IDType and give the CVR and/or RID number of the signer as value.
See this example of how the Signer element shall be if you want to give the user the possibility to choose either private or employee NemID.
<Signer>
<EndUserSigner>
<LocalSignerReference>signer-ref-1</LocalSignerReference>
<Name>Signer Name</Name>
<AcceptedPKIs>
<NemID>
<SignerID>
<CertificatePolicy>Personal</CertificatePolicy>
<IDType>SSN</IDType>
<IDValue>1234561234</IDValue>
</SignerID>
<SignerID>
<CertificatePolicy>Employee</CertificatePolicy>
<IDType>RID</IDType>
<IDValue>CVR:987654321</IDValue>
</SignerID>
</NemID>
<NemID-OpenSign>
<CertificatePolicy>Employee</CertificatePolicy>
<SignerID>
<IDType>RID</IDType>
<IDValue>CVR:987654321</IDValue>
</SignerID>
</NemID-OpenSign>
</AcceptedPKIs>
</EndUserSigner>
</Signer>
If the sign order is setup as the above description, the signer will be presented with this choice when signing:
If the
IDValue is not set to the signer's CPR number in the first
SignerID element in the example above, the user will be prompted for his/hers CPR number in a page like this:
Retrieve information from SDO and PAdES
How to find information in the SDO
The CVR number the signer is authorized to represent:
<ds:SignatureProperty Target="signature">
<openoces:Name>AuthorizedToRepresent</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">CVRNUMBER-number</openoces:Value>
</ds:SignatureProperty>
The signer's CPR number:
<ds:SignatureProperty Target="signature">
<openoces:Name>cpr</openoces:Name>
<openoces:Value Encoding="xml" VisibleToSigner="no">1234561234</openoces:Value>
</ds:SignatureProperty>
The
TransactionID from ID-Rights can be found in the
Metadata part of the SDO. This can be used to track the communication towards ERST for audit purposes later:
<Metadata>
<ValuePair>
<Name>IDRightsTransactionID</Name>
<Value><![CDATA[65e7bf72-4abc-4e30-b6e5-3d123c93512f]]></Value>
</ValuePair>
</Metadata>
Get a PAdES document
Use the
GetPAdES message to retrieve the PAdES version of the signed document. The last page will be updated with the AuthorizedToRepresent value -> the CVR number.
Authentication-based signing
The E-Signing service offers the possibility to sign a document based on an authentication. To create a sign order with authentication-based signing, please have a look at the
authentication-based signing page.
The NemID specific values are listed in the table below:
| AuthenticationID | This element can be used to indicate that NemID JavaScript and/or NemID CodeFile client are some of the eID's the signer can sign with. | dk_nemid_js | dk_nemid-opensign |
| SignerID | The SignerID element can specify which user that shall sign the document. The PID value is the personal identifier from a user's NemID certificate. This is also returned as the pid claim from a NemID authentication through E-Ident. The SSN is the signer's national identifier. Note: The SignerID element is not supported when using employee/MOCES certificates for authentication. | IDType: PID | SSN IDValue: See description. Only with dk_nemid_js as AuthenticationID. |
| forcepkivendor | The forcepkivendor parameter can be used to point the user directly to this eID.
Read more about forcepkivendor. | abs:dk_nemid_js | dk_nemid-opensign |
