Authentication is the process of proving that the user (human or IT process) with a digital identity who is requesting access is the rightful owner of that identity (definition from IDpro). In the context of the BDI, the user is a representative of a legal entity (organization).
Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases.
In this page we will focus on M2M use cases where data is requested by a Data Consumer (e.g. another organization) via an API.
Ensure that BDI users (M2M) are recognized and identified to prevent misuse of services and data. The automatic authentication of a BDI user in a federated perimeter-less architecture (see DNS-based Discovery as option) relies on a (delegated) Trust Anchor for Identity.
The Data Service Provider is responsible for authenticating the user; this is prerequisite for authorization, which will determine if the user can access the requested data.
Incorrect authentication could result in data breaches and / or the unavailability to data for legitimate data consumers.
The BDI uses the OAuth2 protocol. OAuth2 supports two types of client credentials for authentication:
Shared secrets
Private keys (certificates).
The use of private keys is preferred within the BDI.
A BDI association could decide to issue certificates itself as an association, or as a group of associations. The consequence is that the Association is its own Trust Anchor, making federation with other Associations harder or less trustworthy.
The European eIDAS regulation is a trust framework which (also) governs the issuance of certificates within Europe. Certificates can be used for:
Mutual TLS - Qualified Web Application Certificate (QWAC)
Digital Sealing of the message - Qualified Seal (QSEAL)
QWAC and QSEAL are different types of eIDAS certificates.The sealing provides the legal binding of the exchanged data.
The use of eIDAS digital certificates as private keys is recommended. The recommendation is to use eIDAS QWACs as well.
The eIDAS regulation and infrastructure is EU-specific. Outside of Europe other trust anchors could be used (to be investigated).
Certificates are quite expensive
Certificates need frequently to be rotated
The procurement, setup, testing and acceptance of certificates is not trivial.
Guidance on (to be done):
Mapping certificates to identifiers (within the association)
Mapping to a well known identifier within the Data Service Provider
Note on Mutual Authentication; also relevant for the Data Consumer
Non-EU trust anchors (outside of eIDAS).
The use of association issued certificates instead of eIDAS certificates
Alignment with DSSC. The DSSC Blueprint v1.0 is referring to “Identity and Attestation Management” which is based of verifiable credentials, DID’s and OpenID for verifiable credentials. These has been defined out of scope for the current release of DIL / BDI.
In the BDI network, a within a BDI Association is integral for assessing the trustworthiness of visitors or outsiders: members of another BDI Association. While the BDI facilitates digital communication among a network of BDI Associations, establishing trust within a BDI Association through mutual agreements is relatively straightforward. However, evaluating the trustworthiness of participants in other BDI Associations can pose a challenge.
A federation trust is designed to enable efficient and secure online transactions between business partners. Trust to engage between parties is most often based on more attestations agreed between parties and/or assocation they are member of. The service provider can then make decisions based on te information on behalf of the data owner.
When a requests from a member of association A is directed to access data of a member of association B the request is redirected to the association's B attestation service to validate the federated trust artifacts available with the requestor association. These attestations help decide the authentication response of the data provider and authorization conditions applied on behalf the data owner. Note: Emphasizing 'helps decide' as the Trust Sovereignty principle is kept by allowing the assessment against the policies of the data owner to determine authorization. The owner might want to provide the data service as requested even if the Identity does not provide all the required attestations or limit the authorization provided by the assessment policies of the presented attestations.
The concept for the is to adopt the framework standards with it's members to achieve a goal (benefits outweigh the costs). Add local specifics, ratify common standards across associations, evolve and so on.
Above options could be combined; e.g. .
OAuth2:
OAuth 2.0 Mutual-TLS:
iSHARE:
The use of (other) PKI schemes.
The use of Decentral Identifiers.
Federated Authentication through OAuth 2.0 Attestation-Based Client Authentication
See Authentication M2M and Authentication H2M
In the context of the BDI, the user is a representative of a legal entity (organization). Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases.
Authentication is the process of proving that the user (human or IT process) with a digital identity is the rightful owner of that identity (definition from IDpro).
Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases. In this page, the focus is on H2M use cases: the human interacts with a machine by means of an IT-process under its direct control (device, IT-process, wallet etc.), or by digital data (e.g. QR code). Authentication precedes verification of Representation and subsequent Authorization.
The complexity of H2M Authentication is increased by privacy regulations: authenticating a human reveals their identity.
The purpose of this building block is the following:
Ensure that BDI users (H2M) are recognized, identified as a person and in a specific role on behalf of a legal entity in order to prevent misuse, fraud, theft of data, services and physical goods.
Enable smooth, efficient and secure Boundary Management.
Ensure that privacy leaks as a result of authentication are limited.
The use cases relate to Boundary Management:
The building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated. This authentication precedes verification of Representation. In the context of the BDI, the human is a representative of a legal entity (organization): the legal entity assumes accountability and liability for the actions of the representative, limited to the mandate of the representative. A human can have multiple roles for multiple legal entities simultaneously.
The Identity Provider chosen by the parties/Association provides the authentication. A local cache of trusted identities may be operated by an Association as a register.
Representation evidence may be stored in a register by an Association, or transmitted between parties in a nested Jason Web Token or a Verifiable Presentation of Credentials.
The BDI uses the OAuth2 protocol and OpenID Connect protocol for H2M interactions. Identities are managed by an Identity Provider (also called an OpenID Provider).
The , in abstract, follows these steps:
End user navigates to a website or web application via a browser.
End user clicks sign-in and types their username and password.
The RP (Client) sends a request to the OpenID Provider (OP).
Organization can use (1) an internal Identity Provider, (2) an exclusive external Identity Provider and (3) a mix of an internal Identity Provider and (federated) external Service Provider (see the Federation Kit).
In the BDI users are typically acting as a representative for a legal entity and not as an individual person. Therefore, the OpenID Connect UserInfo endpoint must contain a organizational identifier of the legal entity.
eIDAS is short for ‘Electronic Identification, Authentication and Trust Services’ and was launched to help remove digital borders between countries in the EEA. eIDAS ensures the security of digital systems and protects people’s privacy. Besides eIDAS, there are also various national eID schemes. For example, in the Netherlands the national eID for persons is called DigiD and the eID for persons representing a legal entity is called eHerkenning.
There are strict regulations on the use of eIDAS. DigiD cannot be used for most private use cases. There are less limitations for eHerkenning. However, a very limited set of European countries have a similar B2B eID scheme.
Once a national electronic identification scheme has been recognized at European level, it can be used in other EEA countries. This is set out in the EU’s eIDAS Regulation.
These can be used for access to a location and/or transferring assets.
eIDAS2 introduces new trust services and EU Digital Identity Wallets (EDIW) for the use by citizens in both public and private domains. eIDAS2 also includes Organizational Digital Identity Wallets (ODIWs) [].
This building block interlinks with:
The OP responds with an Identity Token and usually an Access Token.
The RP can send a request with the Access Token to the User device.
The UserInfo Endpoint returns Claims about the End-User.
A human, acting as representative for a legal entity desiring access to data or an application owned/controlled by another legal entity
For example: login to an application
A human, acting as representative for a legal entity desiring access to a location owned/controlled by another legal entity
For example: entering a protected zone
A human, acting as representative for a legal entity involved in transferring as asset (cargo) and/or liabilities for the asset between the two legal entities
For example: picking up cargo by a transporter
