NemID (DK)

​NemID gives you a solution that customers are conversant with and accustomed to. The majority of the Danish population aged 15 or older use NemID for online banking and on public and private websites. ​

​Enable NemID in you​r 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: ​https://www.medarbejdersignatur.dk/produkter/nemid_medarbejdersignatur/log_paa_nemid_selvbetjening/log_paa_med_noeglefil/index.html  
    • ​​​​​Add support.esecurity@nets.eu as the technical contact person
  • ​​​​​​​When the production-VOCES is issued, an installation code will be shown. Send this code to support.esecurity@nets.eu.
  • ​​Fe​tch the UID by going to the “Administrér virksomhedssignatur” in the "Meny" at NemID Self Service.
    • ​​​​If ​needed, search for the VOCES you have ordered and note the UID:​​

PID/RID agreem​​ent

NemID offers a PID/RID cpr-service that can match a user’s PID/RID 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/RID can be found here: http://www.nets.eu/dk-da/Produkter/Sikkerhed/NemID-tjenesteudbyder/supplerende-produkter/PID-RID-cpr-tjenester/Pages/default.aspx#tab1​


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.

  • S​upport 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 req​​uest 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​​. ​

​Handling of SSN

​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.
  • T​his 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 Javascrip​​t cli​ent​

​Step 1:​

NemID JS - step 1.png

​Step 2:

NemID JS - step 2.png

 

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: 

NemID CF - step 1.png

Step 2:

NemID CF - step 2.PNG

Step 3:

NemID CF - step 3.png


NemID youth certifica​tes

 

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: 

  1. ​Check the CPR number if you have access to that prior to initiating a signing order to E-Signing.
  2. Check the certificate used to sign a document prior to accepting the signature. This can be done by following these steps:
    1. ​After a document has been signed, the signed document can be fetched from the E-Signing service using the GetSDO XML message
    2. 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.​

​Document types and sizes​

​​The following document formats are supported using NemID:

  • PDF
  • Text

The size limi​t of a document is set to 3MB base64 encoded document or approximately 2,2 MB non-encoded.​​

PDF valid​​ation

 

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 OpenSi​gn/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:

M​etadata in the S​DO​

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:

​Metadata name​Description​Constraints
​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
​appversion​The version of the NemID component in E-Signing.​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/​

Pre​​​​​requisites

To use this functionality in E-Signing, you must:

  • ​know the signer's CPR (national identity number)
  • ​know the organisation the signer will sign on behalf of
  • ​be an ID-Rights customer as well as E-Signing (no integration to ID-Rights necessary)
  • update to the latest TrustSignMessage scheme​. 

 

​Defining the sign order

To use this fu​nctionality, 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, the IDType set to SSN and the IDValue to the person’s CPR number. 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:

Private NemID - english med.png

Retriev​​e information ​from SDO and PAdES

​How to find infor​mation 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-Ri​​ghts 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 doc​​ument

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. 


 

​​