authn.rite

---
title: Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework

editors:
    - name: "Jesus Ruiz"
      email: "hesusruiz@gmail.com"
      company: "JesusRuiz"
      companyURL: "https://hesusruiz.github.io/"
authors:
    - name: "The DOME project participants"

copyright: >
   Copyright © 2023 the document editors/authors. Text is available under the
   <a rel="license" href="https://creativecommons.org/licenses/by/4.0/legalcode">
   Creative Commons Attribution 4.0 International Public License</a>

latestVersion: "https://alastria.github.io/did-method-elsi/authn.html"
edDraftURI: "https://alastria.github.io/did-method-elsi/authn.html"
github: "https://github.com/alastria/did-method-elsi/blob/main/authn.html"
og_description: >
    Authentication and authorization of entities acting on behalf of legal persons with Verifiable Credentials under eIDAS framework
og_site_name: Authn with Verifiable Credentials
localBiblioFile: "localbiblio.yaml"
---

<section #abstract>

    We describe a mechanism enabling **Decentralised Identity and Access Management in B2B** ecosystems which require a high level of legal certainty, reduced manual processes and reduced dependency in third parties for the operation of the ecosystem. It combines eIDAS X.509 certificates issued by QTSPs with advanced or qualified signatures and seals of Verifiable Credentials. 

    The mechanism enables authentication and access control of **entities acting on behalf of a legal person** with much more descriptive power and flexibility than trying to use just X.509 certificates of representation, and in a more efficient and automated way than using just signed PDFs.

    The mechanism is aligned with the upcoming EDIW (European Digital Identity Wallet) and its supporting eIDAS2 regulation, but it advances the state of the art by focusing entirely on **legal persons** with an implementation that can be used today without the need to wait for future supporting regulation.
    
    The mechanism is **not recommended for natural persons**, even if technically could be adapted. For natural persons we recommend to wait for eIDAS2 and EDIW.
    
    The mechanism leverages Verifiable Credentials and the existing eIDAS framework by:
    
    <ul>
        - making the credential a **machine-readable e-mandate** by embedding authorisation information in the credential using a formal language and binding it to the identities of the issuer and subject.
        - making the credential a **legally binding document** under the [[eIDAS]] framework, by signing the credential with an advanced or qualified seal/signature.
        - making the credential an **authentication mechanism**, by binding the identities of the subject and holder of the credential so it can be used for authentication.
    
    In this way, the credential is a **legally binding machine-readable document where the issuer attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential**.
    
    The subject can then **use the credential to authenticate to a Relying Party** because the identities of holder and subject are bound.

    This mechanism leverages the eIDAS trust framework using advanced or qualified signatures and seals to provide a **high level of legal certainty and enjoying the presumption of non-repudiation in the courts**, something that does not happen when using other types of basic signatures.

<section id="conformance">

