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 ¶
|None||Updating 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 ¶
|#1||Fixing typo in document ("i.e." should be "e.g.").|
Version 1.0.0, 2017-06-23 ¶
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:
- Catalogue – Sent by Economic Operator (Role: REQUEST)
- Catalogue Response – Sent by Contracting Authority (Role: RESPONSE)
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.
(from BCL response)
(from BCL response)
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.
Clients is expected to handle HTTP codes per the list below.
|Not in use|
|No content found for the lookup|
|Error 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 ¶
This request is performed for a given PPID, and may be used when performing discovery.
<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> </Participant>
Lookup: Specific profile identifiers and usage scopes ¶
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"> MIICuDCCAaCgAwIBAgIEWUuM3TANBgkqhkiG9w0BAQsFADAeMRwwGgYDVQQ DDBNFeGFtcGxlIGNlcnRpZmljYXRlMB4XDTE3MDYyMjA5MjUxOFoXDTE3MD YyMzA5MjUxOFowHjEcMBoGA1UEAwwTRXhhbXBsZSBjZXJ0aWZpY2F0ZTCCA SIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALboRbrjJIs5aRWTCd23 /EO42sn3hbV4/zR56yUuOeCHBKmB8PTnQnNNNi4j7qVMdIrs/eBZU+eVkHG s+beeBh7B9Sm2AQHYqv5FOPEOJs+YBxLu9pGcSDvZwdh0h32K3DHuEWXEuN SQmhJ1+xfLWy+mmR711SNByls0pE+9PL/qlkmQLJxaTkhCvOjDqv/Xj6Fel iKmGiHGBAv4o8hn0VEl9yKQoxCjTPfhFintfpb13pKftKDZvSr04uZERIfc mg/IWbNzFBRffy/xkZWWs1FJ9nqaWKMeqiKK+pvJGjquVDsKKGvOBPPCP3s /PNdqpn9R114rd4MKEQVqX1rlgFkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQ EAVb11xVQ6iosAxICR49JE+41Uz/Cz4htunKZ8DsTxxfxwJtjPn5fknLNyS 6/lCnihrmgqE9VG5ENnNqpTq1ASJnVe+42O+yjvJoPv97YxoOo8Ki0Dhh1g P5dmbYXfXX+RegPpnWPxO/IEYSA/5Nw8S3VFxO4e6IHyXVgC9QN30t7aIxy n2vGPzZzyQdg+EZp0SADCMc4UBCa8XmgNpzCfgKA56VemI/iP3IDxZ4J0rE jhCxoo5ItXJiOFQpCyA9vKqtlbEQ+8ZjzreP5+rDk9XskS/Mih/1rgG/unS h2Tbl0q0L6ucBj0dDNFJDQb4z3cwVo8qNPkom3itKPurTlT1Q== </Certificate> </Process>
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:
- Use of caching limits must be agreed upon within the domain.
5xxis returned by BCP may cached certificates be used per limits.
404or no valid certificates are received must cache purge cached certificate.
XSD files (normative) ¶
The following XSD files are part of this spesification: