# Glossary

DISCLAIMER: All descriptions are definitions written by iSHARE, unless specified otherwise. DGA definitions are sourced from [Regulation (EU) 2022/868, Article 2](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com) and DSSC from official [website](https://dssc.eu/space/bv15e/777333342/Alphabetical+List+of+All+Defined+Terms+in+Blueprint+v1.5).

* [ABAC](#glossary-abacabac)
* [Accountability](#glossary-accountabilityaccountability)
* [Adherence](#glossary-adherence-ishare-adherence-ishare)
* [Adhering Party (role)](#adhering-party)
* [API](#glossary-apiapi)
* [Attestation](#glossary-authenticationauthentication)
* [Authentication](#glossary-authenticationauthentication)
* [Authenticity](#glossary-authenticityauthenticity)
* [Authorisation](#glossary-authorisationauthorization)
* [Authorisation Registry (role)](#glossary-authorisationregistry-role-authorizationregistry-role)
* [Caching](#glossary-cachingcaching)
* [Certificate authority](#glossary-certificateauthoritycertificateauthority)
* [Certification](#glossary-certification-ishare-certification-ishare)
* [Certified Party (role)](#glossary-confidentialityconfidentiality)
* [Change Advisory Board](#glossary-confidentialityconfidentiality-2)
* [Claim](#glossary-confidentialityconfidentiality-1)
* [Confidentiality](#glossary-confidentialityconfidentiality)
* [Conformance Test Tool (CTT)](#conformance-test-tool-ctt)
* [Connector](#connector-dssc)
* [Council of Participants](#glossary-credentialscredentials)
* [Credentials](#glossary-credentialscredentials)
* [CRUD](#glossary-crudcrud)
* [Data](#data) [or Data Set](#glossary-dataclassificationdataclassification)
* [Data Altruism](#data-altruism)
* [Data classification](#glossary-dataclassificationdataclassification)
* [Data exchange](#glossary-dataexchangedataexchange)
* [Data Governance Act](#data-governance-act)
* [Data Holder](#data-holder)
* [Data Intermediation Service](#data-intermediation-service)
* [Data Space](#glossary-dataspacedataspace)
* [Data Space Governance Body(role)](#glossary-satellite-role-satellite-role)
* [Data User](#data-user)
* [Delegation](#glossary-delegationdelegation)
* [eIDAS](#glossary-eidaseidas)
* [eIDAS 2](#glossary-encryptionencryption)
* [Encryption](#glossary-encryptionencryption)
* [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role)
* [European Digital Identification (EUDI) Wallet](#european-digital-identification-eudi-wallet)
* [Evidence](#evidence-dssc)
* [iSHARE-ID](#glossary-ishare-id)
* [Holder](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)
* [HTTP(S)](#glossary-http-s-http-s)
* [Human Service Consumer (role)](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)
* [Identification](#glossary-identificationidentification)
* [Identity Broker (role)](#glossary-identitybroker-role-identitybroker-role)
* [Identity Provider (role)](#glossary-identityprovider-role-identityprovider-role)
* [Integrity](#glossary-integrityintegrity)
* [iSHARE Network](#glossary-isharenetworkisharenetwork)
* [Issuer](#glossary-jsonjson)
* [JSON](#glossary-jsonjson)
* [JWT](#glossary-jwtjwt)
* [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa)
* [Machine Service Consumer (role)](#glossary-machineserviceconsumer-role-machineserviceconsumer-role)
* [Non-repudiation](#glossary-non-repudiationnon-repudiation)
* [OAuth](#glossary-oauthoauth)
* [OIN](#glossary-oinoin)
* [OpenID Connect](#glossary-openidconnectopenidconnect)
* [Participant](#participant)
* [Participant Registry (role)](#participant-registry-role)
* [Party ID](#glossary-pdppdp)
* [PDP](#glossary-pdppdp)
* [PEP](#glossary-peppep)
* [PIP](#glossary-pippip)
* [PKI](#glossary-pkipki-publickeyinfrastructure)
* [PKI Root](#glossary-pkirootpkiroot)
* [RBAC](#glossary-rbacrbac)
* [Responsibility](#glossary-responsibilityresponsibility)
* [REST](#glossary-restrest-ful)
* [Scheme](#glossary-schemescheme)
* [Scheme Owner (role)](#glossary-schemeowner-role-schemeowner-role)
* [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role)
* [Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role)
* [Service provision](#glossary-serviceprovisionserviceprovision)
* [Signing](#glossary-signingsigning)
* [Status Code](#glossary-statuscodestatuscode-responsecode)
* [Subject](#glossary-tlstls)
* [TLS](#glossary-tlstls)
* [Token](#glossary-tokentoken)
* [Trust Anchor](#trust-anchor-dssc)
* [Trust Framework](#trust-framework)
* [Verifiable Credentials](#verifiable-credentials)
* [Verifier](#verifier-dssc)
* [Zero trust](#zero-trust)

***

### ABAC <a href="#glossary-abacabac" id="glossary-abacabac"></a>

ABAC (Attribute-Based Access Control) is assigning authorisations based on attributes (contextual pieces of information that are relevant to an access decision, such as device type, [RBAC](#glossary-rbacrbac) role, time, location, or [CRUD](#glossary-crudcrud) level). The attributes can be associated with all entities that are involved with certain actions, such as the subject, the object, the action itself and the context (e.g. time, location). The attributes are compared with policies to decide which actions are allowed in which context, granting access based on the policy outcomes.

***

### Accountability <a href="#glossary-accountabilityaccountability" id="glossary-accountabilityaccountability"></a>

There is a clear distinction between accountability and [Responsibility](#glossary-responsibilityresponsibility).

**Accountability** can be described as being liable or answerable for the completion of a certain task. Someone or something who is accountable oversees and manages the stakeholder(s) who are responsible for performing the work effort. In order to be effective, accountability should lie with a sole entity or role.

Responsibility may be delegated, but accountability cannot.

***

### Adherence <a href="#glossary-adherence-ishare-adherence-ishare" id="glossary-adherence-ishare-adherence-ishare"></a>

An **iSHARE Adhering Party** adheres to the [iSHARE terms of use](https://gitlab.com/ishare-foundation/cab/ishare-trust-framework/-/blob/main/.gitbook/assets/2774106116.pdf). An iSHARE Adhering Party MUST sign an Accession Agreement with the [Scheme Owner (role)](#glossary-schemeowner-role-schemeowner-role).

***

### Adhering Party

A legal entity, acting as an Entitled Party, a Service Consumer or a Service Provider as defined in the iSHARE Framework, who concluded an Accession Agreement with the Participant Registry or the Scheme Owner. To find more information about it follow the link: [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles).

***

### API <a href="#glossary-apiapi" id="glossary-apiapi"></a>

An API (Application Programming Interface) is a technical interface, consisting of a set of protocols and data structuring standards ('API specifications'), which enables computer systems to communicate directly with each other. Data or services can be directly requested from a server by adhering to the protocols. APIs are used to hide the full complexity of software and make it easy for third parties to use parts of software or data services. APIs are mainly meant for developers to make the creation of new applications that depend on other applications easier.

***

### Attestation <a href="#glossary-authenticationauthentication" id="glossary-authenticationauthentication"></a>

According to [ISO/IEC 17000](https://www.snv.ch/files/content/Dokumente/News%20und%20Newslettertexte/ISO_IEC%2017000_Conformity%20assessment_Vocabulary%20and%20general%20principles.pdf), an attestation is an issue of a statement, based on a decision, that the fulfilment of specified requirements has been demonstrated.

In the iSHARE context, an attestation is a digital statement about a specific claim, that enables digital verification during role-based authorisation, compliance monitoring, and automated onboarding within the Participant Registry.

***

### Authentication <a href="#glossary-authenticationauthentication" id="glossary-authenticationauthentication"></a>

**Authentication** is the process of determining or validating whether someone or something is, in fact, who or what it is claiming to be. There are several means of authenticating the identity of an entity, which can be used alone or in combination:

* Something the entity knows – examples include a password, PIN, passphrase, or answer to a secret question;
* Something the entity possesses – examples include electronic keycard, smartcard, token, and smartphone;
* Something the entity is (biometrics) – examples include recognition by fingerprint, retina, iris, and face;
* Something the entity does (behavioural dynamics) – examples include recognition by voice pattern, swipe characteristics, handwriting characteristics, and typing rhythm;
* Something about the context of the entity – examples include IP address, device type, geolocation, and time of day.

***

### Authenticity <a href="#glossary-authenticityauthenticity" id="glossary-authenticityauthenticity"></a>

In the context of information security, **authenticity** refers to the truthfulness of information and whether this has been sent or created by an authentic sender.

Authenticity can be achieved by digitally [signing](#glossary-signingsigning) a message with the private key of the sender. The recipient can verify the digital signature with the matching public key. Certificates containing public and private keys are issued by a [Certificate Authority.](#glossary-certificateauthoritycertificateauthority)

***

### Authorisation <a href="#glossary-authorisationauthorization" id="glossary-authorisationauthorization"></a>

**Authorisation** is the process of giving someone or something permission to do something, for example, to access services, data or other functionalities. Authorisation is enabled by [Authentication](#glossary-authenticationauthentication). Policies and attributes determine what types of activities are permitted by an entity.

***

### Authorisation Registry (role) <a href="#glossary-authorisationregistry-role-authorizationregistry-role" id="glossary-authorisationregistry-role-authorizationregistry-role"></a>

The **Authorisation Registry**:

* Manages records of [Delegation](#glossary-delegationdelegation) and Authorisation[ ](#glossary-authorisationauthorization)of [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role) and/or [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role);
* Checks based on the registered permission(s) whether a [Machine Service Consumer (role) ](#glossary-machineserviceconsumer-role-machineserviceconsumer-role)Service Consumer is authorised to take delivery of the requested service, and;
* Confirms the established powers towards the [Service Provider (role).](#glossary-serviceprovisionserviceprovision)

Within the Trust Framework, the term Authorisation[ Registry ](#glossary-authorisationregistry-role-authorizationregistry-role)always refers to an external Authorisation Registry (not part of the[ Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role) or [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role)).

The Authorisation Registry is a role for which iSHARE [Certification ](#glossary-certification-ishare-certification-ishare)is REQUIRED.

Authorisation Registry is part of the data intermediation service in the [Data Governance Act](#data-governance-act-dga) and can be seen as a Participant Agent Services in DSSC Blueprint. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Caching <a href="#glossary-cachingcaching" id="glossary-cachingcaching"></a>

Web servers can temporarily store data in order to enable faster access to this data at a later moment; this is called 'caching'.

***

### Certificate Authority <a href="#glossary-certificateauthoritycertificateauthority" id="glossary-certificateauthoritycertificateauthority"></a>

A **Certificate Authority (CA)** is:

* An entity that issues digital certificates.
* A trusted party, and;
* Responsible for the binding of the certificate (registration & issuance).

A digital certificate certifies the ownership of a public key by the named subject of the certificate, so other parties can rely upon signatures or assertions made with the private key that corresponds to the certified public key.

A **Registration Authority** verifies the identity of entities requesting digital certificates to be issued by the CA and validates the correctness of the registration.

A **Validation Authority** verifies the validity of digital certificates on behalf of the CA.

***

### Certification <a href="#glossary-certification-ishare-certification-ishare" id="glossary-certification-ishare-certification-ishare"></a>

Certification is a process where prospective participants, willing to play one of the certified roles as defined in [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles), go through in order to be granted certified status. Certification requires participants go through an assessment framework, in addition to the process every other (adhering) role goes through, to evaluate their organisation's level of assurance. The level of assurance determined helps other participants to expect the level of internal quality processes the certified party follows that helps in trust decision making.

***

### Certified Party <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

A legal entity, acting as a Participant Registry, an Authorisation Registry, an Identity Broker or an Identity Provider that has been certified by the Scheme Owner or by other Certifying Bodies, who concluded an Accession Agreement with the Participant Registry or the Scheme Owner. To find more information about it follow the link: [iSHARE roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles).

***

### Certification body(/ies) <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

A Certification Body is an entity that independently checks whether an organisation meets the certification requirements for a specific role in the data ecosystem. If those requirements are met, the organisation can be recognised as certified within the ecosystem.\
\
In the iSHARE Trust Framework, certification is used for roles that other participants must be able to rely on, such as roles that support Identification, Authentication, Authorisation, or Participant Registries.

{% hint style="info" %}
The Scheme Owner currently certifies the roles of Identity Provider, Identity Broker, Authorisation Registry and Participant Registry. A Participant Registry can certify participants on behalf of the Scheme Owner.
{% endhint %}

***

### Change Advisory Board <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

The Change Advisory Board (CAB) is a governance body within the iSHARE Trust Framework consisting of subject matter experts delegated by participants and data spaces. The CAB advises the Scheme Owner (iSHARE Foundation) on proposed changes to the iSHARE Trust Framework specifications, through Requests for Change (RFCs). ￼ ￼

The CAB operates as a collaborative expert group that reviews, discusses, and provides recommendations on proposed changes. It plays a key role in ensuring that updates to the framework are well-informed, balanced across legal, operational, functional, and technical perspectives, and aligned with the needs of the ecosystem. CAB meetings and co-creation sessions support open participation and community-driven evolution of the framework.

***

### Claim <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

DSSC defines claim as an assertion made about a [subject](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims).

***

### Conformance Test Tool (CTT)

The iSHARE Conformance Test Tool (CTT) Enables Participants to validate that their systems and components comply with the technical specifications defined in iSHARE Trust Framework. It ensures interoperability between Parties in various roles within and across dataspaces. For full guidance, visit [CTT](https://trustbok.ishare.eu/apply-ishare/conformance-test-tool-ctt).

***

### Connector

DSSC defines connector as a technical component that is run by (or on behalf of) a participant and that provides participant agent services, with similar components run by (or on behalf of) other participants.

Explanatory Text: A connector can provide more functionality than is strictly related to connectivity. The connector can offer technical modules that implement data interoperability functions, authentication interfacing with trust frameworks and authorisation, data product self-description, contract negotiation, etc. We use “participant agent services” as the broader term to define these services.

{% hint style="info" %}
**Note**

This term was automatically generated as a synonym for: data-space-connector.
{% endhint %}

***

### Confidentiality <a href="#glossary-confidentialityconfidentiality" id="glossary-confidentialityconfidentiality"></a>

In the context of information security, **confidentiality** refers to the protection of information from disclosure to unauthorised parties.

Confidentiality can be achieved by the use of cryptography, as well as access control; the message the recipient gets can be proven not to have been read by anyone else but the legitimate sender and recipient.

***

### Council of Participants <a href="#glossary-credentialscredentials" id="glossary-credentialscredentials"></a>

The Council of Participants is a governance body within the iSHARE Trust Framework composed of all parties (or their representatives) that have a contractual relationship with the Scheme Owner and choose to participate. The Council advises the iSHARE Foundation and appoints members of the Supervisory Board, and is responsible for handling escalations regarding the governance of the foundation ￼.

It ensures that participants have influence over governance, oversight, and strategic direction. In practice, it acts as a higher-level decision and escalation body, safeguarding fairness and alignment with participant interests when disputes or unresolved issues arise.

***

### Credentials <a href="#glossary-credentialscredentials" id="glossary-credentialscredentials"></a>

In the context of information security, **credentials** are used to control access of someone or something to something, for example, to services, data or other functionalities. The right credentials validate (i.e. [Authentication](#glossary-authenticationauthentication)) the identity claimed during [Identification](#glossary-identificationidentification).

The best-known example of credentials is a password, but other forms include electronic keycards, biometrics and, for machines, public key certificates.

***

### CRUD <a href="#glossary-crudcrud" id="glossary-crudcrud"></a>

CRUD (acronym for Create, Read, Update, Delete) are considered to be a basic function regarding stored data. In computer programming, possible actions are often mapped to these standard CRUD functions in order to clarify the actions. For example, standard [HTTP(S) ](#glossary-http-s-http-s)actions GET and POST refer to the Read and Create functions regarding stored data.

***

### Data or Data Set <a href="#glossary-dataclassificationdataclassification" id="glossary-dataclassificationdataclassification"></a>

Data or data set in context of iSHARE framework refers to data in its broadest sense. Examples include, but is not limited to, transactional data, data sets, big data, service data, metadata, etc.

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)defines data as any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of a sound, visual or audiovisual recording.

***

### Data Altruism

According to [DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)data altruism arises when individuals and companies give their consent or permission to make data that they generate available for use in the public interest, voluntarily and without reward. Such data have enormous potential to advance research and to develop better products and services, including in the fields of health, climate action and mobility. Member States may develop national policies to encourage data altruism and an entity engaged in data altruism can apply to be registered as a ‘data altruism organisation recognised in the Union’. The Commission will maintain an EU-level register of these organisations.

***

### Data classification

The classification of data in categories is an important prerequisite for proper Authorisation. Data can be classified by defining their type, location, sensitivity and protection level.

Clustering data in categories not only simplifies the authorisation process (i.e. giving someone or something permission to data), but it also provides a clear overview and lowers the risk of exchanging sensitive data with unauthorised entities. A risk analysis is part of the data classification process.

***

### Data exchange <a href="#glossary-dataexchangedataexchange" id="glossary-dataexchangedataexchange"></a>

Data exchange is the process of supplying data and receiving another (set of) data in return.

***

### Data Governance Act (DGA)

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)is a cross-sectoral instrument that aims to regulate the reuse of publicly/held, protected data, by boosting data sharing through the regulation of novel data intermediaries and by encouraging the sharing of data for altruistic purposes. Both personal and non-personal data are in scope of the DGA, and wherever personal data is concerned, the General Data Protection Regulation (GDPR) applies. In addition to the GDPR, inbuilt safeguards will increase trust in data sharing and reuse, a prerequisite to making more data available on the market.

***

### Data Holder

According to [DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)definition, a data holder is a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, who, in accordance with applicable EU or national law, has the right to grant access to or share certain personal or non-personal data.

Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**NOTE:**

Within the iSHARE Framework, a Service Provider may qualify as a Data Holder.
{% endhint %}

***

### Data Intermediary

According to [DGA](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com) definition, a Data Intermediary is an entity that supports data sharing between parties, such as data holders, data subjects, and data users, through technical, legal, or organisational means. It is expected to act as a neutral party in that exchange.

{% hint style="info" %}
**NOTE**

Within the iSHARE Framework, a Data Intermediary is an organisation that helps other parties share data, but it does not own, change, or use the data itself. It helps make the exchange possible in a secure and trusted way. Service Providers and Certified parties usually qualify as data intermediaries.s
{% endhint %}

***

### Data Intermediation Service

[DGA ](https://eur-lex.europa.eu/EN/legal-content/summary/european-data-governance.html?utm_source=chatgpt.com)defines data intermediary services as a service that aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other, through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data.

***

### Data Space <a href="#glossary-dataspacedataspace" id="glossary-dataspacedataspace"></a>

According to [DSSC](https://dssc.eu/space/bv15e/766061351/Introduction+-+Key+Concepts+of+Data+Spaces#What-about-a-Definition?) and [CEN](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2024/cwa18125_2024.pdf), a Data Space is an interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.

In the context of the iSHARE Trust Framework, a data space can have a single or multiple Participant Registries that operate and work together.

***

### Data Space Governance Body (role) <a href="#glossary-satellite-role-satellite-role" id="glossary-satellite-role-satellite-role"></a>

The Data Space Governance Body is an entity that is the main representative of a data space and is responsible for the [data space](#glossary-dataspacedataspace), including the defining, evolving & maintaining and governing of participant lifecycle processes.

In other dataspace initiatives, this role is also known as Data Space Governance Authority. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**Note**

This role used to be referred as iSHARE Satellite in older versions of iSHARE Specifications
{% endhint %}

***

### Data User <a href="#glossary-delegationdelegation" id="glossary-delegationdelegation"></a>

A natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) [2016/679](http://data.europa.eu/eli/reg/2016/679/oj/eng) (see [summary](https://eur-lex.europa.eu/EN/legal-content/summary/general-data-protection-regulation-gdpr.html)) in the case of personal data, to use that data for commercial or non-commercial purposes.

In other dataspace initiatives, this role is also known as Data Consumer, Service Consumer In Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

{% hint style="info" %}
**Note**

Within the iSHARE Framework, a **Service Consumer**, as well as an **Entitled Party** may qualify as a **Data User**.
{% endhint %}

***

### Delegation

**Delegation** is the act of empowering someone or something to act for another or to represent other(s).

In the iSHARE ecosystem, a delegated [Service Consumer (role) ](#glossary-serviceconsumer-role-serviceconsumer-role)acts on behalf of an [Entitled Party (role)](#glossary-entitledparty-role-entitledparty-role). It can mean to represent authorisation, consent, delegation, mandate, etc. In VCs, it is also called DataRights Credential.

***

### Delegation paths

Delegation paths describe the sequence of delegations through which rights or permissions are passed from one party to another. In the iSHARE context, they make transparent on whose behalf a Service Consumer is authorised to act.

***

### eIDAS <a href="#glossary-eidaseidas" id="glossary-eidaseidas"></a>

[**eIDAS** ](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng)is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. The regulation provides important aspects related to electronic transactions, such as qualified electronic certificates.

***

### eIDAS 2 <a href="#glossary-encryptionencryption" id="glossary-encryptionencryption"></a>

[eIDAS 2](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng) is an updated version of the original eIDAS regulation, which aims to further enhance trust and security in cross-border digital transactions with the EU.

***

### Encryption <a href="#glossary-encryptionencryption" id="glossary-encryptionencryption"></a>

**Encryption** is the process of converting data from plaintext to ciphertext. Plaintext (also called cleartext) represents data in its original (readable) format, whereas ciphertext (also called cryptogram) represents data in an encrypted (unreadable) format.

Decryption is the process of converting data from ciphertext to plaintext.

The algorithm represents the mathematical or non-mathematical function used in the encryption and decryption process.

A cryptographic key represents the input that controls the operation of the cryptographic algorithm. With symmetric encryption, the same key is used for encryption and decryption, whereas with asymmetric encryption, two different, but mathematically related keys are used for either encryption or decryption, a so-called public key and a private key.

A crypto system represents the entire cryptographic environment, including hardware, software, keys, algorithms and procedures.

***

### Entitled Party (role) <a href="#glossary-entitledparty-role-entitledparty-role" id="glossary-entitledparty-role-entitledparty-role"></a>

The **Entitled Party** is the legal person that holds one or more legitimate rights regarding access to, use of, or control over data and/or data services provided by a [Service Provider (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceprovider-role-serviceprovider-role) with which it has a legal agreement.

This may include:

* The right to access or consume a data service (e.g. retrieve or send data)
* The right to exercise legal or contractual control over the data itself (e.g. data ownership, stewardship, or regulatory responsibility)

In cases where the Entitled Party holds primary legal [Responsibility ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-responsibilityresponsibility)for the data, they are also [accountable ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-accountabilityaccountability)for ensuring the [Confidentiality](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-confidentialityconfidentiality), [Integrity](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-integrityintegrity), [Availability](https://framework.ishare.eu/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties), and accurate reporting of that data.

The term Entitled Party may also be referred to in some contexts as Data Owner or Data Rights Holder.

The Entitled Party, [Service Consumer](#glossary-serviceconsumer-role-serviceconsumer-role) and [Service Provider](#glossary-serviceprovider-role-serviceprovider-role) roles can be fulfilled by the same entity, i.e. a legal entity that consumes a service based on its own entitlements to this service (for example, a trucking company's entitlement to request Estimated Time of Arrival and optimal route information), but this is not necessary.

The Entitled Party can also delegate its rights to another Service Consumer. In the latter case, this other Service Consumer (or its machines and humans) may consume services on the Entitled Party’s behalf, but it is not necessary.

[iSHARE Adherence](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-adherence-ishare-adherence-ishare) is REQUIRED for the Entitled Party role.

In other dataspace initiatives, this role is also referred as Data Owner, Data Holder, Data Rights Holder. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Evidence

According to DSSC evidence can be included by an [issuer](https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers) to provide the [verifier](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier) with additional supporting information in a [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#evidence) )

***

### European Digital Identification (EUDI) Wallet

[The European Digital Identity Regulation](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) introduces the concepts of EU Digital Identity Wallets. They are personal digital wallets that allow citizens to digitally identify themselves, store and manage identity data and official documents in electronic format. These documents may include a driving licence, medical prescriptions or education qualifications.

### HTTP(S) <a href="#glossary-http-s-http-s" id="glossary-http-s-http-s"></a>

HTTP stands for 'Hypertext Transfer Protocol', and when secured via [TLS](#glossary-tlstls) or SSL, it is referred to as HTTPS (HTTP Secure). It is a protocol for (secure) communication over a computer network and is widely used on the Internet.

***

### Holder <a href="#glossary-humanserviceconsumer-role-humanserviceconsumer-role" id="glossary-humanserviceconsumer-role-humanserviceconsumer-role"></a>

DSSC defines holder as a role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) might perform by possessing one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) and generating [verifiable presentations](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-presentation) from them. A holder is often, but not always, a [subject](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects) of the [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) they are holding. Holders store their [credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-credential) in [credential repositories](https://www.w3.org/TR/vc-data-model-2.0/#dfn-credential-repositories). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders) )

***

### Human Service Consumer (role) <a href="#glossary-humanserviceconsumer-role-humanserviceconsumer-role" id="glossary-humanserviceconsumer-role-humanserviceconsumer-role"></a>

The **Human Service Consumer** is a role that represents a human (person) who requests, receives, and uses certain services, such as data, from a [Service Provider (role)](#glossary-serviceprovider-role-serviceprovider-role) on behalf of and authorised by the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role).

The Human Service Consumer is not a separate role, but belongs to the Adhering Party Service Consumer.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet) User (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Identification <a href="#glossary-identificationidentification" id="glossary-identificationidentification"></a>

**Identification** is the process of someone or something claiming an identity by presenting characteristics called identity attributes. Such attributes include a name, user name, e-mail address, etc. The claimed identity can be validated (i.e. [Authentication](#glossary-authenticationauthentication)) with the right [credentials](#glossary-credentialscredentials).

***

### Identity Broker (role) <a href="#glossary-identitybroker-role-identitybroker-role" id="glossary-identitybroker-role-identitybroker-role"></a>

If multiple distinct [Service Providers (role)](#glossary-serviceprovider-role-serviceprovider-role) exist where each data set is protected under a distinct trust domain, multiple [Identity Providers (role)](#glossary-identityprovider-role-identityprovider-role) may be needed. Moreover, the iSHARE Scheme may require different [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa) for specific data and may wish to designate specific Identity Providers for specific services.

In order to support multiple Identity Providers (with possible multiple rules) and Service Providers, an **Identity Broker** is required. An Identity Broker allows [Human Service Consumer (role) ](#glossary-humanserviceconsumer-role-humanserviceconsumer-role)to select the Identity Provider they prefer to [Authenticate](#glossary-authenticationauthentication) themselves at. It prevents the need for a direct relationship between all Service Providers and all Identity Providers.

The Identity Broker is a role for which iSHARE [Certification (iSHARE)](#glossary-certification-ishare-certification-ishare) is REQUIRED.

***

### Identity Provider (role) <a href="#glossary-identityprovider-role-identityprovider-role" id="glossary-identityprovider-role-identityprovider-role"></a>

The **Identity Provider**:

* Provides identifiers for [Human Service Consumer](#glossary-humanserviceconsumer-role-humanserviceconsumer-role);
* Issues credentials to Human Service Consumers;
* Manages records of [Authorisation](#glossary-authorisationauthorization) of the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role);
* Identifies and authenticates [Human Service Consumers](#glossary-humanserviceconsumer-role-humanserviceconsumer-role) based on provided credentials
* Checks based on the provided credentials and the registered permission(s), whether a Human Service Consumer (role) Service Consumer is authorised to take delivery of the requested service, and;
* Confirms the established powers towards the [Service Provider (role).](#glossary-serviceprovider-role-serviceprovider-role)
* Possibly provides other information (which are frequently referred to as attributes) about the user that is known to the Identity Provider.

In the iSHARE ecosystem, an Identity Provider could support various methods of [Authentication](#glossary-authenticationauthentication), such as:

* Password authentication;
* Hardware-based authentication (e.g. smartcard, token);
* Biometric authentication;
* Attribute-based authentication.

Depending on parameters such as the quality of the registration process, quality of credentials, use of biometrics or multiple authentication factors and information security, an Identity Provider can provide a client with a high or low confidence in the claimed identity of the user, which is known to the Identity Provider. This is also known as the [Levels of assurance](#glossary-levelsofassurancelevelsofassurance-loa).

The Identity Provider is a role for which iSHARE [Certification (iSHARE)](#glossary-certification-ishare-certification-ishare) is REQUIRED.

In the EUDI Wallet ARF context (v2.7.3), comparable actor terms are PID Provider and/or Attestation Provider (depending on credential type) (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Integrity <a href="#glossary-integrityintegrity" id="glossary-integrityintegrity"></a>

In the context of information security, **integrity** refers to the protection of information from being modified by unauthorised parties.

In the iSHARE context, integrity is primarily ensured through the signing of the data, for example, the client assertion is signed by the sender so that receiver can be confident it has not been modified.

***

### iSHARE-ID <a href="#glossary-ishare-id" id="glossary-ishare-id"></a>

An iSHARE ID is a Decentralised Identifier (DID) derived based on the existing and pre-validated (by a Trust Service Provider) identifier of a party. All participant registries must derive and register an iSHARE ID for each participant they onboard. iSHARE ID is typically derived from a PKI certificate or a signed token from a certified identity provider. Please refer to [https://did.iSHARE.eu](https://did.ishare.eu) for `ishare` DID method specifications.

iSHARE ID enables identity interoperability and discoverability of participants across multiple data ecosystems, which can be verified.

{% hint style="info" %}
**Note**

iSHARE ID is not meant to replace other identifiers or serve as the only identifier, but it allows parties to be registered with multiple types of identifiers.
{% endhint %}

***

### iSHARE Ecosystem (or Network) <a href="#glossary-isharenetworkisharenetwork" id="glossary-isharenetworkisharenetwork"></a>

The iSHARE Ecosystem (or network) is the collection of ecosystems, participants and data spaces that are established, maintained, and governed accordingly to the iSHARE Trust Framework. The complete decentralised trust ecosystem that is established using the iSHARE Trust Standard for data sharing.

***

### Issuer <a href="#glossary-jsonjson" id="glossary-jsonjson"></a>

A role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) can perform by asserting [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims) about one or more [subjects](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects), creating a [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) from these [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims), and transmitting the [verifiable credential](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential) to a [holder](https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders). (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-issuers) )

***

### JSON <a href="#glossary-jsonjson" id="glossary-jsonjson"></a>

JSON is short for 'JavaScript Object Notation' and is an open standard data format that does not depend on a specific programming language. This compact data format makes use of human-readable (easy-to-read) text to exchange data objects (structured data) between applications and for data storage.

JSON is most commonly used for asynchronous communication between browsers and servers.

***

### JWT <a href="#glossary-jwtjwt" id="glossary-jwtjwt"></a>

A JSON Web Token (JWT) is used when [non-repudiation](#glossary-non-repudiationnon-repudiation) between parties is required. A statement, of which the data is encoded in [JSON](#glossary-jsonjson), is digitally signed to protect the [Authenticity](#glossary-authenticityauthenticity) and [Integrity](#glossary-integrityintegrity) of the statement.

***

### Levels of Assurance (LoA) <a href="#glossary-levelsofassurancelevelsofassurance-loa" id="glossary-levelsofassurancelevelsofassurance-loa"></a>

Within online [Authentication](#glossary-authenticationauthentication), depending on the authentication protocol used, the server is to some extent assured of the client's identity. Depending on parameters such as the quality of the registration process, quality of credentials, use of biometrics or multiple authentication factors and information security, an authentication protocol can provide a server with a high or low confidence in the claimed identity of the client. For low-interest products, a low certainty might be sufficient, while for sensitive data, it is essential that a server is confident that the client's claimed identity is valid.

***

### Machine Service Consumer (role) <a href="#glossary-machineserviceconsumer-role-machineserviceconsumer-role" id="glossary-machineserviceconsumer-role-machineserviceconsumer-role"></a>

The **Machine** **Service Consumer** is a role that represents a machine that requests, receives, and uses certain services, such as data, from a Service Provider (role) on behalf of and authorised by the [Service Consumer (role)](#glossary-serviceconsumer-role-serviceconsumer-role).

The Machine Service Consumer is not a separate role, but it belongs to the Adhering Party Service Consumer (role).

***

### Non-repudiation <a href="#glossary-non-repudiationnon-repudiation" id="glossary-non-repudiationnon-repudiation"></a>

In the context of information security, **non-repudiation** refers to the fact that the sending (or broadcast) and receipt of the message cannot be denied by either of the involved parties (sender and recipient).

Non-repudiation is closely related to [Authenticity](#glossary-authenticityauthenticity) and can be achieved by digital [Signing](#glossary-signingsigning) in combination with message tracking.

***

### OAuth <a href="#glossary-oauthoauth" id="glossary-oauthoauth"></a>

OAuth is an open standard for [Authorisation](#glossary-authorisationauthorization), which is used by, i.e. Google, Facebook, Microsoft, Twitter, etc., to let their users exchange information about their accounts with other applications or websites. OAuth is designed to work with [HTTP(S)](#glossary-http-s-http-s). Within iSHARE, a modified version of OAuth 2.0 is used.

Through OAuth, users can authorise third-party applications or websites to access their account information on other 'master' systems without the need to exchange their [Credentials](#glossary-credentialscredentials) with them to log in to the platform. OAuth provides a 'secure delegated access' to resources (email accounts, picture accounts, etc.) on behalf of the resource owner.

It specifies a method for resource owners to authorise third parties' access to their resources without exchanging their credentials (username, password). Authorisation servers (of the platform) issue access tokens to third-party clients (applications or websites) with the approval of the resource owner (= end user). The third-party client needs the access token to get access to the resources that are stored on the resource server (of the master system).

***

### OIN <a href="#glossary-oinoin" id="glossary-oinoin"></a>

The OIN format is used to uniquely identify organisations. OIN stands for Organisation Identifying Number. An OIN consists of the following concatenated elements:

* An 8-digit prefix that tells the register where the number is defined (e.g. Chamber of Commerce, RSIN, etc.)
* A number whose value depends on the register

***

### OpenID Connect <a href="#glossary-openidconnectopenidconnect" id="glossary-openidconnectopenidconnect"></a>

OpenID Connect (OIDC) is the authentication layer that is built on top of the [OAuth](#glossary-oauthoauth) 2.0 protocol, which is an authorisation framework. The OIDC authentication layer allows clients to verify the ID and obtain basic profile information of their end-users

The authentication is performed by the authorisation server (managing the access rights and conditions) in an interoperable and [REST](#glossary-restrest-ful)-like manner. Within iSHARE, OpenID Connect 1.0 is used.

***

### Participant <a href="#glossary-participant" id="glossary-participant"></a>

An organisation or legal entity formally admitted to the iSHARE Ecosystem that assumes one or more defined roles and adheres to the iSHARE Trust Framework’s legal, technical, and governance requirements.

***

### Participant Registry (role)

The Participant Registry ensures smooth onboarding and membership management in a data space. All participants within the Data Space/iSHARE network will be explicitly linked to the Participant Registry responsible for their admission. The Participant Registry is a certified party and can also be the [Data Space Governance Body](#glossary-satellite-role-satellite-role) for the data space.\
\
The Participant Registry plays a fundamental role in any iSHARE use case. As part of the [secondary use cases](/detailed-descriptions/functional/secondary-use-cases.md), parties will need to register themselves as [certified or a](/main-aspects-of-the-ishare-trust-framework/framework-and-roles.md)dhere to a Participant Registry. They will also need to consult the Participant Registry to check whether their counterparty is adherent or certified.

In other dataspace initiatives, this role is also referred as Dataspace Registry. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor terms are Registrar (of wallet-relying parties) and related trusted-list concepts (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Party ID <a href="#glossary-pdppdp" id="glossary-pdppdp"></a>

A *Party ID* is typically a unique identifier issued to a natural person or legal person. A data space may require one or more such identifiers during the onboarding of a participant. A data space may even define its own identifier. The Party ID facilitates the accurate identification and authentication of the relevant entity.

The [iSHARE ID](#glossary-ishare-id) serves as a specific type of Party ID, enabling interoperability of identity across various data ecosystems in a verifiable and trusted manner.

***

### PDP <a href="#glossary-pdppdp" id="glossary-pdppdp"></a>

Policy Decision Point. An entity that evaluates access requests that are received from the policy enforcement point ([PEP](#glossary-peppep)). Subsequently, an answer is sent back to the PEP.

***

### PEP <a href="#glossary-peppep" id="glossary-peppep"></a>

Policy Enforcement Point. An entity that determines whether an action is permitted or not. It takes any access requests and forwards them to the policy decision point ([PDP](#glossary-pdppdp)).

***

### PIP <a href="#glossary-pippip" id="glossary-pippip"></a>

Policy Information Point. An entity that holds policy information and is contacted as a source of information regarding [Delegation](#glossary-delegationdelegation)/[Authorisation](#glossary-authorisationauthorization) information.

***

### PKI (Public Key Infrastructure) <a href="#glossary-pkipki-publickeyinfrastructure" id="glossary-pkipki-publickeyinfrastructure"></a>

A PKI is a system for the distribution and management of digital keys and certificates, which enables secure authentication of parties interacting with each other.

Generally, three different methods exist for creating trust within PKIs. These are through 'Certificate Authorities', 'Web of Trust' and 'Simple PKI'. Within iSHARE, the 'Certificate Authority' approach is used, and as such, the other methods will not be discussed.

A PKI can be considered a chain of certificates. At the beginning of the chain is the root '[Certificate Authority'](#glossary-certificateauthoritycertificateauthority) (CA), a public trusted party which is allowed to digitally sign its own certificates (SSC, self-signed certificate). This '[PKI Root](#glossary-pkirootpkiroot) CA' distributes certificates and encryption keys to organisations. The certificate is signed by the 'root CA' as proof that the owner of the certificate is trusted. These organisations can start distributing certificates as well, if allowed by their root. They become CAs, and as such, sign the certificates that they distribute. Repeating these steps, a chain of certificates is created, with each certificate signed by the CA that distributed the certificate.

Parties need to trust a certificate for [Authentication](#glossary-authenticationauthentication) purposes. Instead of trusting individual certificates of organisations, root certificates can be trusted. By trusting a root, all certificates that have the root within their PKI chains are automatically trusted. Most large root CAs are automatically trusted within web browsers, enabling computers to safely interact with most web servers.

***

### PKI Root <a href="#glossary-pkirootpkiroot" id="glossary-pkirootpkiroot"></a>

A PKI root is another term for a root certificate, and stands for a self-signed public key certificate that identifies the [Certificate Authority](#glossary-certificateauthoritycertificateauthority), the party that is trusted by all members in the trust framework. The most common type of PKI certificates is based on the [X.509](/detailed-descriptions/technical/technical-standards.md) standard and normally includes the digital signature of the Certificate Authority. The certificate authority issues digital certificates to all members in the trust framework.

***

### RBAC <a href="#glossary-rbacrbac" id="glossary-rbacrbac"></a>

Role-Based Access Control. Assigning authorisations through business roles. An RBAC role represents a set of tasks or activities translated into authorisations, reflecting one or more of the following:

* Organisational structure
* Business processes
* Policies (rules)

RBAC authorisations can either give access to the front door of the information system or can be translated to access rights within the information system (often through application roles or groups).

***

### Responsibility <a href="#glossary-responsibilityresponsibility" id="glossary-responsibilityresponsibility"></a>

There is a clear distinction between responsibility and [Accountability](#glossary-accountabilityaccountability).

**Responsibility** can be described as being tasked with getting the job done. Someone or something who is responsible performs the actual work effort to meet a stated objective.

Responsibility may be delegated, but accountability cannot.

***

### REST(ful) <a href="#glossary-restrest-ful" id="glossary-restrest-ful"></a>

REST stands for 'Representational State Transfer' and is an architectural style for building systems and services. Systems adhering to this architectural style are commonly referred to as 'RESTful systems'. REST itself is not a formal standard, but it is an architecture that applies various common technical standards such as [HTTP(S)](#glossary-http-s-http-s), [JSON](#glossary-jsonjson) and URI.

A RESTful [API](#glossary-apiapi) indicates that the API architecture follows REST 'constraints'. Constraints restrict the way that servers respond and process client requests, to preserve the design goals which are intended by applying REST. The goals of REST are, among others, performance and scalability. Both are of utmost importance in iSHARE.

***

### Scheme <a href="#glossary-schemescheme" id="glossary-schemescheme"></a>

A **scheme** can be defined as a collaborative effort to establish and maintain a set of agreements to achieve a common goal. The iSHARE Scheme is also known as the iSHARE Trust Framework.

iSHARE is a scheme with [common goals](/introduction/goals-and-scope-of-the-ishare-trust-framework.md). Other schemes include credit card schemes such as MasterCard and Visa, payment scheme iDEAL and identity scheme eHerkenning.

***

### Scheme Owner (role) <a href="#glossary-schemeowner-role-schemeowner-role" id="glossary-schemeowner-role-schemeowner-role"></a>

The **Scheme Owner** represents the body that governs the iSHARE Trust Framework and its participants.

Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

***

### Service Consumer (role) <a href="#glossary-serviceconsumer-role-serviceconsumer-role" id="glossary-serviceconsumer-role-serviceconsumer-role"></a>

The **Service Consumer** is the legal entity that consumes the [Service Provider's (role)](#glossary-serviceprovider-role-serviceprovider-role) service based on the [Entitled Party's (role)](#glossary-entitledparty-role-entitledparty-role) rights to that service. It can do so because the Service Consumer is either the same legal entity as the Entitled Party (i.e. it already has these rights) or because the Entitled Party has delegated rights to the [Service Consumer](#glossary-serviceconsumer-role-serviceconsumer-role).

The Service Consumer interacts with the Service Provider in the form of a [Machine Service Consumer (role)](#glossary-machineserviceconsumer-role-machineserviceconsumer-role) or [Human Service Consumer (role)](#glossary-humanserviceconsumer-role-humanserviceconsumer-role).

The Service Consumer is a role for which iSHARE [Adherence (iSHARE)](#glossary-adherence-ishare-adherence-ishare) is REQUIRED.

In other dataspace initiatives, this role is also referred as Data Space Support Organisation. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet) User (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Service Provider (role) <a href="#glossary-serviceprovider-role-serviceprovider-role" id="glossary-serviceprovider-role-serviceprovider-role"></a>

The Service Provider is a role that provides certain services, such as data, to a[ Service Consumer (role)](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-serviceconsumer-role-serviceconsumer-role). In the case of data provisioning, the Service Provider is either the Data Owner or, has the case the service pertains to data provisioning, the Service Provider is either the [Entitled Party](#glossary-entitledparty-role-entitledparty-role) or has explicit consent of the[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-dataownerdataowner)[Entitled Party](#glossary-entitledparty-role-entitledparty-role) to provide the services.

The Service Provider is[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-responsibilityresponsibility)responsible for the availability of services, and[ ](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-accountabilityaccountability)accountable for these services if it also has the role of the Entitled Party.

[iSHARE Adherence](broken://spaces/zdKjSSaFEukZOShyTzC9) is REQUIRED for the Service Provider role.

In other dataspace initiatives, this role is also referred as Data Provider, Data Node. Refer to our [Roles Nomenclature](https://trustbok.ishare.eu/apply-ishare/quick-walkthroughs/role-nomenclature) page to understand how this role is called in different data ecosystems.

In the EUDI Wallet ARF context (v2.7.3), comparable actor term is (Wallet-) Relying Party (See [EUDI Wallet ARF actor mapping](https://trustbok.ishare.eu/understand-ishare/role-nomenclature/eudi-wallet-arf-actor-mapping)).

***

### Service provision <a href="#glossary-serviceprovisionserviceprovision" id="glossary-serviceprovisionserviceprovision"></a>

**Service provision** is the act of providing or supplying something for consumption or use. One of the most common forms of service provision is the [Data exchange](#glossary-dataexchangedataexchange).

***

### Signing <a href="#glossary-signingsigning" id="glossary-signingsigning"></a>

**Signing** is the process of [Encryption](#glossary-encryptionencryption) data (message, document, transaction) with the private key of the sender. It enables a receiver to confirm the [Authenticity](#glossary-authenticityauthenticity) of the data. Signing also provides for [Non-repudiation](#glossary-non-repudiationnon-repudiation), so that it is ensured that a sender cannot deny having sent a message.

In most cases, a hash of the data is encrypted. Thus, both the [Integrity](#glossary-integrityintegrity) and the [Authenticity](#glossary-authenticityauthenticity) of the data can be verified. Confirmation takes place by the receiver uses the public key of the sender. The public key is contained in the digital certificate that is sent by the sender along with the signed data. The association of the key pair with the sender MUST be assured by a [Certificate Authority](#glossary-certificateauthoritycertificateauthority).

***

### Status Code / Response Code <a href="#glossary-statuscodestatuscode-responsecode" id="glossary-statuscodestatuscode-responsecode"></a>

After sending an [HTTP(S)](#glossary-http-s-http-s) request to a server, the server responds with (among others) a Status Code, which indicates the outcome of the request made to the server. A well-known response is 404 Not found, indicating that the requested location or resource is not (yet) found.

***

### System Services

In the context of the iSHARE Trust Framework, System Services are catered by the use of systems like APIs, portals or IoT devices. The service levels for Availability and Performance mainly apply to system service providers, irrespective of their role. Thus, organisations providing only business services are exempt from these service level requirements (like [Entitled Party](#glossary-entitledparty-role-entitledparty-role) and [Service Consumers](#glossary-serviceconsumer-role-serviceconsumer-role)).

***

### Subject <a href="#glossary-tlstls" id="glossary-tlstls"></a>

Thing about which [claims](https://www.w3.org/TR/vc-data-model-2.0/#dfn-claims) are made (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects) )

***

### TLS <a href="#glossary-tlstls" id="glossary-tlstls"></a>

TLS (Transport Layer Security) is a set of protocols that provides for secure communication in computer networks. TLS makes use of cryptography and is widely used by a variety of applications such as web browsing, email and voice-over-IP. Securing [HTTP(S)](#glossary-http-s-http-s) communication via (among others) TLS results in the HTTP(S) protocol. Securing communication with TLS v1.2 is mandatory for all iSHARE communication.

***

### Token <a href="#glossary-tokentoken" id="glossary-tokentoken"></a>

Something that serves as a verifiable representation of some fact, e.g. an identity or entitlement. Within iSHARE, Tokens are issued after completing [API](#glossary-apiapi) requests, which are then used to process the next request. For example, to access a certain service, first, an access token is required. Upon receiving this access token, it can be used to request the service itself.

***

### Trust Anchor

According to [DSSC](https://dssc.eu/space/BVE2/1071255941/Trust+Framework#3.2.1-Trust-Anchors) , Trust Anchors are authoritative entities for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific [scope of attestation](https://www.iso.org/obp/ui/#iso:std:iso-iec:17000:ed-2:v2:en:term:7.4).\
Examples include governmental bodies. Their fundamental role is to ensure the authenticity, integrity, security, and reliability of identities, data services and transactions within the data space.

***

### Trust Framework

According to [DSSC](https://dssc.eu/space/BVE2/1071255941/Trust+Framework#3.2.1-Trust-Framework), a trust framework provides the methodology and technical specifications for collecting, organizing, and verifying information to support trust decisions - that is, decisions about whether an entity, piece of information, or transaction can be trusted.

The iSHARE Trust Framework is a collaborative initiative aimed at improving the exchange of data between organizations. It focuses on identification, authentication, and authorization to ensure secure and trusted data sharing. The framework provides a set of agreements and standards that facilitate seamless business data sharing, addressing legal, functional, operational, and technical dimensions to enhance governance and interoperability among participants.

***

### Verifier

DSSC defines verifier as a role an [entity](https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities) performs by receiving one or more [verifiable credentials](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential), optionally inside a [verifiable presentation](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-presentation) for processing. Other specifications might refer to this concept as a relying party. (ref. [Verifiable Credentials Data Model v2.0 (w3.org)](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifier) )

***

### Verifiable Credentials

[According to the W3C Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential), a verifiable credential is a tamper-evident credential whose authorship can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verifiable.

***

### Zero trust

Zero Trust is a principle by which trust is not automatically assumed based on a participant’s presence within a network but is verified just in time(of use). Trust can be evaluated using credentials or dynamically verified trust criteria, ensuring each interaction is authenticated based on current, context-sensitive information. Zero trust principles are rooted in the iSHARE Trust Framework and its components, like the Participant Registry.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://framework.ishare.eu/glossary-and-legal-notices/glossary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