<section>Authentication and Authorization with Verifiable Credentials

    <section>Problem Statement 

        Representation powers and mandates are an essential element for businesses establishing relationships with other businesses, governments and customers, because in many cases **natural persons act on behalf of legal persons** and depending on the sensitivity of the involved data/processes the Relying Party may want to enforce a high level of legal compliance and reduce associated legal risks.

        Electronic powers of representation and mandates are an **explicit objective of the European Digital Identity Wallet** (EDIW) and the proposed amendment to eIDAS to support it:

        <blockquote>
            To achieve **simplification and cost reduction benefits to persons and businesses across the Union, including by enabling powers of representation and e-mandates**, Member States should issue EDIWs relying on common standards and technical specifications to ensure seamless interoperability and to adequately increase the IT security, strengthen robustness against cyber-attacks and thus significantly reduce the potential risks of ongoing digitalisation for citizens and businesses.

            <figcaption>—[[[eIDAS2.Regulation]]]

        The traditional way to solve this is by using cumbersome processes associated to onboarding and Know-Your-Customer (KYC) procedures, in many cases manual processes and paper/PDF documents that the Relying Party verifies until it is satisfied with the level of legal risk assumed when allowing a Principal to access some services on behalf of the Participant. Those setup processes are normally cumbersome, slow and people-intensive, creating a lot of friction in the initial stages of using a service, especially when strong identification is required by the nature of the service.

        Standard eIDAS certificates of representation can help (see an example QTSP <a href="https://eadtrust.eu/en/electronic-certificates/legal-entity-representative/">Certificate of Legal Entity Representative</a>), but they tend to be for natural persons with full powers or for very standard use cases.

        For a more granular specification of the powers of a natural person when acting on behalf of a legal person, other solutions have been implemented in different Member States, but typically centralised, non-interoperable among them and limited to the services provided by the Public Administration. In the private sector there is not any standardised solution and basically every company does it their own way.

        **Verifiable Credentials** can become a good instrument to implement a machine-readable and legally-binding e-mandate with much more descriptive power and flexibility than trying to use just certificates of representation, while maintaining the same level of compliance and legal risk than with traditional processes, and this is the reason why it is included in the objectives of the upcoming eIDAS2 regulation.

        However, currently there are important barriers that hinder the adoption of an EU wide solution for cross-border transfer of representation information, being one of the most relevant the **lack of a common semantic framework**. 
        
        Representation is complex, and electronic mandates schemes and policies are basically national and usually do not contemplate the possibility to use those mandates in cross-border scenarios. The problem of mandates when accessing services from a Public Administration is extremely complex, so **we will focus here on the private sector**: when both the Relying Party and the Participant are legal persons from the private sector.

        In order to have a simple, flexible and powerful mechanism using Verifiable Credentials, the main requirements are the following:

        <ul>

            -(REQ-01): **The credential is an e-mandate**, by embedding authorisation information in the credential and binding it to the identities of the issuer and subject. We call such a credential a "Verifiable Authorisation".

                There must be a **controlled vocabulary** that can be used to express in a formal language (e.g. ODRL) the semantics of the powers delegated to a Principal by the Participant.

            -(REQ-02): **The Relying Party does not have to know in advance the Principal** accessing its services on behalf of a Participant.

                However, the Relying Party should have an easy authentication mechanism based on Verifiable Credentials to ensure that the entity accessing the services is the same entity identified in the e-mandate, and so that it has the required powers to access.

                Ideally, to simplify the authentication and authorisation process for the Relying Party, the same credential that is a mandate (we call it a Verifiable Authorisation) can enable authentication (we call it a VerifiableID). Of course, we could use different credentials and even a "traditional" authentication mechanism, but having a single credential that can be used both for authentication and authorisation (using the powers specified in the mandate) is what we describe here.

            -(REQ-03): There may be several Principals accessing the services of a Relying Party on behalf of the same Participant, and each Principal may have different powers that enable them to access different (possibly overlapping) sets of services.

                The Relying Party specifies the powers that need to be validated for each service (the scope the access is requested on and the type of representation that the Service provider allows). Each individual service may require different sets of powers, at the sole discretion of the Relying Partly (of course always in synch with the agreement formalised with the Participant).
                
                The Participant grants the authorisations to the Principals at its own discretion. Only the Principals that have the powers required by an individual service can access that service. The Participant may have more powers than strictly required (for example, full representation of the legal entity).

            -(REQ-04): The Relying Party can **reduce the legal risks and associated costs of litigation** in court by leveraging the **presumption of non-repudiation** associated to the use of an eIDAS advanced/qualified seal/signature for the Verifiable Credential.
            
                Of course, the Relying Party is free to request from Participants other types of signatures, if it is willing to assume the higher level of legal risk. We define here a mechanism which can have the same level as a document with a handwritten signature (when using qualified electronic signatures/seals).

                In this way the credential is a **legally binding machine-readable document where the issuer (Participant) attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential (Principal)**.

            -(REQ-05): The Relying Party can verify that the issuer of the credential corresponds to a **real-world identity which is fully accountable** for the contents of the credential, without needing any additional third-party, trust framework or participant list associated to a given Data Space or Federation.
            
                Using an eIDAS signature/seal for the credential, the current EU legal and trust framework in place since 2016 is enough for the Relying Party to verify that the Participant has issued a legally-binding mandate to the Principal.

        With all these properties, the credential is a **legally binding machine-readable document where the issuer attests that it delegates the set of powers specified in the credential to the user identified as the subject of the credential**. The subject can then **use the credential to authenticate to a Relying Party** because the identities of holder and subject are bound.

        This mechanism leverages the eIDAS trust framework using advanced or qualified signatures and seals to provide a **high level of legal certainty and enjoying the presumption of non-repudiation in the courts**, something that does not happen when using other types of basic signatures.

    <section>Introduction

        In a typical B2B ecosystem, the agreements between a product/service provider and the consumer are formalised among legal persons (also known in this document as 'organisations').

        However, when interacting in the context of execution of the agreement, typically other entities are acting on behalf of the legal persons both for the consumer organisation and for the service provider organisation.

        For example, an employee of the consumer organisation may start on behalf of his employer an interaction with the provider organisation to perform a process needed for the provision of a service. In this case, the provider organisation should authenticate the natural person and apply appropriate access control policies to ensure that the natural person is really entitled by the consumer organisation to perform the intended process.

        In the context of authentication and access management, the legal entity acting as consumer organisation will be named `Participant`. The digital representation of a natural person, acting on behalf of a Participant, is referred to as a `Principal`. However, when the context is clear and we need to refer to eIDAS legal terms, we will use the term `user` (defined in the Glossary) to denote a natural or legal person, or a natural person representing a legal person using a wallet to authenticate.

        The legal entity acting as service provider and performing authentication and access management will be called `Relying Party`.

        The approach is similar to the on-behalf-of actor model described in [[Actor-DataSpaces]] but our focus is on the compliance with the eIDAS legal framework to enable not only Data Spaces but any type of ecosystem to leverage the eIDAS trust framework and achieve a high level of legal certainty with the presumption of non-repudiation in the courts.

        The mechanism described here allows a Relying Party receiving a Verifiable Credential from a principal engaging in an authentication process to perform the following verifications:

        <x-dl>

            <x-dt>Authentication
                <ul>
                    - **Non-tampering**. The Relying Party can verify that the credential was not tampered with since it was generated, thanks to the digital signature of the credential.

                    - **Binding the Principal with the subject inside the credential**. The Relying Party can verify that the principal presenting the credential is the same principal identified as the subject inside the credential by using the cryptographic material inside the credential that was embedded in a secure and private way during the credential issuance process. See section <x-ref "verifiable_id"> for more details.
                    
                        The degree of trust in this verification depends on the degree of trust that the Relying Party puts on the processes that the Participant uses to issue the credentials.

                        However, as described below, the usage of eIDAS signatures to sign the credential makes the Participant legally liable for any problems in the binding of the identities of the holder and subject of the credential. Specifically, compliance to the eIDAS specifications and regulation for electronic seals and signatures provides **presumption of non-repudiation and the burden of disputing it in the courts rests on the Participant, not on the Relying Party**.

                        This is important because it provides the incentives in the proper places: the Participant is incentivised to create the credential in the proper way, and the Relying Party is incentivised to perform its due diligence in verifying the credential. By using the eIDAS signatures, no party has to assume the burden if the technical validity of the signature is disputed in court. Only the contents of the credential can be under discussion. See section <x-ref "signature_benefits"> for more details.

                        In the mechanism described here, the verification is enabled by embedding inside the credential a public key corresponding to a private key that was generated by the principal during the issuance process. See below for the details, including an optional mechanism by embedding an existing eIDAS certificate issued by a QTSP when the principal is a natural person or a legal person (different from the Participant).

                    - **Binding of issuer with a real-world identity**. The Relying Party can verify that the credential was issued by somebody controlling a private key associated to a given real-world identity.

                        The verification is enabled because the Verifiable Credential is sealed with an eIDAS <x-ref "qualified certificate for electronic seal"> issued to the Participant by a <x-ref "qualified trust service provider"> (QTSP) in the [[[EU_Trusted_Lists]]], and the signature of the credential is an advanced or qualified electronic signature using the [[JAdES]] format (JSON Advanced Electronic Signature) as defined in the eIDAS regulation.

                        Of course, we also support electronic signatures with qualified certificates for electronic signatures issued by QTSPs to **natural persons acting as representatives of legal persons**.

                        This verification ensures that an organisation with a real-world legal identity under the eIDAS Trust Framework has signed the credential being presented by a natural person identified as the subject of the credential.

                        This verification **does not say anything about whether the organisation is a participant** in a given Data Space or not. See next point for such verification.

                    - **Verify that the real-world identity is a Participant**. The Relying Party, using the unique identifier in the eIDAS certificate used to sign the credential, can check if the issuer of the credential is a participant in a given ecosystem by looking for that unique identifier in the Trusted Participant List managed by that ecosystem.

                        This unique identifier is the unique `organizationIdentifier` defined in [[[ETSI-LEGALPERSON]]], which is inside the certificates for legal persons and certificates for natural persons acting as representatives of legal persons.

                        Any legal person that can already engage in electronic transactions in the internal market can have an eIDAS certificate including such a unique identifier, which is used in all types of legally-binding signatures like invoices, contracts, etc.

                        We assume here that the onboarding process of each ecosystem does not invent a new "local-only" identifier but uses the one that is already valid for electronic transactions in the internal market. Or at least, that the global eIDAS unique identifier is associated with whatever private identifier is invented by the ecosystem.
                        
                        We assume that the eIDAS unique identifier is used during onboarding to update a given Trusted Participant List with the identity of the new participant. That identity is composed of the unique identifier in the eIDAS framework and any additional attributes that may be relevant for the ecosystem. See below for the structure of the unique eIDAS identifier.

            <x-dt>Access Control
                <ul>
                    - **Binding the Participant to the delegated powers to the Principal**. The Relying Party can verify that the legal person (the Participant) or a representative of the legal person (in eIDAS terms) has delegated a specific set of powers to the subject identified inside the credential (who is the same person holding and presenting the credential, as described above in 'authentication').

                        This is enabled because the credential includes a **set of claims that state in a formal language the delegated powers**, and the credential has been sealed/signed using an eIDAS certificate using the eIDAS advanced/qualified electronic signature format, described in more detail later in this document.

                        Alternatively, the credential can include a pointer to an external document (which could be another credential) describing in detail the delegated powers. In this case, the linking mechanism should provide a tamper-evident mechanism to avoid undetected modifications to the original external document, for example using [[Cryptographic Hyperlinks]].
                        
                        Thanks to the usage of eIDAS signatures, the credential is effectively a legal document with the same legal validity as any other document in any format supported by the eIDAS signature scheme. The Relying Party can verify (and prove in court if needed) with a high level of legal certainty that the legal person issuing the credential (the Participant) has declared that the holder/subject of the credential has the powers stated inside the credential (or linked by the credential).

                        Actually, the entity identified as a subject in the credential, and that is receiving the delegated powers, is not restricted to be a natural person and can be of different types. Anything that can be expressed in paper or PDF format can be also expressed in the Verifiable Credential format. For example, it can be an employee, a customer or a machine or device under the responsibility of the legal person signing the credential.

                    - The Relying Party can use the claims mentioned above, expressed as a formal language (e.g. [[ODRL]]), to perform access control. The specific mechanism is not in the scope of this document.

                        For example, the credential can just specify the role(s) of the entity identified in the credential (e.g. 'finance administrator' for an employee, 'gold customer' for a customer, 'humidity sensor' for a machine) and the Relying Party can evaluate a set of arbitrarily complex policy rules associated to the role(s) for access control.

                        Alternatively, the credential could specify more complex rules which the Relying Party can combine if needed with additional policy rules to make the final decision.

        To achieve all of the above, we define specific types of Verifiable Credentials with a format and a mechanism which specify:
        
        <ol>
            - a way to sign the credentials;
            - a way to bind the identity of the holder of a credential to the identity of the subject inside the credential;
            - and a way to embed authorisation information in the credential describing the powers that the legal entity has delegated to the subject inside the credential.
            
        The mechanisms described here can be used to generate credentials to employees, contractors, customers and even to machines and devices acting on behalf of an organisation. The schema is identical, except the issuance process is probably a little bit different and the roles and duties embedded in the credentials have different legal implications (but always in line with the legal framework, for example with the <a href="https://commission.europa.eu/law/law-topic/consumer-protection-law/consumer-contract-law/consumer-rights-directive_en#:~:text=About%20the%20directive,-The%20Consumer%20Rights&text=It%20aligns%20and%20harmonises%20national,they%20shop%20in%20the%20EU.">Consumer rights directive</a>).

        <section #signature_benefits>Signature of the Verifiable Credentials

            We use a <x-ref "qualified certificate for electronic seal"> provided by an eIDAS <x-ref "qualified trust service provider"> (QTSP) to seal credentials with an <x-ref "advanced electronic seal"> (AdESeal) or <x-ref "qualified electronic seal"> (QESeal) with the JSON Advanced Electronic Signature format ([[JAdES]]).

            We also use a <x-ref "qualified certificate for electronic signature"> issued by a QTSP to authorised representatives of the legal person, to sign credentials with an <x-ref "advanced electronic signature"> (AdES) or with a <x-ref "qualified electronic signature"> (QES) with the JSON Advanced Electronic Signature format (JAdES).

            This mechanism for sealing/signing the Verifiable Credentials has the following properties:

            <x-dl>
            
                <x-dt>Provides high assurance of the identity of the creator of the credential.
                
                    The seals/signatures provide **high assurance of the identity of the creator of the seal**. For example, it will be difficult for a malicious user to get a qualified seal certificate in the name of a company, because the QTSP will be responsible to check that such a seal is issued to the persons representing the company and not to unauthorised persons.

                <x-dt>Enables authorised representatives of the legal person to act on behalf of the legal person.
                
                    The mechanism provides **high legal predictability**, including for the qualified electronic signature the benefits of its **legal equivalence to handwritten signatures**.

                    As stated by the eIDAS Regulation, when a transaction requires a qualified electronic seal from a legal person, a qualified electronic signature from the authorised representative of the legal person should be equally acceptable.

                    It is possible to certify elements that are bound to the signatory such as a title (e.g. Director), a link with its employer, etc. Because the QTSP is trusted for verifying the information it certifies, the Relying Party can get a high level of confidence in such information conveyed with the signature through the signatory's certificate.

                    In this way, the Relying Party receiving Verifiable Credentials can have the same legal certainty than with any other document in other formats (e.g. PDF) signed with AdES or QES signatures or with handwritten signatures (in the case of QES).

                <x-dt>Provides a high level of legal certainty and interoperability.

                    Any basic signature benefits from the non-discrimination rule, which means that a Court in an EU Member State cannot reject it automatically as being invalid simply because they are in electronic form.
                
                    However, their dependability is lower than that of an AdES/AdESeal or QES/QESeal because the signatory may be required to prove the security of the technology being used if the validity of the signature is disputed before a court. This requires significant costs and efforts that could be avoided with relative ease by opting for the more established and standardised advanced and qualified signature solutions. It may also be the case that the relying parties have no applications or tools to validate such signature, when not based on standards; in such a scenario, the signature may be legally valid and technologically robust, but of limited use (see [[ENISA-Qualified Electronic Signatures]] and [[ENISA-Qualified Electronic Seals]]).
                    
                    For these interoperability reasons, QES/QESeal that are based on recognised EU standards are preferable unless the parties operate purely in a local context where the acceptance and usability of the chosen signature solution is sufficiently certain.
                    
                    Beyond the technical interoperability, the eIDAS Regulation also ensures the international recognition of electronic signatures, and not limited to the EU.

        <section>A taxonomy of Verifiable Credentials

            The objectives defined in the introduction can be achieved in different ways. We define here an approach that standardises the detailed mechanisms so it can be adopted easily by anyone who wants to obtain the associated benefits. If the approach is adopted in an ecosystem, it provides a high level of interoperability among the participants in the ecosystem, reducing also the risks associated with mistakes in the implementation.

            To describe precisely the approach, we define a taxonomy of the relevant classes of Verifiable Credentials that we need.

            For the purpose of this discussion we use a diagram derived from the taxonomy <a href="https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Data+Models+and+Schemas">defined in EBSI</a>:

            <x-diagram .plantuml>Classes of credentials
                hide circle
                hide empty members

                class "<b>W3C Verifiable</b>\n<b>Credential</b>" as vc 
                class "<b>Verifiable</b>\n<b>Attestation</b>" as va
                vc <|-- va: extends

                package "Authn & Authz" <<Rectangle>> {
                    class "<b>VerifiableID</b>" as vid #Application {
                        For authentication
                    }
                    class "<b>Verifiable Authorisation</b>" as vau #Application {
                        For authorisation
                    }
                    class "<b>LEARCredential</b>" as lear #PaleGreen {
                        For authentication &
                        authorisation
                    }
                    va <|-- vid
                    va <|-- vau: extends

                    vau <|-- lear: extends
                    vid <|-- lear: extends
                }

                package "Other uses" <<Rectangle>> {
                    va <|-- "Other\nVerifiable Attestations"
                }

                class "<b>Employee</b>\n<b>credential</b>" as employee #Khaki
                class "<b>Customer</b>\n<b>credential</b>" as customer #Khaki
                class "<b>Machine</b>\n<b>credential</b>" as machine #Khaki
                lear <... employee: Instance of
                lear <... customer
                lear <... machine: Instance of

            And this is the chain of trust from the "Authentic sources" to the credential that the employee (for example) holds.


            <x-diagram .plantuml>Chain of trust
                @startuml
                left to right direction

                package "eIDAS Trust Framework" {
                    database "Source of Trust" as st
                    component "Qualified\nTrust Service\nProvider" as qtsp
                    st --> qtsp : Read by\nQTSP

                }

                package "Legal entity" {
                    actor "Representative of\nlegal entity" as lr
                    qtsp --> lr : Issues\ncertificate\nof representation

                    actor "Authorisation\nManager" as autm
                    actor "Employee with\nlimited powers" as emp

                    lr --> autm : Issues\ncredential with\nlimited powers
                    autm --> emp : Issues\ncredential with\nlimited powers\nto access\nspecific services

                }

                @enduml

            The sections below refer to this diagram for each type of credential discussed.



        <section #verifiable_id>Authentication requires a VerifiableID

            Not all types of Verifiable Credentials can be used as a mechanism for online authentication, because the Relying Party (the entity receiving the Verifiable Credential in an authentication process) needs to bind the identity of the user sending the credential to the claims attested about the subject inside the credential.

            For example, in the case of a Diploma as a Verifiable Credential (a Verifiable Diploma), the credential is a Verifiable Attestation which indicates that the subject has certain skills or has achieved certain learning outcomes through formal or non-formal learning context. However, as in the case with normal Diplomas in paper of PDF format, this credential can be presented by anyone that holds the credential. In other words, the credential binds the identity of the subject with the claims inside the credential, but does not bind the identity of the holder of the credential with the identity of the subject of the credential, which requires a special mechanism in the issuance process.

            Most Verifiable Credentials will be issued as Verifiable Attestations, acting as efficient machine-processable and verifiable equivalent to their analog counterparts. Their purpose is to attest some attributes about the subject of the credential and not act as a mechanism for online authentication.

            Instead, **a `VerifiableID` is a special form of a Verifiable Credential that a natural or legal person can use in an electronic identification process as evidence of whom he/she/it is** (comparable with a passport, physical IDcard, driving licence, social security card, member-card…).

            VerifiableIDs can be of different types and be issued by different entities with different levels of assurance (in eIDAS terminology). They are issued with the purpose of serving as authentication mechanisms in online processes. In the near future, VerifiableIDs of the highest level of assurance (LoA High) will be issued to citizens and businesses by their governments under eIDAS2.

            We describe in this document a way to issue VerifiableID credentials and how a Relying Party can perform authentication by accepting that credential.


        <section>Access Control requires a Verifiable Authorisation

            Once the user is authenticated, the system should make a decision to grant or reject an access request to a protected resource from an already authenticated subject, based on what the subject is authorised to access.

            Let's take the example of when a Service Provider signs an agreement with a Service Consumer organisation (a legal person), and the Service Provider wants to allow access to some services to employees of the Consumer organisation under the conditions of the agreement.

            In most cases, granting access is not an all-or-nothing decision. In general, the agreement between the Service Provider and Service Consumer specifies that only a subset of the employees of the Consumer organisation can access the services, and even in that subset not all employees have the same powers when accessing the services. For example, some employees have access to the administration of the service, some can perform some create/update/delete operations in a subset of the services, and some employees can only have read access to a subset of the services.

            To allow for this granularity in an authentication and access control process, in general the entity willing to perform an action on a protected resource has to present (in a Verifiable Presentation) a VerifiableID and possibly one or more additional Verifiable Attestations.

            At least one of the credentials should include claims identifying the employee (or any other subject) and a formal description of the concrete powers that have been delegated by the legal representative of the organisation, enabling the determination by the Service Provider whether the user is entitled to access a service and the operations that the user can perform on that service.

            We define later a standard mechanism and format for a Verifiable Credential that enables this functionality in a simple, secure and with high degree of legal certainty compatible with eIDAS.

            Such a credential is called a Verifiable Authorization, represented in the figure above.

        <section>Combining VerifiableID and Verifiable Authorisation in the LEARCredential

            In many use cases, it is possible to simplify the authentication and access control by combining in a single credential both a VerifiableID (for authentication) and a Verifiable Authorisation (for access control).

            We call the resulting credential a LEARCredential and it is very useful when the holder/subject wants to use a decentralised IAM mechanisms implemented by Relying Parties which are federated in a decentralised way using a common Trust Anchor Framework.

            We repeat here the taxonomy diagram to facilitate the description of the LEARCredential.

            <x-diagram .plantuml>The LEARCredential
                hide circle
                hide empty members

                class "<b>W3C Verifiable</b>\n<b>Credential</b>" as vc 
                class "<b>Verifiable</b>\n<b>Attestation</b>" as va
                vc <|-- va: extends

                package "Authn & Authz" <<Rectangle>> {
                    class "<b>VerifiableID</b>" as vid #Application {
                        For authentication
                    }
                    class "<b>Verifiable Authorisation</b>" as vau #Application {
                        For authorisation
                    }
                    class "<b>LEARCredential</b>" as lear #PaleGreen {
                        For authentication &
                        authorisation
                    }
                    va <|-- vid
                    va <|-- vau: extends

                    vau <|-- lear: extends
                    vid <|-- lear: extends
                }

                package "Other uses" <<Rectangle>> {
                    va <|-- "Other\nVerifiable Attestations"
                }

                class "<b>Employee</b>\n<b>credential</b>" as employee #Khaki
                class "<b>Customer</b>\n<b>credential</b>" as customer #Khaki
                class "<b>Machine</b>\n<b>credential</b>" as machine #Khaki
                lear <... employee: Instance of
                lear <... customer
                lear <... machine: Instance of


            The subject identified in the credential can authenticate to perform a protected process by using a special type of Verifiable Credential called `LEARCredential` (from <b>L</b>egal <b>E</b>ntity <b>A</b>uthorised <b>R</b>epresentation).

            To achieve a high level of legal certainty under eIDAS, the LEARCredential is:
            
            <ul>
                - signed or sealed with an eIDAS certificate which is either:

                    <ul>
                        - a <b>certificate for electronic seals</b> issued to a legal person by a <x-ref "qualified trust service provider">, or
                        - a <b>certificate for electronic signatures</b>, issued to a <b>legal representative of the legal person</b> by a qualified trust service provider.
                - signed using the <b>JSON Advanced Electronic Signature</b> format described in [[[JAdES]]]

            The LEARCredential includes claims identifying the subject of the credential and a description of the concrete powers that have been delegated by the legal representative of the organisation.

            By signing/sealing the credential with an eIDAS certificate, the legal representative attests that the powers described in the credential have been delegated to the subject (maybe under some conditions, also described in the credential).

            In this way, the LEARCredential has the same legal status as any other document in other formats (e.g., PDF) signed in an eIDAS-compliant way, but with all the advantages provided by the Verifiable Credential format.

            In addition, the LEARCredential includes cryptographic material that allows the subject of the credential to <b>use the credential as an online authentication mechanism</b> in a portal or API, by proving that the holder of the credential is the same entity identified in the credential.

            Any Verifier that trusts the eIDAS Trust Framework will be able to verify that:

            <ul>
                - <b>The entity presenting the LEARCredential (the holder) is the same as the one identified in the subject of the credential</b>
                - <b>A legal representative of the organisation has attested that the subject has the powers described in the credential</b>

            This enables the entity presenting the LEARCredential to start the process and to provide any additional required documentation as additional Verifiable Credentials to enable automatic verification of compliance with the process requirements (including Gaia-X credentials issued by the Compliance Service of Gaia-X). 

            Both types of eIDAS certificates mentioned above are an electronic attestation <b>that links electronic seal/signature validation data to a legal person and confirms the name of that person</b>. This way, the certificate, usually linked to the sealed/signed document, can be used to verify the identity of the creator of the seal/signature and whether the document has been sealed/signed using the corresponding private key.

            Before issuing a certificate like the above, the qualified trust service provider (QTSP) performs validations against `Authentic Sources` to authenticate the identity of the organisation under the eIDAS framework:

            <ul>
                - The data concerning the business name or corporate name of the organisation.
                - The data relating to the constitution and legal status of the subscriber.
                - The data concerning the extent and validity of the powers of representation of the applicant.
                - The data concerning the tax identification code of the organisation or equivalent code used in the country to whose legislation the subscriber is subject.

            The person controlling the above certificates can authorise a subject to perform some operations on behalf of the organisation (LEAR) by generating and signing a Verifiable Credential which:

            <ul>
                - Includes identification data of a subject
                - Includes claims stating the delegation of specific powers to perform a set of specific processes on behalf of the organisation
                - Includes a public key where the corresponding private key is controlled by the subject, enabling the subject to prove that she/he/it is the holder of the credential when it is being used in an authentication process like the ones used as examples in this document.

            The LEARCredential uses the `did:elsi` method for the identifiers of legal persons involved in the process, to facilitate the DID resolution and linkage with the eIDAS certificates. The `did:elsi` method is specified in [[[DID-ELSI]]]. But any other suitable DID method can be used is desired.
            
            The high-level view of the process is described in the following diagram, using as an example a COO (Chief Operating Officer) acting a legal entity representative and appointing an employee to perform some processes:

            <x-diagram .plantuml>High level view of issuance of LEARCredential to an employee
                box "Company" #WhiteSmoke
                    actor "Employee of company" as employee
                    participant "COO of company" as COO
                end box
                control "Trust Service Provider" as TSP
                database "Authentic Sources" as registry

                COO -> TSP ++: Request a\ncertificate for signatures

                TSP <-> registry: Verify trusted data
                
                TSP -> COO --: Provide certificate for signature

                COO -> employee: Issue LEARCredential


    <section>The LEARCredential through an example

        In this section we describe in detail the LEARCredential and for illustrative purpose we use example attributes from a fictitious ecosystem whose participants are described in Appendix <x-ref "participants">.

        In this example the LEARCredential will be generated using the eIDAS certificate of the COO (Chief Operation Officer) of the organisation that will be issuing the credential.

        The credential will be generated with an application that the COO will use as Issuer of the LEARCredential and that allows the employee to receive the credential using his credential wallet, using [[OpenID.VCI]] to achieve compliance with the EUDI Wallet ARF.

        This application enables the COO to attest the information required to create the LEARCredential, specifying the employee information and the specific type of LEARCredential. In general, there may be different instances of LEARCredentials for different purposes. One employee can have more than one LEARCredential, each having a different delegation of powers for different environments.

        The specific detailed use case here is the issuance of a LEARCredential to an employee to enable that employee to perform the onboarding process in an ecosystem. But exactly the same process with different attested attributes can be used by any organisation to issue credentials that can be accepted by other organisations for authentication and access control to any protected resources that they manage.

        The essential components of a LEARCredential are the following:

        <ul>
            - <b>Claims identifying the employee</b>

            - <b>DID of the employee to enable authentication</b>

            - <b>Claims identifying the legal representative</b>

            - <b>The roles and duties of the LEAR</b>

            - <b>Advanced/Qualified signature of the credential</b>

        These concepts are elaborated in the following sections. 

        <section>Claims identifying the employee

            These are claims identifying the subject of the credential, the person who will act as LEAR. Each ecosystem can define their own depending on their specific requirements.
                
            In addition, each organisation can specify their own for enabling access to its products/services. However, it is recommended to use a set of claims that are agreed upon by all participants in the ecosystem unless there are specific requirements for not doing so. This includes not only the amount of claims but also their syntax and semantics.

            For our example, we use the same that are used for accessing the European Commission portal. The claims in the credential are the digital equivalent of their analog counterparts, displayed here for illustration.

            <figure #lear-appointment-letter-1>
                <img src="images/lear-appointment-letter-1.png" alt="" />

                <figcaption>LEAR subject identification data.

            From the above form we can derive the following claims using the example data:

            <x-code .json>
                {
                    "title": "Mr.",
                    "first_name": "John",
                    "last_name": "Doe",
                    "gender": "M",
                    "postal_address": "",
                    "email": "johndoe@goodair.com",
                    "telephone": "",
                    "fax": "",
                    "mobile_phone": "+34787426623"
                }


        <section>DID of the employee

            In this example we use the `did:key` method for the DID of the employee, which provides a very high level of privacy and given the way the LEARCredential is generated it supports the verification of the chain of responsibility with a proper level of guarantee.

            If the highest levels of assurance and legal compliance are desired and the employee has an eIDAS certificate for signatures (in this case a personal one, not one like the COO), we could use the `elsi:did` method for identification of the employee. However, the organisation (GoodAir in our example) should make sure that the employee is aware of and agree to the possible privacy implications of doing so, given the personal details leaked from the eIDAS certificate.

            Those personal details are exactly the same as if the employee signs any document with a digital certificate, but care should be taken by the organisation because in this case the signature would be done "on behalf of" his employer and not as an individual personal action.

            Even though this is not unique to the `did:elsi` method, this also implies that the onboarding service has to handle those personal details in the same way as if it would be accepting any other document signed with a certificate for signatures, and ensure compliance with GDPR. This is "business as usual" when using digital signatures, but we want to make sure that this is taken care of when implementing the authentication and access control mechanisms described here.

            In this example we assume the usage of the `did:key` method for the employee to protect his privacy as much as possible.

            This DID for the employee is an additional claim to the ones presented above, using the `id` field in the `credentialSubject` object.
            
            Using this DID method has an additional advantage: the DID identifier corresponds to a keypair that is generated during the LEARCredential issuance process, where the private key is generated by the wallet of the employee and it is always under his control.

            This private key controlled by the employee can be used to sign challenges from Relying Parties that receive the credential to prove that the person sending the credential is the same person that is identified in the `credentialSubject` object of the LEARCredential.

            It is this property that makes this credential a VerifiableID that can be used for online authentication.

            An example DID for the employee could be:

            <x-code .json>
                {
                    "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
                }

            In this example, the signatures performed with the private key can not be JAdES-compliant ([[JAdES]]), but if the LEARCredential is attached to any other credential that is signed with this private key, then they can be traced up to the eIDAS certificate of the COO and so the chain of responsibility can be determined..

            With the DID for the employee, the set of claims identifying him would be then:

            <x-code .json>
                {
                    "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
                    "title": "Mr.",
                    "first_name": "John",
                    "last_name": "Doe",
                    "gender": "M",
                    "postal_address": "",
                    "email": "johndoe@goodair.com",
                    "telephone": "",
                    "fax": "",
                    "mobile_phone": "+34787426623"
                }

        <section>legalRepresentative

            This section identifies the natural person (the COO) who is a legal representative of the legal person (GoodAir) and that is nominating the employee identified in the credential.

            <x-code .json>
                "legalRepresentative": {
                    "cn": "56565656V Jesus Ruiz",
                    "serialNumber": "56565656V",
                    "organizationIdentifier": "VATES-12345678",
                    "o": "GoodAir",
                    "c": "ES"
                }


            <x-note>Attributes for natural and legal persons

                The attributes for natural persons and legal persons are derived from the <a href="https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/467109280/eidas_saml_attribute_profile_v1.0_2.pdf?version=1&modificationDate=1639417533738&api=v2">eIDAS SAML Attribute Profile (eIDAS Technical Sub-group, 22 June 2015)</a>.

                All attributes for the eIDAS minimum data sets can be derived from the <a href="https://ec.europa.eu/isa2/solutions/core-vocabularies_en/">ISA Core Vocabulary</a> and <a href="https://joinup.ec.europa.eu/collection/semic-support-centre/specifications">https://joinup.ec.europa.eu/collection/semic-support-centre/specifications</a>.

                In the case of natural persons refer to the <a href="https://joinup.ec.europa.eu/asset/core_person/asset_release/core-person-vocabulary">Core Person Vocabulary</a> and in the case of legal persons refer to definitions for <a href="https://joinup.ec.europa.eu/asset/core_business/asset_release/core-business-vocabulary">Core Business Vocabulary</a>.


        <section>Roles and Duties of the LEAR

            The LEARCredential should include a formal description with the roles and duties of the LEAR. This is the digital equivalent to the analog description in our example, which uses natural language:

            <figure #lear-appointment-letter-2>
                <img src="images/lear-appointment-letter-2.png" alt="" />

                <figcaption>LEAR roles and duties.

            <x-note>
                We do not yet have defined the actual mechanism that will be used for describing formally the roles and duties of the LEAR. The way we specify them below is just an example. There is work ongoing to define the detailed mechanism formally (e.g. with ODRL), and it is expected to change. This example is intended only to describe the concepts in detail.

            The `rolesAndDuties` object points to an externally hosted object with the roles and duties of the LEAR. This external object can be either a machine-interpretable definition of the roles and duties in the credential, or just an external definition of the roles and duties in natural language. The ideal approach is the first option, expressing the semantics with a proper machine-readable language, because this will allow automatic access control at the granularity of the individual sentences of that expression language. The `rolesAndDuties` object can also have the definition embedded into it, instead of having a pointer to an external object.

            A simplistic implementation of the object inside the credential could be:

            <x-code .json>
                "rolesAndDuties": [
                    {
                        "type": "LEARCredential",
                        "id": "https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"
                    }
                ]

            Where the last part of the url can correspond to the hash of the external linked document to ensure that any modification or tampering can be detected. The contents of that object ata that url could be:

            <x-code .json>
                [
                    {
                        "id": "https://dome-marketplace.eu//lear/v1/6484994n4r9e990494",
                        "target":"https://bae.dome-marketplace.eu/"
                        "roleNames": ["seller", "customer"]
                    }
                ]

            In the above example, we have specified that the roles object referenced in the credential with `id: https://dome-marketplace.eu//lear/v1/6484994n4r9e990494` is granting the employee of GoodAir (in our example) to access services in the DOME marketplace (specified with the field `target`) with the roles `seller` and `customer` (which are the roles of the <a href="https://business-api-ecosystem.readthedocs.io/en/latest/index.html">FIWARE BAE component</a>).

            If `target` is omitted, the roles would apply to any target organisation. If we need to specify more than one target organisation, the array should include as many objects as required.

        <section>Assembling the pieces together

            With the above values for the example, the complete LEARCredential would become something like this:

            <x-code .json>
                {
                    "@context": [
                        "https://www.w3.org/2018/credentials/v1",
                        "https://dome-marketplace.eu//2022/credentials/learcredential/v1"
                    ],
                    "id": "urn:did:elsi:25159389-8dd17b796ac0",
                    "type": ["VerifiableCredential", "LEARCredential"],
                    "issuer": {
                        "id": "did:elsi:VATES-12345678"
                    },
                    "issuanceDate": "2022-03-22T14:00:00Z",
                    "validFrom": "2022-03-22T14:00:00Z",
                    "expirationDate": "2023-03-22T14:00:00Z",
                    "credentialSubject": {
                        "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
                        "title": "Mr.",
                        "first_name": "John",
                        "last_name": "Doe",
                        "gender": "M",
                        "postal_address": "",
                        "email": "johndoe@goodair.com",
                        "telephone": "",
                        "fax": "",
                        "mobile_phone": "+34787426623",
                        "legalRepresentative": {
                            "cn": "56565656V Jesus Ruiz",
                            "serialNumber": "56565656V",
                            "organizationIdentifier": "VATES-12345678",
                            "o": "GoodAir",
                            "c": "ES"
                        },
                        "rolesAndDuties": [
                            {
                                "type": "LEARCredential",
                                "id": "https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"
                            }
                        ]
                    }
                }


    <section>Issuing the LEARCredential

        <section>Overview

            In this example we use what we call a <i>profile</i> of the [[OpenID.VCI]] protocol. The standard is very flexible, and we restrict the different options available in the standard and implement a set of the options with given values that are adequate for our use case, without impacting flexibility in practice.

            The following figure describes the main components that interact in the issuance of a credential in this profile.

            The description of the issuance process is general enough to be used for many types of credentials, but the text includes notes describing the concrete application of the process to the case of the LEARCredential.

            <figure #iss-overview>
                <img src="images/issuance/issuance_background.svg" alt="" />

                <figcaption>Overview of participants.

            <b>End user</b>

            This profile is valid for both natural and juridical persons, but because we are focusing on the issuance of the LEARCredential, in the detailed examples below we assume a natural person as the user.

            <b>Wallet</b>

            The wallet is assumed to be a Web application with a wallet backend, maybe implemented as a PWA so it has some offline capabilities and can be installed in the device, providing a user experience similar to a native application. Private key management and most sensitive operations are performed in a backend server, operated by an entity trusted by the end user. Other profiles can support native and completely offline PWA mobile applications, for end users.

            This type of wallet supports natural persons, juridical persons and natural persons who are legal entity representatives of juridical persons. For juridical persons the wallet is usually called an `enterprise wallet` but we will use here just the term `wallet` unless the distinction is required.

            In this profile we assume that the wallet is not previously registered with the Issuer and that the wallet does not expose public endpoints that are called by the Issuer, even if the wallet has a backend server that could implement those endpoints. That makes the wallet implementations in this profile to be very similar in interactions to a full mobile implementation, making migration to a full mobile implementation easier.

            In other words, from the point of view of the Issuer, the wallet in this profile is almost indistinguishable from a full mobile wallet.

            <b>User Laptop</b>

            For clarity of exposition, we assume in this profile that the End User starts the interactions with the Issuer with an internet browser (user agent) in her laptop. However, there is nothing in the interactions which limits those interactions to a laptop form factor and the End User can interact with any internet browser in any device (mobile, tablet, kiosk).

            <b>Issuer</b>

            In this profile we assume that the Issuer is composed of two components:

            <ul>
                - <b>Authorization server</b>: the backend component implementing the existing authentication/authorization functionalities for the Issuer entity.
                - <b>Issuer backend</b>: the main server implementing the business logic as a web application and additional backend APIs required for issuance of credentials.

            The Issuer backend and the Authorization server could be implemented as a single component in an actual deployment, but we assume here that they are separated to make the profile more general, especially for big entities and also when using Trust Service Providers for cloud signature and credential issuance, for example.

            <b>Authentication of End User and previous Issuer-End User relationship</b>

            We assume that the Issuer and End User have a previous relationship and that the Issuer has performed the KYC required by regulation and needed to be able to issue Verifiable Credentials attesting some attributes about the End User. We assume that there is an existing trusted authentication mechanism (not necessarily related to Verifiable Credentials) that the End User employs to access protected resources from the Issuer. For example, the user is an employee or a customer of the Issuer, or the Issuer is a Local Administration and the End User is a citizen living in that city.


        <section>Authentication

            <figure #iss-authentication>
                <img src="images/issuance/issuance_authentication.svg" alt="" />

                <figcaption>Issuance authentication.


            Before requesting a new credential, the End User has to authenticate with the Issuer with whatever mechanism is already implemented by the Issuer. This profile does not require that it is based on OIDC, Verifiable Credentials or any other specific mechanism.

            The level of assurance (LoA) of this authentication mechanism is one of the factors that will determine the confidence that the Verifiers can have on the credentials received by them from a given Issuer.

            <x-note>LEARCredential
                In the case of the LEARCredential, the End User (John Doe) is an employee of GoodAir and in order to receive the credential John first has to authenticate into the company systems using whatever mechanism GoodAir uses for employee authentication.
                
                Being a modern company, GoodAir uses Verifiable Credentials IAM but this is not a requirement for the issuance of the LEARCredential.


        <section>Credential Offer

            <figure #iss-credentialoffer>
                <img src="images/issuance/issuance_credentialoffer.svg" alt="" />

                <figcaption>Credential offer.

            In this profile the wallet does not have to implement the Credential Offer Endpoint described in section 4 of [[OpenID.VCI]].

            Instead, the Credential Issuer renders a QR code containing a reference to the Credential Offer that can be scanned by the End-User using a Wallet, as described in section 4.1 of [[OpenID.VCI]].

            According to the spec, the Credential Offer object is a JSON object containing the Credential Offer parameters and can be sent by value or by reference. To avoid problems with the size of the QR travelling in the URL, this profile requires that the QR contains the `credential_offer_uri`, which is a URL using the `https` scheme referencing a resource containing a JSON object with the Credential Offer parameters. The `credential_offer_uri` endpoint should be implemented by the Issuer backend.


            <section>Credential Offer Parameters

                This profile restricts the options available in section 4.1.1 of [[OpenID.VCI]]. The profile defines a Credential Offer object containing the following parameters:

                <ul>
                    - `credential_issuer`: REQUIRED. The URL of the Credential Issuer that will be used by the Wallet to obtain one or more Credentials.

                    - `credentials`: REQUIRED. A JSON array, where every entry is a JSON string. To achieve interoperability faster, this profile defines a global Trusted Credential Schemas List where well-known credential schemas are defined, in addition to the individual credentials that each Issuer can define themselves. The string value MUST be one of the id values in one of the objects in the `credentials_supported` metadata parameter of the Trusted Credential Schemas List (described later), or one of the id values in one of the objects in the `credentials_supported` Credential Issuer metadata parameter provided by the Credential Issuer. When processing, the Wallet MUST resolve this string value to the respective object. The credentials defined in the global Trusted Credential Schema List have precedence over the ones defined by the Credential Issuer.

                        <x-note>LEARCredential
                            The only credential being offered in our case is the LEARCredential, so this is the credential schema that should be specified here. The LEARCredential is a credential known globally to the DOME ecosystem, so its schema should be published and be available in the Trusted Credential Schemas List.

                    - `grants`: REQUIRED. A JSON object indicating to the Wallet the Grant Type `pre-authorized_code`. This grant is represented by a key and an object, where the key is `urn:ietf:params:oauth:grant-type:pre-authorized_code`. In this profile the credential issuance flow requires initial authentication of the End User by the Credential Issuer, so the Pre-Authorized Code Flow achieves a good level of security and we do not need the more general Authorization Code Flow.

                        In other scenarios like when the wallet is a native mobile application and the user interacts with the Issuer exclusively with the mobile (without the laptop), then the Authorization Code Flow has to be used. This can be described in detail in a different profile.

                The grant object contains the following values:

                <ul>
                    - `pre-authorized_code`: REQUIRED. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code MUST be short lived and single-use. This parameter value MUST be included in the subsequent Token Request with the Pre-Authorized Code Flow.

                    - `user_pin_required`: REQUIRED. The [[OpenID.VCI]] standard says it is RECOMMENDED, but this profile specifies the user pin to achieve a greater level of security. This field is a boolean value specifying whether the Credential Issuer expects presentation of a user PIN along with the Token Request in a Pre-Authorized Code Flow. Default is false. This PIN is intended to bind the Pre-Authorized Code to a certain transaction in order to prevent replay of this code by an attacker that, for example, scanned the QR code while standing behind the legit user. It is RECOMMENDED to send a PIN via a separate channel. The PIN value MUST be sent in the `user_pin` parameter with the respective Token Request.

                The following non-normative example shows a Credential Offer object where the Credential Issuer offers the issuance of one Credential ("LEARCredential"):

                <x-code .json>
                    {
                        "credential_issuer": "https://www.goodair.com",
                        "credentials": [
                            "LEARCredential"
                        ],
                        "grants": {
                            "urn:ietf:params:oauth:grant-type:pre-authorized_code": {
                                "pre-authorized_code": "asju68jgtyk9ikkew",
                                "user_pin_required": true
                            }
                        }
                    }


            <section>Contents of the QR code

                Below is a non-normative example of the Credential Offer displayed by the Credential Issuer as a QR code when the Credential Offer is passed by reference, as required in this profile:

                <x-code .INI>
                    https://www.goodair.com/credential-offer?
                    credential_offer_uri=https%3A%2F%2Fserver%2Eexample%2Ecom%2Fcredential-offer%2F5j349k3e3n23j

                Which in plain text would be:

                <x-code .INI>
                    https://www.goodair.com/credential-offer?
                    credential_offer_uri=https://www.goodair.com/credential-offer/5j349k3e3n23j


                To increase security, the Issuer MUST make sure that every Credential Offer URI is unique for all credential offers created. This is the purpose of the nonce (`5j349k3e3n23j`) at the end of the url in the example. Issuers can implement whatever mechanism they wish, as far as it is transparent to the wallet.

        <section>Credential Issuer Metadata

            The Wallet backend retrieves the Credential Issuer's configuration using the Credential Issuer Identifier that was received in the Credential Offer.

            A Credential Issuer is identified in this context by a case sensitive URL using the https scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components. No DID is used in this context.

            Credential Issuers MUST make a JSON document available at the path formed by concatenating the string `/.well-known/openid-credential-issuer` to the Credential Issuer Identifier. If the Credential Issuer value contains a path component, any terminating / MUST be removed before appending `/.well-known/openid-credential-issuer`.

            `openid-credential-issuer` MUST point to a JSON document compliant with this specification and MUST be returned using the `application/json` content type.

            The retrieval of the Credential Issuer configuration is illustrated below.

            <figure #iss-issuermetadata>
                <img src="images/issuance/issuance_issuermetadata.svg" alt="" />

                <figcaption>Issuer metadata.

            <section>Credential Issuer Metadata Parameters

                The object contained in `openid-credential-issuer` contains the following:

                <ul>
                    - `credential_issuer`: REQUIRED. The Credential Issuer's identifier.

                    - `credential_endpoint`: REQUIRED. URL of the Credential Issuer's Credential Endpoint. This URL MUST use the https scheme and MAY contain port, path and query parameter components.

                    - `credentials_supported`: REQUIRED. A JSON array containing a list of JSON objects, each of them representing metadata about a separate credential type that the Credential Issuer can issue. The JSON objects in the array MUST conform to the structure of the Section XXXX.

                TODO: define a global directory of credentials supported to eliminate requirement for each individual Issuer to publish its own list.

                This profile does not make use of the following parameters:

                <ul>
                    - `authorization_server` parameter, because it uses the `pre-authorized_code` Grant type.

                    - `batch_credential_endpoint` parameter. It indicates that the Credential Issuer does not support the Batch Credential Endpoint.

                    - `display` parameter.


        <section>OAuth 2.0 Authorization Server Metadata

            This specification also defines a new OAuth 2.0 Authorization Server metadata [[RFC8414]] parameter to publish whether the AS that the Credential Issuer relies on for authorization, supports anonymous Token Requests with the Pre-authorized Grant Type. It is defined as follows:

            <ul>
                - `pre-authorized_grant_anonymous_access_supported`: OPTIONAL. A JSON Boolean indicating whether the issuer accepts a Token Request with a Pre-Authorized Code but without a client id. The default is false.


        <section>Access Token

            <figure #issuance_accesstoken>
                <img src="images/issuance/issuance_accesstoken.svg" alt="" />

                <figcaption>Access Token.

            The Wallet invokes the Token Endpoint implemented by the Authorization Server, which issues an Access Token and, optionally, a Refresh Token in exchange for the Pre-authorized Code that the wallet obtained in the Credential Offer.

            <section>Token Request

                After the wallet receives the Credential Issuer Metadata, a Token Request is made as defined in Section 4.1.3 of [[RFC6749]].

                The following are the extension parameters to the Token Request used in a Pre-Authorized Code Flow as used in this profile:

                <ul>
                    - `pre-authorized_code`: REQUIRED. The code representing the authorization to obtain Credentials of a certain type.

                    - `user_pin`: OPTIONAL. String value containing a user PIN. This value MUST be present if user_pin_required was set to true in the Credential Offer. The string value MUST consist of a maximum of 8 numeric characters (the numbers 0 - 9).

                In this profile the Wallet does not have to authenticate when using the Token Endpoint, because we are using the Pre-Authorized Code Grant Type, given the level of trust between the Issuer and the End User and that authentication was already performed at the beginning of the flow.

                Below is a non-normative example of a Token Request:

                <x-code .HTTP>
                    POST /token HTTP/1.1
                    Host: server.example.com
                    Content-Type: application/x-www-form-urlencoded

                    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apre-authorized_code
                    &pre-authorized_code=SplxlOBeZQQYbYS6WxSbIA
                    &user_pin=493536


            <section>Successful Token Response

                Token Responses are made as defined in [[RFC6749]].

                In addition to the response parameters defined in [[RFC6749]], the Authorization Server returns the following parameters:

                <ul>
                    - `c_nonce`: REQUIRED. JSON string containing a nonce to be used to create a proof of possession of key material when requesting a Credential. The Wallet MUST use this nonce value for its subsequent credential requests until the Credential Issuer provides a fresh nonce.

                    - `c_nonce_expires_in`: REQUIRED. JSON integer denoting the lifetime in seconds of the c_nonce.

                Below is a non-normative example of a Token Response:

                <x-code .HTTP>
                    HTTP/1.1 200 OK
                    Content-Type: application/json
                    Cache-Control: no-store

                    {
                        "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
                        "token_type": "bearer",
                        "expires_in": 86400,
                        "c_nonce": "tZignsnFbp",
                        "c_nonce_expires_in": 86400
                    }

            <section>Token Error Response

                If the Token Request is invalid or unauthorised, the Authorization Server constructs the error response as defined in section 6.3 of [[OpenID.VCI]].


        <section>Request and receive Credential

            <figure #issuance_requestcredential>
                <img src="images/issuance/issuance_requestcredential.svg" alt="" />

                <figcaption>Request and receive Credential.


            The Wallet backend invokes the Credential Endpoint, which issues a Credential as approved by the End-User upon presentation of a valid Access Token representing this approval.

            Communication with the Credential Endpoint MUST utilise TLS.

            The client can request issuance of a Credential of a certain type multiple times, e.g., to associate the Credential with different public keys/Decentralised Identifiers (DIDs) or to refresh a certain Credential.

            If the Access Token is valid for requesting issuance of multiple Credentials, it is at the client's discretion to decide the order in which to request issuance of multiple Credentials requested in the Authorization Request.


            <section>Binding the Issued Credential to the identifier of the End-User possessing that Credential

                The Issued Credential MUST be cryptographically bound to the identifier of the End-User who possesses the Credential. Cryptographic binding allows the Verifier to verify during the presentation of a Credential that the End-User presenting a Credential is the same End-User to whom that Credential was issued.

                The Wallet has to provide proof of control alongside key material using the mechanism described below.

            <section>Credential Request

                The Wallet backend makes a Credential Request to the Credential Endpoint by sending the following parameters in the entity-body of an HTTP POST request using the `application/json` media type.

                <ul>
                    - `format`: REQUIRED. This profile uses the Credential format identifier `jwt_vc_json`.

                    - `proof`: OPTIONAL. JSON object containing proof of possession of the key material the issued Credential shall be bound to. The specification envisions use of different types of proofs for different cryptographic schemes. The proof object MUST contain a `proof_type` claim of type JSON string denoting the concrete proof type. This type determines the further claims in the proof object and its respective processing rules. Proof types are defined in Section [[[#proof_type]]].

                The proof element MUST incorporate a `c_nonce` value generated by the Credential Issuer and the Credential Issuer Identifier (audience) to allow the Credential Issuer to detect replay. The way that data is incorporated depends on the proof type. In a JWT, for example, the `c_nonce` is conveyed in the `nonce` claim whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the challenge element in the proof object and the Credential Issuer (the intended audience) is included as the domain element.

                <section #proof_type>Proof Type

                    This specification defines only one value for `proof_type`:

                    `jwt`: objects of this type contain a single jwt element with a JWS [[RFC7515]] as proof of possession. The JWT MUST contain the following elements:

                        <ul>
                            - in the JOSE Header,

                                <ul>
                                    - `typ`: REQUIRED. MUST be `openid4vci-proof+jwt`, which explicitly types the proof JWT as recommended in Section 3.11 of [[RFC8725]].

                                    - `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. MUST NOT be none or an identifier for a symmetric algorithm (MAC).

                                    - `kid`: REQUIRED. JOSE Header containing the key ID. The Credential will be bound to a DID, so the kid refers to a DID URL which identifies a particular key in the DID Document that the Credential will be bound to.

                            - in the JWT body,

                                <ul>
                                    - `aud`: REQUIRED (string). The value of this claim MUST be the Credential Issuer URL of the Credential Issuer.

                                    - `iat`: REQUIRED (number). The value of this claim MUST be the time at which the proof was issued using the syntax defined in [[RFC7519]].

                                    - `nonce`: REQUIRED (string). The value type of this claim MUST be a string, where the value is the `c_nonce` provided by the Credential Issuer.

                    The Credential Issuer MUST validate that the proof is actually signed by a key identified in the JOSE Header.

                    Below is a non-normative example of a proof parameter (dots in the middle of jwt for display purposes only), for the example of issuing a LEARCredential:

                    <x-code .json>
                        {
                            "proof_type": "jwt",
                            "jwt": "eyJraWQiOiJkaWQ6ZXhhb....aZKPxgihac0aW9EkL1nOzM"
                        }

                    where the JWT looks like this:

                    <x-code .json>
                        {
                            "typ": "openid4vci-proof+jwt",
                            "alg": "ES256",
                            "kid":"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
                        }

                        {
                            "iss": "s6BhdRkqt3",
                            "aud": "https://www.goodair.com",
                            "iat": 1659145924,
                            "nonce": "tZignsnFbp"
                        }

                    In the example of a LEARCredential, the wallet generates a pair of public/private keys and a `did:key` identifier which is univocally related to the public key. This is the reason why the `kid` field above is exactly the DID identifier under this DID method. The `did:key` method is very simple and achieves a very high degree of privacy, allowing the creation of many different identifiers which can be one-use only if so desired.

                    The `did:key` method is perfect for the requirements of our usage of the LEARCredential. Any other suitable DID method can be used if it is required, but this is out of scope for this profile.

            <section>Credential Response

                This profile restricts Credential Response to be Synchronous and Deferred response is not used. The Credential Issuer MUST be able to immediately issue a requested Credential and send it to the Client.

                The following claims are used in the Credential Response:

                <ul>
                    - `format`: REQUIRED. JSON string denoting the format of the issued Credential. This profile uses the format identifier `jwt_vc_json`.

                    - `credential`: REQUIRED. Contains issued Credential. MUST be a JSON string.

                    - `c_nonce`: OPTIONAL. JSON string containing a nonce to be used to create a proof of possession of key material when requesting a Credential. When received, the Wallet MUST use this nonce value for its subsequent credential requests until the Credential Issuer provides a fresh nonce.

                    - `c_nonce_expires_in`: OPTIONAL. JSON integer denoting the lifetime in seconds of the c_nonce.

                Below is a non-normative example of a Credential Response:

                <x-code .HTTP>
                    HTTP/1.1 200 OK
                    Content-Type: application/json
                    Cache-Control: no-store

                    {
                        "format": "jwt_vc_json",
                        "credential" : "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
                        "c_nonce": "fGFF7UkhLa",
                        "c_nonce_expires_in": 86400
                    }

            <section>Credential Error Response

                When the Credential Request is invalid or unauthorised, the Credential Issuer constructs the error response as defined in section 7.3.1 of OIDCVCI.

            <section>Credential Issuer Provided Nonce

                Upon receiving a Credential Request, the Credential Issuer MUST require the Wallet to send a proof of possession of the key material it wants a Credential to be bound to. This proof MUST incorporate a nonce generated by the Credential Issuer. The Credential Issuer will provide the client with a nonce in an error response to any Credential Request not including such a proof or including an invalid proof.

                Below is a non-normative example of a Credential Response with the Credential Issuer requesting a Wallet to provide in a subsequent Credential Request a proof that is bound to a `c_nonce`:

                <x-code .http>
                    HTTP/1.1 400 Bad Request
                    Content-Type: application/json
                    Cache-Control: no-store

                    {
                        "error": "invalid_or_missing_proof",
                        "error_description":
                            "Credential Issuer requires proof to be bound to a Credential Issuer provided nonce.",
                        "c_nonce": "8YE9hCnyV2",
                        "c_nonce_expires_in": 86400
                    }


    <section>Authenticating with Verifiable Credentials

        <section>Overview

            Authentication requires a special type of Verifiable Credential called a VerifiableID. For the examples illustrating the mechanism we will use a LEARCredential, which is at the same time a VerifiableId and a Verifiable Authorization.

            For the explanation we will use the following figure which is based on [[[NIST-AUTH]]] which describes a reference architecture with necessary functional components to achieve authentication and enforcement of the authorization policies. The authorization process depends on four layers of functionality: <b>Enforcement</b>, <b>Decision</b>, <b>Access Control Data</b>, and <b>Administration</b>.

            The diagram uses the logical concepts also used in the XACML reference architecture, but the description is agnostic to the actual policy language used in a concrete implementation.

            In this description we assume that the user is a natural person who wants to access a protected resource. However, the architecture supports machine-to-machine (M2M) interactions. The differences will be described in the description when they are relevant.

            <x-img @images/login_in_DOME/authn_architecture_numbered.drawio.png>Architecture overview 

            The high level flow is the following:

            <ul .plain>

                -(1) The user sends a request to access a protected resource managed by the Relying Party.
                
                -(2) Every request to a protected resource is intercepted by the PEP (Policy Enforcement Point). The PEP is normally implemented as a reverse proxy or API gateway, so all calls to protected resources entering the organisation are intercepted and forwarded only if they are accepted. If the request does not come with authentication information, there are several high level scenarios which are possible:

                    <ul>
                        - If the user is a machine using an API, the request is rejected with an error. The caller is responsible for authenticating before retrying, which can be done using the metadata about the Relying Party available at the standard OpenID endpoints.

                        - If the user is a natural person using a browser for navigating the portal of the Relying Party, the typical approach is to redirect the browser to the authentication component using an HTTP Status of 302. The redirection includes enough information so the authentication component can send back the user to the original request if the user completes authentication successfully.
                        
                    Alternatively, the request can include authentication information which has been obtained before via an authentication process. If this is the case, the PEP goes directly into the authentication phase, described later in section <x-ref "accesscontrol">.

                -(3) The user is redirected to the authentication component. As mentioned before, alternatively the authorization component can be accessed directly by the user before trying to access the protected resource. This would be the expected behaviour of a user who knows that authentication is required. The mechanism described here supports all possible scenarios both for natural persons and machines.

                    An example flow with a natural person would be: The user navigates first to a general Login page in the portal of the Relying Party and authenticates. After authentication the portal presents a collection of services that the user can access. The user selects one of the services/operations and the Relying Party executes the operation if the user is authorised to do so.

                -(4) The Verifiable Credentials verifier component of the Relying Party retrieves the credentials that are required for authentication. If the user has been redirected when trying to access a protected resource, the redirection provides information about the operation and protected resource that was trying to access, so there may be more credentials required than just a VerifiableID.

                    If the user accessed the Login page directly, the VC Verifier component does not have information about the resource that the user intends to access, so it can request just a VerifiableID.

                -(5) The VC Verifier component of the Relying Party and the Wallet of the user engage in a Verifiable Presentation Exchange flow, where the result is that the VC Verifier receives a VerifiableID and possibly additional Verifiable Credentials as determined in step 4.

                -(6) The authorization mechanism uses the Trust Framework to query different Trusted Lists that are needed to evaluate the policy rules applicable to the request and compute a decision.

                    The Trust Framework is composed of one or more Trusted Lists where each list is specialised in some specific domain of trust.

                    For example, the Trust Framework contains Trusted Lists with the schema definitions used for the well-known types of Verifiable Credentials in the ecosystem. In this way, if the Verifiable Registry used for the Trust Framework is based on a Blockchain network (or several federated networks), the schemas can be published in a trusted and resilient manner reducing the risk of malicious tampering and keeping a record of the history of modifications.

                    But the most interesting Trusted Lists in the Trust Framework are the Trusted Issuers Lists, which provide the mechanism to efficiently and securely verify that the issuer of a given credential is a Trusted Issuer of that type of credentials.

                    It has to be noticed that even though most Trusted Issuer Lists are global (used by all participants in the ecosystem) and have essentially public information, there may be some specialised lists that are private to one or more organisations and specialised in some specific requirement.

                    In this way, there may be some lists that are specific to the products that one organisation provides to other participants in the ecosystem. For example, there may be a Trusted Issuer List private to one organisation which is updated with the identity of a participant when that participant acquires access to some product provided by that organisation.

                    For example, this "product-specific" Trusted Issuer List is queried when performing authorization if the related policy rules specify that the issuer of the Verifiable Credential received in the request should have acquired the product that the request is trying to access.

                    However, as mentioned before, the set of "internal" and "external" Trusted Lists to query is not hardcoded but it depends on the specific policy rules that should be applied to the request when computing the decision to grant access or not.

                    In this way, the system provides a great deal of flexibility on how access control is performed.

                    For simplicity, the diagram below shows the query of the Trusted Issuer Lists as a single interaction to a single box, but the actual interactions can be very complex if required. In addition, the diagram does not specify whether the list is "private" or "global".

            The following sections elaborate in more detail in each of the interactions.
            

        <section>Starting the OpenID for Verifiable Presentations flow

            In this section we assume that the user tries to access a protected resource and that the user is not authenticated. The flow when the user is already authenticated is the same, just skipping the authentication phase (steps 1 to 6).

            The authentication process starts an OpenID for Verifiable Presentations flow combined with the Self-Issued OP v2 specification [[OpenID.SIOP2]], where the VC Verifier component of the portal plays the role of a Relying Party (RP in Open ID Connect terminology) and the wallet of the user is a Self-Issued IdP.
            
            In this step, the Verifier has to send an Authorization Request to the wallet. But as a Self-Issued OP may be running locally as a native application or progressive web application (PWA), the RP may not have a network-addressable endpoint to communicate directly with the OP. We have to leverage the implicit flow of OpenID Connect to communicate with such locally-running Ops, as described in [[OpenID.SIOP2]].

            We use a QR code to start the process and allow the wallet to receive the Authorization Request from the Verifier, and respond with an Authorization Response, sent to the Verifier in the body of an HTTP `POST` request.

            <x-diagram .plantuml>Starting the authentication phase
                box "Company" #WhiteSmoke
                    actor "User" as user
                    participant "Wallet" as mobile
                    participant "Laptop" as browser
                end box
                box "Relying Party" #WhiteSmoke
                    participant "Portal" as portal
                    participant "VC Verifier" as verifier
                end box

                user -> browser ++: **(1)** Access DOM portal
                # -(1) The user (GoodAir employee) uses his Laptop browser to access the DOME portal to perform the onboarding process.

                    We assume in this scenario a cross-device interaction, that is, the user accesses the portal services with a PC browser, but authentication is performed with a mobile using Verifiable Credentials, as in typical 2-factor authentication.

                browser -> portal --++: **(2)** Access DOM portal
                # -(2) The browser sends a request to the Packet Delivery portal server.

                portal -> browser --++: **(3)** HTTP 302 (redirect)
                browser -> verifier --++: **(3 cont)** Access Login page
                # -(3) The portal redirects the user to the login page of the Verifier component of DOME Onboarding. The page shows a button labelled “Login with Verifiable Credentials” or something similar.

                verifier -> verifier: **(4)** Generate QR code
                # -(4) The Verifier generates a QR code, containing inside the URL of the `/authentication-requests` endpoint of the Verifier component which will be used to start the [[OpenID.VP]] process.

                    A QR code is used because a Self-Issued OP may be running locally as a native application or progressive web application (PWA), the RP may not have a network-addressable endpoint to communicate directly with the OP. We have to leverage the implicit flow of OpenID Connect to communicate with such locally-running Ops, as described in [[OpenID.SIOP2]].

                    <x-code .ini>
                        https://verifier.dome-marketplace.eu/authorization-requests?state=af0ifjsldkj

                # -(5) The QR code is displayed in the user browser with instructions to scan it and go to the URL inside it.

                    <figure #qr_code_authreq>
                        <img src="images/qrcode-authreq.png" alt="" />

                        <figcaption>QR code with the example Authorization Request endpoint inside

                verifier -> browser --: **(5)** Display QR code

                # -(6) The user scans the QR with his wallet and tells the wallet to go to the URL in the QR.
                user -> mobile ++: **(6)** Start QR scan
                browser --> mobile: Scan QR code

                mobile -> verifier --++: **(7)** GET /authorization-requests
                # -(7) After confirmation by the user, the wallet performs a `GET /authentication-requests` to the endpoint that was inside the QR code. The reply to the GET request is an Authorization Request


                verifier -> verifier: **(8)** Create Authorization Request
                # -(8) The VC Verifier creates a SIOP Authentication Request. The parameters comprising a request for verifiable presentations are described in detail in the next section

                verifier -> mobile --: **(9)** Reply with Authorization Request
                # -(9) The Verifier replies to the wallet with the Authorization Request


        <section>Generating the Authorization Request

            The Authorization Request travels in the response body of the HTTP GET request performed in the previous point, as a JWT signed by the DOME onboarding service, using the eIDAS certificate for seals that corresponds to the legal person operating the service and with the JAdES signature format.

            The parameters comprising a request for verifiable presentations are given in section 5 of [[OpenID.VP]] and in section 10.1 of [[OpenID.SIOP2]] and are reproduced here with the particularities of this use case, in particular taking into account that this is a cross-device interaction:

            <ul>

                -(response_type) (REQUIRED). Must be `vp_token`. This parameter is defined in [[RFC6749]]. The possible values are determined by the response type registry established by [[RFC6749]]. The [[OpenID.VP]] specification introduces the response type `vp_token`. This response type asks the Wallet to return only a VP Token in the Authorization Response, which is what we want in our case.

                -(scope) (REQUIRED). This parameter is defined in [[RFC6749]] which allows it to be used by verifiers to request presentation of credentials by utilizing a pre-defined scope value designating the type of credential. See section <x-ref "request_scope"> for more details. We use in this instance the value `dome.credentials.presentation.LEARCredential` which means that the RP (DOME onboarding service) is asking the SIOP (user wallet) to send a credential of type `LEARCredential`.

                -(response_mode) REQUIRED. MUST be `direct_post`. As this is a cross-device scenario, this response mode is used to instruct the Self-Issued OP to deliver the result of the authentication process to a certain endpoint using the HTTP POST method. This endpoint to which the SIOP shall deliver the authentication result is conveyed in the parameter `redirect_uri` described below.

                -(redirect_uri) (REQUIRED). MUST be a valid RP endpoint. The Authentication Response is sent to this endpoint using `POST` and encoding `application/json`).

                -(client_id) REQUIRED. MUST be the DID of the RP (DOM onboarding entity) so it can be resolved by the SIOP and checked against a Trusted List, or rejected if it does not pass validation. This provides a high level of assurance to the SIOP that the RP is really who it claims.

                -(client_id_scheme) REQUIRED. MUST have the value `did`. This value indicates that the Client Identifier is a DID defined in [[DID-Core]]. The request MUST be signed with a private key associated with the DID. To obtain the corresponding private key, the Wallet MUST use DID Resolution defined by the DID method used by the Verifier. For most DID methods and since the associated DID Document may include multiple public keys, a particular public key used to sign the request in question MUST be identified by the kid in the JOSE Header. However, in our case the Verifier uses `did:elsi` and so the request MUST be signed with the eIDAS certificate according to the [[JAdES]] format, which defines the mechanism to identify the public key.
                
                    All Verifier metadata other than the public key MUST be obtained from the client_metadata or the `client_metadata_uri parameter` as defined in Section 5 of [[OpenID.VP]].

                -(nonce) REQUIRED. This parameter follows the definition given in [[OpenID.Core]]. It is used to securely bind the verifiable presentation(s) provided by the wallet (SIOP) to the particular transaction managed by the RP.

                -(state) REQUIRED. Used by the portal component of DOM onboarding to associate the start of an authentication session with the end of that session when the RP Verifier component notifies to the portal.

                -(presentation_definition) CONDITIONAL. A string containing a `presentation_definition` JSON object as defined in Section 4 of [[DIF.PresentationExchange]]. We do not use this parameter because `scope` already specifies the credential type.

                -(presentation_definition_uri) CONDITIONAL. A string containing a URL pointing to a resource where a `presentation_definition` JSON object as defined in Section 4 of [[DIF.PresentationExchange]] can be retrieved. We do not use this parameter because `scope` already specifies the credential type.


            Note: A request MUST contain either a `presentation_definition` or a `presentation_definition_uri` or a single `scope` value representing a presentation definition, those three ways to request credential presentation are mutually exclusive. We use here the `scope` mechanism, which is simpler and fits our use case.

            This is an example request object using the definitions above:

            <x-code .ini>
                openid://?
                scope=dome.credentials.presentation.LEARCredential&
                response_type=vp_token&
                response_mode=direct_post&
                client_id=did:elsi:VATFR-99999999&
                redirect_uri=https://verifier.dome-marketplace.eu/api/authentication_response&
                state=af0ifjsldkj&
                nonce=n-0S6_WzA2Mj

            (URL encoding removed, line breaks and leading spaces added for readability).

            As mentioned above, the Authentication Request is returned to the wallet in the reply body of the GET request, as a JWT in JWS form [[RFC7515]]), signed with eIDAS certificate of the DOM onboarding legal person.

            This is an example of the unencoded contents of the payload of the JWT:

            <x-code .json>
                {
                    "iss": "did:elsi:VATFR-99999999",   // Should correspond with the client_id in the AR
                    "sub": "did:elsi:VATFR-99999999",   // Should correspond with the client_id in the AR
                    "aud": "https://self-issued.me/v2", // As specified in section 5.5 of OIDC4VP
                    "iat": 1667194901,
                    "exp": 1667194961,                  // To avoid replays, here it expires in 60 secs
                    "auth_request": "openid://?scope=...&amp;response_type=vp_token&amp;...",
                }

            Where the claims `iss` and `sub` MUST be the DID of the RP (in this case DOME onboarding) and MUST correspond exactly with the `client_id` parameter in the Authorization Request. The claim `auth_request` contains the Authentication Request as a string. The expiration time in claim `exp` avoids replays and can be very short because it is used by the Wallet just on reception of the Authentication Request. The expiration time should be enough for the user to review the Authorization Request, decide the credential(s) to send to the RP and instruct the Wallet to send the Authorization Reply to the RP.


        <section>Verification of the Authorization Request


            Before sending the Authentication Response, the wallet should verify that the Authorization Request is correct. The most important verifications are described here:

            <x-diagram .plantuml>Starting the authentication phase
                box "Company" #WhiteSmoke
                    actor "User" as user
                    participant "Wallet" as mobile
                    participant "Laptop" as browser
                end box
                box "Relying Party" #WhiteSmoke
                    participant "Portal" as portal
                    participant "VC Verifier" as verifier
                end box


                verifier -> mobile --++: **(9)** Reply with Authorization Request

                mobile -> mobile: **(10)** Verification of signature of Authorization Request
                # -(10) Verification of the signature. As mentioned in the previous section, the Authorization Request is received as a JWT signed by the DOME onboarding service, using the eIDAS certificate for seals that corresponds to the legal person operating the service. This allows the wallet to verify that the signature corresponds to a real-world entity.

                mobile -> mobile: **(11)** Verification of the identity of the Relying Party
                # -(11) Verification that the DID in the `client_id` field of the Authorization Request corresponds to the entity that signed the Authorization Request. This is easy in our case because we use the `did:elsi` method.

                mobile -> mobile: **(12)** Verification of the trusted nature of the RP
                # -(12) Verification that the entity identified in the `client_id` field of the Authorization Request is a trusted entity belonging to the ecosystem, by resolving the DID in the `client_id` field.

                    The actual mechanism may vary depending on the DID method used and the ecosystem where the client wants to onboard.
                    
                    If the Relying Party is a well known entity (like the DOME onboarding service in the case of DOME), it is easy to verify that the DID corresponds to the Relying Party.

                    In most other cases, for example when the Relying Party is a participant in the ecosystem, we assume that the ecosystem provides a Trusted Participants Registry with an API compatible with the EBSI Trusted Issuers Registry, and that the participants registry is managed in a trusted way by the onboarding service (meaning that the Wallet user trusts on the onboarding service, in the same way as all other participants).
                    
                    In this case, to check if the DID is a participant on the ecosystem, the wallet sends a `GET /api/did/v1/identifiers/{did-to-verify}` request to the endpoint of one of several trusted servers implementing the functionality to query the Trusted Participant Registry, where `{did-to-verify}` is the actual DID the Wallet wants to check (in our example it would be `did:elsi:VATFR-99999999`, corresponding to the RP) . The API returns a JSON document as a DID Document. The DID Document (as per W3C) contains relevant information about the entity owner of the DID. It contains its Public Key, used to verify the digital signature of the entity. It also contains the status of the entity in the ecosystem. It is extensible and can contain any public information which may be relevant for the use case. The API must be operated by a trusted entity for the Wallet user. There may be as many servers implementing the API as needed and operated by different entities. At least one of those trusted entities has to be configured in the Wallet of the user, to facilitate the use of the wallet.

        <section>Creating and sending the Authorization Response 

            Once the Authorization Request has been validated, the Wallet creates an Authorization Response to be posted in the `redirect_uri` specified by teh RP in the Authorization Request. For completeness, we describe in the following figure the complete process from reception of Authorization Request until sending the Authorization Response.

            <x-diagram .plantuml>Starting the authentication phase
                box "Company" #WhiteSmoke
                    actor "User" as user
                    participant "Wallet" as mobile
                    participant "Laptop" as browser
                end box
                box "Relying Party" #WhiteSmoke
                    participant "Portal" as portal
                    participant "VC Verifier" as verifier
                end box

                verifier -> mobile --++: **(9)** Reply with Authorization Request

                mobile -> mobile: **(10)** Verification of signature of Authorization Request

                mobile -> mobile: **(11)** Verification of the identity of the Relying Party

                mobile -> mobile: **(12)** Verification of the trusted nature of the RP

                mobile -> mobile: **(13)** Create Authorization Response
                # -(13) The wallet creates an Authorization Response to be posted in the `redirect_uri` specified by GoodAir in the Authorization Request that was sent to the wallet. The contents of the Authorization Response are described below.

                    The response is constructed as defined in section 6.1 of [[OpenID.VP]]. In particular, because the Authorization Request included only `vp_token` as the `response_type`, the VP Token is provided directly in the Authorization Response and a separate `id_token` is not needed.

                    The contents of the Authorization Response in our specific use case are:

                    <x-code .ini>
                        presentation_submission=[see definition below]
                        &vp_token=[see definition below]

                    The content of the `presentation_submission` parameter in the above Authorization Response is:

                    <x-code .json>
                        {
                            "definition_id": "OnboardingPresentationDefinition",
                            "id": "OnboardingPresentationSubmission",
                            "descriptor_map": [
                            {
                                "id": "id_credential",
                                "path": "$",
                                "format": "ldp_vp",
                                "path_nested": {
                                    "format": "ldp_vc",
                                    "path": "$.verifiableCredential[0]"
                                }
                            }
                            ]
                        }

                    Which complies with [[DIF.PresentationExchange]] and refers to the Verifiable Presentation in the `vp_token` parameter provided in the same response. In our example, the Verifiable Presentation includes the LEARCredential that was described in the previous sections.

                mobile -> verifier ++: **(14)** POST /api/siop/authorization_response
                # -(14) The wallet sends the Authorization Response to the endpoint received in the `redirect_uri` parameter of the Authorization Request, sending an HTTP `POST` request using the encoding `application/x-www-form-urlencoded`.

                    <x-code .http>
                        POST /api/siop/authorization_response HTTP/1.1
                        Host: verifier.dome-onboarding.org
                        Content-Type: application/x-www-form-urlencoded

                        presentation_submission=[see definition below]
                        &vp_token=[see definition below]


        <section>Authenticating the user with the LEARCredential

            We should remember that inside the LEARCredential the `credentialSubject` object has an `id` field with value `did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK` which is the DID of the user. It was generated during the creation of the LEARCredential, and the Relying Party should trust that the credential was generated in the proper way binding cryptographically the DID with the LEARCredential, as described in a previous section. It is the same trust that should be put in the generation of any other signed document, like a contract or invoice.

            The process of verifying the Authorization Response and authenticating the user with the LEARCredential is the following:

            <x-diagram .plantuml>Starting the authentication phase
                box "Company" #WhiteSmoke
                    actor "User" as user
                    participant "Wallet" as mobile
                    participant "Laptop" as browser
                end box
                box "Relying Party" #WhiteSmoke
                    participant "Portal" as portal
                    participant "VC Verifier" as verifier
                end box

                mobile -> verifier ++: (14) POST /api/siop/authorization_response

                verifier -> verifier: (15 and 16) Verify signature\nand issuer of\nLEARCredential
                # -(15 and 16) The Verifier receives the Authorization Request and has to perform verifications, the standard ones being defined in [[DIF.PresentationExchange]]. In order to verify that the Verifiable Credential has been issued by a trusted entity, the Relying Party has to verify:

                    <ol>
                        - That the DID of the entity which is the issuer of the VC is a trusted entity.
                        - That the VC was signed by that participant.

                    Both verifications can be done by performing DID resolution, checking that the resulting DID Document contains the public key corresponding to the one specified in the Verifiable Credential, and by verifying the digital signature of the credential against that public key.

                    In our case the LEARCredential was issued using the `did:elsi` method, so resolution is very simple and is specified in [[DID-ELSI]].

                verifier -> verifier: (17) Verify sender of the\nAuthorization Response
                # -(17) After verifying the credential, the Relying Party can also verify that the Verifiable Presentation including the Verifiable Credential is sent by the user and not by a malicious agent. To do so, it uses the public key associated to the `did:key` identifier `id` field inside the `credentialSubject` structure. That public key is cryptographically bound to the customer DID during the onboarding process that GoodAir performed with its employee.

                verifier -> verifier: (18) Generate Access Token
                # -(18) The Verifier creates an Access Token for the user so it can be used later for access services provided by the Relying Party (in the case of onboarding, those services would be the ones related to the onboarding process implemented by the Onboarding portal). The Access Token is generated in JWT format and signed by the VC Verifier. The access token is intended for use as bearer token over HTTP [[RFC2616]] using Transport Layer Security (TLS) [[RFC5246]] to access protected resources, and it should use the JWT Profile profile described in [[RFC9068]].

                    For our use case, the payload of the JWT access token looks like:

                    <x-code .json>
                        {
                            "iss": "did:elsi:VATFR-99999999",
                            "sub": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
                            "aud":   "https://dome-marketplace.eu/onboarding",
                            "exp": 1639528912,
                            "iat": 1618354090,
                            "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
                            "client_id": "did:elsi:VATFR-99999999",
                            "scope": "vp_token",
                            "verifiableCredential": ["the VC that was received inside the Verifiable Presentation"]
                        }

                    Where, according to [[RFC9068]]:

                    <ul>
                        - `iss` and `client_id` have the same value because the access token has been generated by the Verifier component of the DOME onboarding service, acting as the DOME legal person.

                        - `sub` identifies the user (employee of GoodAir acting as LEAR of the company) using the DID inside the Verifiable Credential received

                        - `aud` identifies the RS (Resource Server) component in Packet Delivery. In this case we assume that it is internal and does not have a DID assigned, so we use the URI of the component.

                        - `kid` in the header identifies the key that is used to sign the JWT and which must be configured up-front and known by the RS (Resource Server.

                        - `scope` has the same value as the equivalent `scope` parameter in the initial Authorization Request.

                        - `verifiableCredential` contains the Verifiable Credential that was received, specifically the value of the first element of the field `verifiableCredential` of the Verifiable Presentation.

                verifier -> mobile: (19) HTTP 200 with <access token>
                # -(19) The Verifier sends a successful response to the POST request from the wallet. The wallet receives the response to the POST indicating the success or failure of the process. The Verifier continues processing because the web portal of Packet Delivery has to be refreshed with the services that this specific user can access, based on the information received in the Verifiable Credential and the access control policies implemented by the DOME portal.

                verifier -> portal --++: (20) Notify with\n<access token> and <state>
                # -(20) The Verifier notifies the DOME portal to refresh the login page so it can present the services to the user. The notification includes the following:

                    <ul>
                        - The `state` nonce that was generated by the portal when it generated the QR code. The portal uses the `state` nonce to know what login session is being notified.

                        - The access token generated before.

                    The notification is a simple POST request with both parameters in the body:

                    <x-code .http>
                        POST /api/notify HTTP/1.1
                        Host: dome-marketplace.eu
                        Content-Type: application/x-www-form-urlencoded

                        access_token=[the access token]
                        &state=af0ifjsldkj

                    The portal component replies immediately and continues processing.

                portal -> browser --: (21) Refresh screen\nwith services and include\n<access token>
                # -(21) The portal of the Relying Party refreshes the screen and displays the services available to users, sending the Access Token to the browser of the user. The Access Token will be sent back by the browser to the portal whenever the user tries to access a protected resource of the portal, and so access control can be performed using the data inside the token, in the same way as with any other access token in other authentication mechanisms.
                


    <section #accesscontrol>Access control with Verifiable Credentials

        <section>Overview

            This section assumes that authentication has already been performed and that the Relying Party receives a request to a protected resource, with a proper access token inside the request. If the request does not come with an access token, the request is rejected immediately (or the user is redirected to the Authentication service of the Relying Party, depending on the use case).

            The Access Control mechanism described here is the same independently of whether the request comes from a user or a machine, so the M2M use case is supported without any modification. In the following description we will use the term <b>user</b> interchangeably for both the user as a natural person or the user as a machine.

            However, the assumption is that all machines have an identity (they are assigned an identifier), and that they are acting `on behalf of` a legally valid identity in the sense of eIDAS2. In other words, we require that the identities of users and machines can be cryptographically bound to the real-world identity of either a natural person or a legal person in a way that provides legal certainty to the Relying Party regarding the chain of responsibility.

            If the user is a natural person using the portal of the Relying Party, the request to the protected resource will come from the browser that the user employs to navigate the portal, and the access token will be included automatically by the browser in every request that is sent to the Relying Party, for example when the user clicks a button or fills a form.

            If the user is a server or device, it is assumed that it has obtained an access token previously as the result of an authentication process described above. The server or device is responsible for including the access token in every request that is sent to the Relying Party to access a protected resource.

            If the portal of the Relying Party is an onboarding process (eg., the portal of the DOME Onboarding service), the protected resource could be the onboarding service itself, or a service to upload additional information for a partially completed onboarding process.

            If the portal is a Marketplace and the organisation using the portal wants to offer products in it, these services could be to register the organisation as a <i>Seller</i>, or to create a Product specification and offering.
            
            If the portal is the Marketplace and the organisation wants to contract products in it, these services could be to register the organisation as a <i>Customer</i>, or to launch a procurement order of a product.

            The same mechanism can be used by any participant in the ecosystem, if they want to use an advanced IAM mechanism which is aligned with the EU strategy on digital identity based on Verifiable Credential and eIDAS2.

            For the explanation we will use the following figure which is based on [[[NIST-AUTH]]] which describes a reference architecture with necessary functional components to achieve enforcement the authorization policies. The authorization process depends on four layers of functionality: <b>Enforcement</b>, <b>Decision</b>, <b>Access Control Data</b>, and <b>Administration</b>.

            <figure #authn-reference>
                <img src="images/login_in_DOME/authn_architecture_authorization.drawio.png" alt="" />

                <figcaption>High level Authentication logical architecture


        <section>Determine the Authorization Policies which apply to the request 

            Every request to a protected resource is intercepted by the PEP (Policy Enforcement Point), and to know if the request should be authorised or not, the PEP asks to the PDP (Policy Decision Point) for a decision. The PDP needs to know what are the policy rules that should be applied to the request, and it uses the PRP (Policy Retrieval Point) to retrieve those policies.

            <x-diagram .plantuml>Determine the Authorization Policies
                box "Company" #WhiteSmoke
                    participant "User" as user
                end box
                box "Relying Party" #WhiteSmoke
                    participant "PEP" as pep
                    participant "PDP" as pdp
                    participant "PRP" as prp
                    participant "PIP" as pip
                    participant "Resource" as resource
                end box
                participant "Trust Framework" as trust

                user -> pep --++: **(1)** Access protected resource
                # -(1) The user (natural person or machine) sends a request to access a protected resource, and the PEP (Policy Enforcement Point) component intercepts the call. The PEP is normally implemented as a reverse proxy or API gateway, so all calls to protected resources entering the organisation are intercepted and forwarded if they are accepted.

                pep -> pdp --++: **(2)** Request a decision
                # -(2) If the request is not authenticated it is rejected with an error. Depending on the use case, the error returned can contain additional information that enables the user agent to be redirected to perform authentication.
                
                    After inspecting the request, the PEP requests a decision from the PDP passing a series of attributes. In general, the request from the PEP to the PDP consists of <b>subject</b> attributes (typically for the user who issued the request), <b>resource</b> attributes (the resource for which access is sought), <b>action</b> attributes (the operations to be performed on the resource), and <b>environment</b> attributes.

                    Some of the above attributes are obtained by the PEP from the original request received from the user. For example, the HTTP verb (GET, POST, PUT, PATCH, DELETE) and the URL and possibly the body of the request provide action attributes. Specifically, in the case of an NGSI-LD request those attributes are formally specified in the NGSI-LD standard.

                    The subject attributes most relevant for access control are located in the access token received with the request. In particular, the access token includes the Verifiable Credentials that were employed for authentication, and the claims in those credentials can be used to evaluate access control policies. This includes (but is not limited to) the roles object that may be included in the VerifiableID credential used for authentication.

                    An example access token would be:

                    <x-code .json>
                        {
                            "token_type": "Bearer",
                            "expires_in": 3600,
                            "access_token": "ewogICJhbGciOiAiR...ERBIgogIH0KfQ"
                        }

                    Decoding the `access_token` field we could see a Verifiable Presentation including the LEARCredential that the user presented when authenticating:

                    <x-code .json>
                        {
                            "@context": [
                                "https://www.w3.org/2018/credentials/v1",
                                "https://dome-marketplace.eu//2022/credentials/learcredential/v1"
                            ],
                            "id": "urn:did:elsi:25159389-8dd17b796ac0",
                            "type": ["VerifiableCredential", "LEARCredential"],
                            "issuer": {
                                "id": "did:elsi:VATES-12345678"
                            },
                            "issuanceDate": "2022-03-22T14:00:00Z",
                            "validFrom": "2022-03-22T14:00:00Z",
                            "expirationDate": "2023-03-22T14:00:00Z",
                            "credentialSubject": {
                                "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
                                "title": "Mr.",
                                "first_name": "John",
                                "last_name": "Doe",
                                "gender": "M",
                                "postal_address": "",
                                "email": "johndoe@goodair.com",
                                "telephone": "",
                                "fax": "",
                                "mobile_phone": "+34787426623",
                                "legalRepresentative": {
                                    "cn": "56565656V Jesus Ruiz",
                                    "serialNumber": "56565656V",
                                    "organizationIdentifier": "VATES-12345678",
                                    "o": "GoodAir",
                                    "c": "ES"
                                },
                                "rolesAndDuties": [
                                    {
                                        "type": "LEARCredential",
                                        "id": "https://dome-marketplace.eu//lear/v1/6484994n4r9e990494"
                                    }
                                ]
                            }
                        }


                    Environmental attributes, which depend on the availability of system sensors that can detect and report values, are somewhat different from subject and resource attributes, which are administratively created. Environmental attributes are not properties of the subject or resources, but are measurable characteristics that pertain to the operational or situational context in which access requests occur. These environmental characteristics are subject and resource independent, and may include the current time, day of the week, or threat level.

                    The PDP computes decisions to permit or deny subject requests to perform actions on resources. In computing a decision, the PDP queries policies stored in a PRP (Policy Retrieval Point).
                    
                    If the attributes of the request are not sufficient for rule and policy evaluation, the PDP may need to search the PIP for additional attributes. The PIP is shown as one logical store, but in fact may comprise multiple physical stores of different types.
                    
                    In addition to the PIP, the PDP uses one or more Trusted Issuers Lists (to check if the issuer of the credential is included in them as a trusted issuer of that type of credential), and also the Authorization Registry (AR), which can check for finer granularity authorisation records which may be very dynamic in nature (e.g. if some resource usage by employees and machines owned by the issuer have exceeded some quota this month).

                    The actual Trusted Issuers Lists that the PDP needs to check is determined by the policy rules retrieved from the PRP. Those policy rules also determine the additional queries performed to the PIP data stores.
                        
                    The set of information and data stored in the PIP and PRP comprise the access control data and collectively define the current authorization state, which the PDP will use to compute its decision.


                pdp -> prp --++: **(3)** Query policies
                # -(3) The PDP asks the PRP for the policy rules applicable to this request. The policy rules may be specified using different policy languages, like ODRL, XACML or Rego. It is very difficult to make the interface between the PDP and the PRP completely transparent and independent from the concrete policy language used in an implementation. However, The PDP can be modularised in order to minimise the dependency and reduce the cost of migration to other policy language in the future.

                prp -> pdp --++: **(4)** Reply with policies
                # -(4) The PDP receives the policy rules to apply for the current request.

        <section>Determine which Trusted Issuer Lists should be queried

            After retrieving the policies from the PRP, the PDP determines what are the attributes needed by the policy rules to perform its evaluation. Some of those attributes can be determined from the request received (e.g., claims inside the Verifiable Credential(s) in the access token). But in general, the policy rules require additional attributes that have to be retrieved from other sources.

            The two logical sources of those attributes are the PIP and the Trusted Issuers Lists in the Trust Anchor Framework.

            The concept of the PIP is the same as in the standard XACML logical architecture, essentially enabling the PDP to retrieve environmental attributes required for policy evaluation.

            In our approach using Verifiable Credentials for authentication and authorization, we use a Trust Framework to determine if the credentials received in the request are issued by authorised issuers of those credentials.

            The PDP does not have hardcoded the actual Trusted Lists to query, but they are determined dynamically from the policies retrieved from the PRP. In simple use cases there may be one or two lists to query which are the same for all requests. But the mechanism described here can cater for very complex scenarios where the lists may be different depending on the requests and also from the dynamic environmental information retrieved from the PIP.

            <x-diagram .plantuml>Determine Trusted Issuer Lists to query
                box "Company" #WhiteSmoke
                    participant "User" as user
                end box
                box "Relying Party" #WhiteSmoke
                    participant "PEP" as pep
                    participant "PDP" as pdp
                    participant "PRP" as prp
                    participant "PIP" as pip
                    participant "Resource" as resource
                end box
                participant "Trust Framework" as trust


                prp -> pdp --++: **(4)** Reply with policies
                # -(4) The PDP receives the policy rules to apply for the current request.

                pdp -> pdp: **(5)** Initial evaluation of the policies
                # -(5) The PDP performs an initial evaluation of the policy rules and if the attributes of the request are not sufficient for rule and policy evaluation, it determines the PIP stores to query, and also the set of Trusted Issuers Lists to query. The concrete Trusted Lists to query are dynamic and depend on the specific policies associated to the request.

                pdp -> pip --++: **(6)** Query additional attributes
                pip -> pdp --++: Reply with attributes
                # -(6) Based on the policies and the attributes of the request, the PDP queries the PIP for additional attributes needed for the policy evaluation.

                    Now that the PDP has the policy rules to apply and the attributes from the request and the ones retrieved from the PIP, the PDP can determine the actual Trusted Lists that have to be queried in order to be able to evaluate the policies.


        <section>Query the Trusted Issuer Lists

            The authorization mechanism uses the Trust Framework to query different Trusted Lists that are needed to evaluate the policy rules applicable to the request and compute a decision.

            The Trust Framework is composed of one or more Trusted Lists where each list is specialised in some specific domain of trust.

            For example, the Trust Framework contains Trusted Lists with the schema definitions used for the well-known types of Verifiable Credentials in the ecosystem. In this way, if the Verifiable Registry used for the Trust Framework is based on a Blockchain network (or several federated networks), the schemas can be published in a trusted and resilient manner reducing the risk of malicious tampering and keeping a record of the history of modifications.

            But the most interesting Trusted Lists in the Trust Framework are the Trusted Issuers Lists, which provide the mechanism to efficiently and securely verify that the issuer of a given credential is a Trusted Issuer of that type of credentials.

            It has to be noticed that even though most Trusted Issuer Lists are global (used by all participants in the ecosystem) and have essentially public information, there may be some specialised lists that are private to one or more organisations and specialised in some specific requirement.

            In this way, there may be some lists that are specific to the products that one organisation provides to other participants in the ecosystem. For example, there may be a Trusted Issuer List private to one organisation which is updated with the identity of a participant when that participant acquires access to some product provided by that organisation.

            For example, this "product-specific" Trusted Issuer List is queried when performing authorization if the related policy rules specify that the issuer of the Verifiable Credential received in the request should have acquired the product that the request is trying to access.

            However, as mentioned before, the set of "internal" and "external" Trusted Lists to query is not hardcoded but it depends on the specific policy rules that should be applied to the request when computing the decision to grant access or not.

            In this way, the system provides a great deal of flexibility on how access control is performed.

            For simplicity, the diagram below shows the query of the Trusted Issuer Lists as a single interaction to a single box, but the actual interactions can be very complex if required. In addition, the diagram does not specify whether the list is "private" or "global".


            <x-diagram .plantuml>Query the Trusted Issuer Lists
                box "Company" #WhiteSmoke
                    participant "User" as user
                end box
                box "Relying Party" #WhiteSmoke
                    participant "PEP" as pep
                    participant "PDP" as pdp
                    participant "PRP" as prp
                    participant "PIP" as pip
                    participant "Resource" as resource
                end box
                participant "Trust Framework" as trust


                pdp -> pip --++: **(6)** Query additional attributes
                pip -> pdp --++: Reply with attributes
                # -(6) Based on the policies and the attributes of the request, the PDP queries the PIP for additional attributes needed for the policy evaluation.

                pdp -> trust --++: **(7)** Query the Trusted Issuer List(s)
                trust -> pdp --++: Reply with results
                # -(7) Based on the policies and the attributes of the request, the PDP queries one or more Trusted Issuer Lists to check that the credentials received comply with the requirements specified in the policies.


        <section>Compute the decision and allow (or not) access

            Once the PDP has all the attributes required for policy evaluation, it computes a decision and returns that decision to the PEP which will enforce it.        

            <x-diagram .plantuml>Compute the decision
                box "Company" #WhiteSmoke
                    participant "User" as user
                end box
                box "Relying Party" #WhiteSmoke
                    participant "PEP" as pep
                    participant "PDP" as pdp
                    participant "PRP" as prp
                    participant "PIP" as pip
                    participant "Resource" as resource
                end box
                participant "Trust Framework" as trust

                trust -> pdp --++: Reply with results

                pdp -> pdp: **(8)** Final evaluation of the policies
                # -(8) The PDP performs a final evaluation of the policy rules, taking into consideration the attributes received from the PEP, the attributes received from the PIP, and the Trusted Issuers Lists queried. After the evaluation the PDP computes a decision, either to accept or to reject the request.

                pdp -> pep --++: **(9)** Return decision
                # -(9) The PDP returns the decision to the PEP, which will enforce it.

                pep -> resource --++: **(10)** Perform operation
                # -(10) If the decision from the PDP is to reject the request, the PEP returns an error to the user. Otherwise, it forwards the original request to the Resource for execution.

                resource -> pep --++: **(11)** Return result
                # -(11) The resource executes the request and returns the result.

                pep -> user --++: **(12)** Return result
                # -(12) The PEP returns the result to the user.


        <section>Summary of the authorization process

            The following diagram combines all the steps in a single one to provide an overall view of the authorization process.

            <x-diagram .plantuml>Summary of the Authorization process
                box "Company" #WhiteSmoke
                    participant "User" as user
                end box
                box "Relying Party" #WhiteSmoke
                    participant "PEP" as pep
                    participant "PDP" as pdp
                    participant "PRP" as prp
                    participant "PIP" as pip
                    participant "Resource" as resource
                end box
                participant "Trust Framework" as trust

                user -> pep --++: **(1)** Access protected resource

                pep -> pdp --++: **(2)** Request a decision

                pdp -> prp --++: **(3)** Query policies

                prp -> pdp --++: **(4)** Reply with policies

                pdp -> pdp: **(5)** Initial evaluation of the policies

                pdp -> pip --++: **(6)** Query additional attributes
                pip -> pdp --++: Reply with attributes

                pdp -> trust --++: **(7)** Query the Trusted Issuer List(s)
                trust -> pdp --++: Reply with results

                pdp -> pdp: **(8)** Final evaluation of the policies

                pdp -> pep --++: **(9)** Return decision

                pep -> resource --++: **(10)** Perform operation

                resource -> pep --++: **(11)** Return result

                pep -> user --++: **(12)** Return result


<section .appendix #participants>Example scenario: Participants in the ecosystem

    Here we introduce the actors of the reference use case we are going to use. The main actors are marked in yellow in the following diagram.
    
    RealTruth is a Trust Service Provider operating under the eIDAS Trust Framework, which issues a certificate for seals to the company GoodAir. GoodAir is a business that provides some services using an Air Quality application operated by GoodAir.

    RealTruth also provides a certificate for signatures to the COO of the GoodAir company, so the COO can use the certificate to sign documents on behalf of GoodAir (like contracts, invoices, financial reports, ...) in a way that is compliant with eIDAS.

    The COO of GoodAir will issue a verifiable credential of type LEARCredential to an employee of GoodAir, signing the credential with his certificate for signatures.

    <x-diagram .d2>
        classes: {
            participant: {
                style: {
                    fill: "aqua"
                }
            }
            multiple: {
                style: {
                    multiple: true
                }
            }
        }

        eIDAS: eIDAS Trust Framework {
            icon: /images/eu_trust_mark.jpg
        }
        eIDAS.style.fill: transparent

        DE_TL: Germany Trusted List

        RealTruth: RealTruth TSP {

            Seal: Certificate\nfor seal
            Seal.shape: oval

            Sign: Certificate\nfor signature
            Sign.shape: oval

        }
        RealTruth.class: participant

        OtherG: Other TSPs {
            S3.shape: circle
            S3: Cert\nfor Sign
            S4.shape: circle
            S4: Cert\nfor Seal
        }
        OtherG.class: multiple

        DE_TL -> RealTruth
        DE_TL -> OtherG

        Other_Countries: Other Trusted Lists
        Other_Countries.style.fill: transparent
        Other_Countries.class: multiple

        TSP1 {
            S1.shape: circle
            S1: Cert\nfor Sign
            S2.shape: circle
            S2: Cert\nfor Seal
        }

        TSPn {
            S3.shape: circle
            S3: Cert\nfor Sign
            S4.shape: circle
            S4: Cert\nfor Seal
        }

        GoodAir {
            COO
            Employee
        }
        GoodAir.class: participant

        eIDAS -> DE_TL
        eIDAS -> Other_Countries


        RealTruth.Seal -> GoodAir: Issue Cert for Seals {
            style: {
                font-size: 30
            }
        }
        RealTruth.Sign -> GoodAir.COO: Issue Cert for Signatures {
            style: {
                font-size: 30            }
        }

        Other_Countries -> TSP1
        Other_Countries -> TSPn

        GoodAir.COO -> GoodAir.Employee: LEARCredential {
            style: {
                font-size: 30
            }
        }

    <section #participant>GoodAir: the company that wants to perform the process

        The new participant is a business providing an Air Quality Monitoring application as a service. The business is called GoodAir and it operates the application, which receives data from a set of sensors that may or may not be the property of GoodAir. The sensors must have received a certification to be able to operate and send data to the GoodAir application.

        The company is registered in the tax agency and business registry of Spain with VAT number <b>VATES-12345678</b>.

    <section>COO (Chief Operating Officer) of GoodAir

        The GoodAir company is small and the only person that can sign contracts on behalf of the company is the COO (Chief Operating Officer). The COO is a legal representative of the company and she is registered as so in the business registry of Spain.

        The COO has a certificate for electronic signatures issued by one of the TSPs in Spain enabling the COO to perform electronic qualified signatures as legal representative of GoodAir, instead of doing them manually.

        The X.509 certificate of the COO has the following contents in the `Subject` field (the example below is derived from a real certificate but with the identifiers modified to be an example):

        <x-code .ini>
            cn = 56565656V Jesus Ruiz
            serialNumber = 56565656V
            givenName = Jesus
            sn = Ruiz
            2.5.4.97 = VATES-12345678
            o = GoodAir
            c = ES
            2.5.4.13 = Notary:Juan Lopez/Protocol Num:7172/Date:07-06-2021

        The above set of fields bind the legal identity of the COO with the identity of the business:

        <ul>
            - `serialNumber` is the unique number recognized by the Spanish Government for spanish citizens (called NIF).
            - `2.5.4.97` is the <a href="https://oidref.com/2.5.4.97">official OID for `organizationIdentifier`</a>. The contents of this field in the example certificate is the unique identifier for the legal person GoodAir.

        Before issuing a certificate like the above, the TSP has to perform some validations to ensure that in the official source of truth (the business registry of Spain in this case) there is already registered information that states that the COO has indeed powers to act on behalf of GoodAir as a legal representative.

    <section>RealTruth: a Trust Service Provider

        RealTruth is an EU TSP, which appears in the TL (Trusted List) maintained by the <a href="https://tl.bundesnetzagentur.de/TL-DE.XML">German Government</a>.
        
        RealTruth is a TSP based in Germany but operates in most of the countries of the EU and so being able to provide Trust Services across many countries, including Spain.

        As all TSPs in the TLs of the Member States, its entry in the TL includes one or more "Services" entries which describe the Trust Services provided by the TSP.

        A TSP can have one Service issuing certificates for signatures, another service issuing certificates for seals, another service for timestamping, etc.

        The regulator approves or suspends each service from a TSP individually, and the services are the root anchor for a given trust environment.

        In our case, the entry for RealTruth in the TL includes a `\<TSPService\>` entry, and inside it the `\<ServiceDigitalIdentity\>` entry includes a DER-encoded certificate specifying the digital identity of the root anchor for that trust domain. The certificate for the Service has in the Subject field:

        <x-code .INI>
            2.5.4.97 = VATDE-170173453
            CN = DRV QC 11 MA CA 2017ca
            OU = QC 11 Mitarbeiter CA
            O = Deutsche Rentenversicherung Westfalen
            C = DE

        Which in the `organizationIdentifier` field (OID 2.5.4.97) specifies the unique organisation identifier assigned by the German regulatory authority to the TSP: VATDE-170173453.

        RealTruth provides `Legal Person Representative Certificates` which are qualified in accordance with Regulation (EU) No. 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market.

        The certification policies of RealTruth includes the following sentences:

        <blockquote>
            The Registration Authority must verify the following information in order to authenticate the identity of the organisation:

            <ul>
                - The data concerning the business name or corporate name of the organisation.
                - The data relating to the constitution and legal status of the subscriber.
                - <b>The data concerning the extent and validity of the powers of representation of the applicant.</b>
                - The data concerning the tax identification code of the organisation or equivalent code used in the country to whose legislation the subscriber is subject.

        The TSP (RealTruth in this case) performs the verifications against `Authentic Sources`.

        <blockquote>
            Authentic Sources are the public or private repositories or systems recognised or required by law containing attributes about a natural or legal persons.
            
            The Authentic Sources in scope of Annex VI of the [eIDAS2] legislative proposal are sources for attributes on address, age, gender, civil status, family composition, nationality, education and training qualifications titles and licences, professional qualifications titles and licences, public permits and licences, financial and company data.
            
            Authentic Sources in scope of Annex VI are required to provide interfaces to Qualified Electronic Attestation of Attributes  (QEAA) Providers to verify the authenticity of the above attributes, either directly or via designated intermediaries recognised at national level.
            
            Authentic Sources may also issue (Q)EAA-s themselves if they meet the requirements of the eIDAS Regulation. It is up to the Member States to define terms and conditions for the provisioning of these services, but according to the minimum technical specifications, standards, and procedures applicable to the verification procedures for qualified electronic attestations of attributes.

        In accordance to the policies, RealTruth made those validations when issuing the certificate to the COO, in such a way that the Relying Parties verifying the certificate can have a high level of trust in the assertion that the natural person identified in the certificate (with Spanish ID of 56565656V) is a legal representative of he GoodAir company (organizationIdentifier VATES-12345678).

    <section>John Doe: an administrative employee of GoodAir

        This is an employee of the central administration department of GoodAir, who is going to be formally nominated to manage a specific set of processes on behalf of GoodAir in the Data Space. In particular, this employee is going to be nominated as a LEAR (Legal Entity Appointed Representative).

        As its name implies, the LEAR has to be nominated by a <b>legal representative</b> of the GoodAir organisation with the necessary legal authority to commit the organisation for this type of decision. In our case, the COO of GoodAir will nominate John Doe as the LEAR of GoodAir, delegating to him the capabilities to perform some processes in the DOME portal and some other tasks in other organisations. That means that John Doe will not be empowered to perform cation snot explicitly specified in the credential.

        To perform the nomination, the COO of GoodAir (a legal representative of GoodAir) will issue a special credential to John Doe and will sign the credential with his certificate for signatures as legal representative of GoodAir. The details are described later in this document.

    <section>DOME: an instance of a Data Space for Smart Cities

        DOME is a Data Space where local governments can procure data and services from other entities that act as service providers. At the same time, the local governments can also act as data and service providers for other entities in the Data Space.

        The DOME Data Space has an portal service that allows external entities to perform some processes in an automated fashion by using Verifiable Credentials that have been issued by trusted entities. The complete Trust Framework used by DOME is composed from a series of Trust Frameworks, some managed internally using a governance model of DOME and some others managed externally but by trusted entities. At the root of the Trust Framework of DOME is the eIDAS Trust Framework and the pan-european recognized list of Trust Service Providers issuing the eIDAS compliant digital identities, in the form of certificates for signatures/seals.

        In order to participate in DOME, every legal person requires a certificate for seals or that one of its legal representatives has a certificate for signatures (or both). The DOME entity is registered in France with VAT number <b>VATFR-99999999</b>.



<section #request_scope>Request Scope

    According to section 5.3 of [[OpenID.VP]], wallets MAY support requesting presentation of credentials using OAuth 2.0 `scope` values. Such a scope value MUST be an alias for a well-defined presentation definition as it will be referred to in the `presentation_submission` response parameter.

    In this specification we define concrete scope values and the mapping between a certain scope value and the respective presentation definition, in particular the mapping between scope values and specific types of Verifiable Credentials used for access control in the use case described in this document. In a production implementation of a Data Space ecosystem, the Trust Framework has to define the mappings used in the ecosysyem and the mechanisms and governance model used to update those mappings.

    In this example we only need the mapping for the LEARCredential, where the scope `dome.credentials.presentation.LEARCredential` represents the following presentation definition:

    <x-code .json>
        {
            "id": "dome.credentials.presentation.LEARCredential",
            "input_descriptors": [
                {
                "id": "LEARCredentialDefinitionv1.01",
                "format": {
                    "ldp_vc": {
                        "proof_type": [
                            "RsaSignature2018"
                        ]
                    }
                },
                "constraints": {
                    "fields": [
                        {
                            "path": [
                                "$.type"
                            ],
                            "filter": {
                                "type": "string",
                                "pattern": "LEARCredential"
                            }
                        }
                    ]
                }
                }
            ]
        }


<section #glossary>Glossary

    As far as possible and in order to enhance consistency with the regulation, we use in this document the following definitions, which is essentially a subset of the definitions in Article 3 of the document [[eIDAS2.Regulation]] and in the original [[[eIDAS.Regulation]]].

    This is the reason why in some definitions below the description refers to an article or section that does not exist in this document. We have decided to keep the definitions like in the original, as we think it does not limit the understanding of the concept.

    <ul .plain>

        -(electronic identification): 
            means the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person;

        -(electronic identification means): 
            means a material and/or immaterial unit, including European Digital Identity Wallets or ID cards following Regulation 2019/1157, containing person identification data and which is used for authentication for an online or offline service:

        -(person identification data): 
            means a set of data, issued in accordance with national law, enabling the identity of a natural or legal person, or a natural person representing a legal person to be established;

        -(electronic identification scheme): 
            means a system for electronic identification under which electronic identification means, are issued to natural or legal persons or natural persons representing legal or natural persons;

        -(user): 
            means a natural or legal person, or a natural person representing a legal person using trust services, notified electronic identification means or European Digital Identity Wallets;

        -(authentication): 
            means an electronic process that enables the verification of the origin and integrity of data in electronic form;

        -(identification): 
            means an electronic process that establish an unequivocal relationship between a set of data and a natural or legal person;

        -(validation): 
            means the process of verifying that an electronic signature, an electronic seal, a European Digital Identity Wallet, an electronic identification mean, a relying party authorisation, person identification data, an electronic attestation of attributes or any electronic certificates for trust services is valid and has not been revoked;

        -(zero knowledge proof): 
            means cryptographic methods by which a relying party can validate that a given statement based on the electronic attestation of attributes held in a user's European Digital Identity Wallet is true, without conveying any data related to those electronic attestation of attributes to the relying party;

        -(relying party): 
            means a natural or legal person that relies upon an electronic identification means, including European Digital Identity Wallets, or a trust service, directly or through an intermediary, in order to provide services;

        -(public sector body): 
            means a state, regional or local authority, a body governed by public law or an association formed by one or several such authorities or one or several such bodies governed by public law, or  private entity mandated by at least one of those authorities, bodies or associations to provide public services, when acting under such a mandate;

        -(body governed by public law): 
            means a body defined in point (4) of Article 2(1) of Directive 2014/24/EU of the European Parliament and of the Council (1);

        -(signatory): 
            means a natural person who creates an electronic signature;

        -(electronic signature): 
            means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign;

        -(advanced electronic signature): 
            means an electronic signature which meets the requirements set out in Article 26;

        -(qualified electronic signature): 
            means an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures;

        -(electronic signature creation data): 
            means unique data which is used by the signatory to create an electronic signature;

        -(certificate for electronic signature): 
            means an electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person;

        -(qualified certificate for electronic signature): 
            means a certificate for electronic signatures, that is issued by a qualified trust service provider and meets the requirements laid down in Annex I;

        // (16) ‘trust service’ from eIDAS2
        -(trust service): 
            means an electronic service normally provided against payment which consists of:
            <ul>
                - (a) the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services, electronic attestation of attributes and certificates related to those services;

                - (b) the creation, verification and validation of certificates for website authentication;

                - (c) the preservation of electronic signatures, seals or certificates related to those services;

                - (d) the electronic archiving of electronic documents;

                - (e) the management of remote electronic signature and seal creation devices;

        // (17) ‘qualified trust service’ from eIDAS1
        -(qualified trust service): 
            means a trust service that meets the applicable requirements laid down in this Regulation;

        // (18) ‘conformity assessment body’ from eIDAS1
        -(conformity assessment body): 
            means a body defined in point 13 of Article 2 of Regulation (EC) No 765/2008, which is accredited in accordance with that Regulation as competent to carry out conformity assessment of a qualified trust service provider and the qualified trust services it provides;

        // (19) ‘trust service provider’ from eIDAS1
        -(trust service provider): 
            means a natural or a legal person who provides one or more trust services either as a qualified or as a non-qualified trust service provider;

        // (20) ‘qualified trust service provider’ from eIDAS1
        -(qualified trust service provider): 
            means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body;

        // (25) ‘electronic seal’ from eIDAS1
        -(electronic seal): 
            means data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity;

        // (26) ‘advanced electronic seal’ from eIDAS1
        -(advanced electronic seal): 
            means an electronic seal, which meets the requirements set out in Article 36;

        // (27) ‘qualified electronic seal’ from eIDAS1
        -(qualified electronic seal): 
            means an advanced electronic seal, which is created by a qualified electronic seal creation device, and that is based on a qualified certificate for electronic seal;

        // (28) ‘electronic seal creation data’ from eIDAS1
        -(electronic seal creation data): 
            means unique data, which is used by the creator of the electronic seal to create an electronic seal;

        // (29) ‘certificate for electronic seal’ from eIDAS2
        -(certificate for electronic seal): 
            means an electronic attestation or set of attestations that links electronic seal validation data to a legal person and confirms the name of that person;

        // (30) ‘qualified certificate for electronic seal’ from eIDAS1
        -(qualified certificate for electronic seal): 
            means a certificate for an electronic seal, that is issued by a qualified trust service provider and meets the requirements laid down in Annex III;

        // (31) ‘electronic seal creation device’ from eIDAS1
        -(electronic seal creation device): 
            means configured software or hardware used to create an electronic seal;

        // (32) ‘qualified electronic seal creation device’ from eIDAS1
        -(qualified electronic seal creation device): 
            means an electronic seal creation device that meets mutatis mutandis the requirements laid down in Annex II of [[eIDAS.Regulation]];

        // (33) ‘electronic time stamp’ from eIDAS1
        -(electronic time stamp): 
            means data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time;

        // (34) ‘qualified electronic time stamp’ from eIDAS1
        -(qualified electronic time stamp): 
            means an electronic time stamp which meets the requirements laid down in Article 42 of [[eIDAS.Regulation]];

        // (35) ‘electronic document’ from eIDAS1
        -(electronic document): 
            means any content stored in electronic form, in particular text or sound, visual or audiovisual recording;

        // (36) ‘electronic registered delivery service’ from eIDAS1
        -(electronic registered delivery service): 
            means a service that makes it possible to transmit data between third parties by electronic means and provides evidence relating to the handling of the transmitted data, including proof of sending and receiving the data, and that protects transmitted data against the risk of loss, theft, damage or any unauthorised alterations;

        // (37) ‘qualified electronic registered delivery service’ from eIDAS1
        -(qualified electronic registered delivery service): 
            means an electronic registered delivery service which meets the requirements laid down in Article 44;

        // (42) ‘European Digital Identity Wallet’ from eIDAS2
        -(European Digital Identity Wallet): 
            means an electronic identification means which securely stores, manages and validates identity data and electronic attestations of attributes, to provide them to relying parties and other users of European Digital Identity Wallets on request, and which enables the creation of qualified electronic signatures and seals;

        // (43) ‘attribute’ from eIDAS2
        -(attribute): 
            is a feature, characteristic or quality of a natural or legal person or of an entity;

        -(electronic attestation of attributes): 
            means an attestation in electronic form that allows the presentation and authentication of attributes;

        -(qualified electronic attestation of attributes): 
            means an electronic attestation of attributes, which is issued by a qualified trust service provider and meets the requirements laid down in Annex V;

        -(authentic source): 
            is a repository or system, held under the responsibility of a public sector body or private entity, that contains attributes about a natural or legal person and is considered to be the primary source of that information or recognised as authentic in Union or national law;

        -(electronic archiving): 
            means a service ensuring preservation of electronic data or documents in order to guarantee their integrity, the accuracy of their origin and legal features throughout the conservation period;

        -(qualified electronic archiving service): 
            means a service that meets the requirements laid down in Article 45g;

        -(EU Digital Identity Wallet Trust Mark): 
            means an indication in a simple, recognisable and clear manner that a Digital Identity Wallet has been issued in accordance with this Regulation;

        -(strong user authentication): 
            means an authentication based on the use of at least two authentication factors categorised as user knowledge , possession and inherence that are independent, in such a way that the breach of one does not compromise the reliability of the others, and is designed in such a way to protect the confidentiality of the authentication data;

        -(user account): 
            means a mechanism that allows a user to access public or private services on the terms and conditions established by the service provider;

        -(personal data): 
            means any information as defined in point 1 of Article 4 of Regulation (EU) 2016/679;

        -(identity matching): 
            means a process where person identification data or person identification means are matched with or linked to an existing account belonging to the same person;

        -(offline service): 
            means the capability of a user to electronically identify and authenticate with a third party with close proximity technologies irrespective of whether the device is connected to the internet or not in order to access a wide range of public and private services;



<section #references>