CertPub Publisher 1.0


This document describes version 1 («v1») of the Business Certificate Publisher (BCP) interface. This document does not describe internal workings of an implementation of BCP. Introduction to BCP

The BCP service provides a standardized lookup interface to retrieve the qualified certificate for use in end to end encryption of business communication (b2b, g2b, b2g and g2g), known in the four-corner model (link) as corner 1 and 4. BCP provides clear separation of concern between the communicating parties and BCP’s function of maintenance, distribution and security clearing of certificates. Each participant is responsible to provide the qualified certificate they preferred used when receiving encrypted messages.


This document describes version 1 of the API for lookup. This API uses “v1” as identifier. This is to allow upgrading to newer API versions when needed.


Version 1.0.2, 2019-09-30

NoneUpdating examples in 5.1, and updating URL path in 5.2 and 5.3 accordingly. Changing from "URL path" to "API path" for clarification.

Version 1.0.1, 2017-10-13

#1Fixing typo in document ("i.e." should be "e.g.").

Version 1.0.0, 2017-06-23

NoneInitial document.


Participant Identifier (PPID)

Participant Identifier in BCP reuses the PEPPOL Participant Identifier (PPID) defined by OpenPEPPOL. PPID is defined as a qualified identifier based upon ISO 6523. PPID expressed in BCP uses double colon (“::”) as separator.

Example of a Norwegian organization:


Process Identifier (PID)

Process Identifier (PID) in BCP reuses the Process Identifier defined by OpenPEPPOL/CEN BII. PID is defined as a qualified identifier. PPID expressed in BCP uses double colon (“::”) as separator.

Example of invoicing process identifier:



Role is introduced in BCP to allow organizations to provide different certificates based upon the role they play in complex processes consisting of responses back to initiator of the process.

BCP is currently limited to processes containing maximum two participants, where processes containing more than two participants should be divided into narrower processes.

Role is applied to a process by defining the direction of the first message (sent by initiator) as a REQUEST message. BCP is modelled on having receivers declare capabilities. For encryption of REQUEST messages is the receiver’s REQUEST certificate used for encryption in the process. When a message is returned as part of the same process is this direction defined as RESPONSE. Further uses of the same direction in the process uses the same role.

Example of Catalogue process:

Supported lookups

BCP is inspired by OASIS BDXR SMP, and support two requests for lookup; list of supported profiles for a given PPID and certificates for a combination of PPID, PID and UC.


Lookups are performed in the context of the BCP service. In the case of BCP not running as root application for the hostname is URL paths defined by BCP to be applied to the BCP context.

Example 1:

API pathapi/v1/[PID]
BCP context
(from BCL response)
Request URIhttp://bcp.example.com/api/v1/[PID]

Example 2:

API pathapi/v1/[PID]
BCP context
(from BCL response)
Request URIhttp://example.com/bcp/api/v1/[PID]

PPID and PID must be URL encoded when replacing value holders in this document. Service implementations are free to support non-encoded values; however, client implementations must implement with encoding of values. Any other parts of the URL are not subject to encoding.

Example 3:


Clients is expected to handle HTTP codes per the list below.

HTTP CodeDescription
200Content available
3xxNot in use
404No content found for the lookup
5xxError in the service, try again later

It is recommended to provide BCP using HTTPS. BCP services may use the included XML Signature (XMLDsig) for integrity in cases where HTTPS is not used or where such use is specified within domain.

Lookup: Supported profile identifiers

API pathapi/v1/[PPID]
Supported methodsGET
Response elementParticipant

This request is performed for a given PPID, and may be used when performing discovery.

Example response:

<Participant xmlns="urn:fdc:difi.no:2017:virksert:v1" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#">
  <ParticipantIdentifier scheme="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii01:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii03:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii04:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii05:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii28:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii30:ver2.0</ProcessReference>
  <ProcessReference scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:biixx:ver2.0</ProcessReference>

Lookup: Specific profile identifiers and usage scopes

API pathapi/v1/[PPID]/[PID] (Returns Role=REQUEST)
Supported methodsGET
Response elementProcess

This request is performed for a combination of PPID, PID and role to fetch encryption certificates.

Example response (self-signed certificate):

<Process xmlns="urn:fdc:difi.no:2017:virksert:v1" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#">
  <ParticipantIdentifier scheme="iso6523-actorid-upis">9908:910076787</ParticipantIdentifier>
  <ProcessIdentifier scheme="busdox-procid-ubl">urn:www.cenbii.eu:profile:bii01:ver2.0</ProcessIdentifier>
  <Certificate serialNumber="1498123485" expire="1498209918000">

BCP services must perform validation of each certificate at some interval (e.g. 48 hours), meaning certificates received upon lookup is not checked on-the-fly by BCP and is subject to validation by clients before use.

All clients fetching certificates must validate certificates received. In a case where multiple certificates are received may any valid certificate be used. Validation of certificates must be per the chain and rules agreed upon within the domain (i.e. Norwegian Business Certificates).

In a situation where all returned certificates fail validation is the lookup application expected to handle this as if the service returned 404 rather than 200.

Caching services may be used per these rules:


XSD files (normative)

The following XSD files are part of this spesification: