Hanah

1 Overview#

Reference: DSBA Technical Convergence v2.0 chapter 6

This section implements a scenario where data service providers offer services on a public platform, allowing service consumers to gain access to these services. Additionally, these consumers can delegate the access rights they obtain to their users/customers.

Use case of this section: The data service provider is a parcel delivery company that supports the creation and management of parcel delivery orders and provides services to view and modify specific attributes of the orders; the consumer is a retailer that provides a goods system to its customers, who can obtain access to the parcel delivery company's services through the data space marketplace and delegate that access to their customers.

In the reference use case, multiple participants are involved, each with its own infrastructure. Specifically, they include:

1. Data Space Marketplace: A public marketplace for creating service products and obtaining access rights.
2. Trust Anchor: Acts as the scheme administrator, holding information about each participant (including a globally unique identifier known as the Economic Operators Registration and Identification: EORI number) and allowing it to check the admission status of each participant.
3. Parcel Delivery Company: Provides services for retrieving and updating parcel delivery order data.
4. Happy Pets: A premium pet retailer. Additionally, there are two human roles involved: Happy Pets employees and Happy Pets customers.
5. No Cheaper: A retailer offering significant discounts. Additionally, there are two human roles involved: No Cheaper employees and No Cheaper customers.

The overall architecture is as follows:

• The parcel delivery company and the store system service providers each have their own identity providers (IdP) and authorization registries.
• The parcel delivery company hosts a portal that allows users to view and modify the attributes of parcel delivery orders.
• Order entities are stored in instances of a context broker.
• Read-and-write access to parcel delivery order entities is proxied by a policy enforcement point (PEP proxy) and controlled by a policy decision point (PDP), which will be detailed later for each participant.

2 Detailed Explanation of Each Component#

2.1 Parcel Delivery Company#

The corresponding architecture diagram is as follows:

Packet Delivery is a logistics company providing global parcel delivery services. It offers two types of parcel delivery services:

• Standard Parcel Delivery Service
  • Customers can specify the sender, delivery address, date and time for parcel pickup, and the recipient's name and address.
  • When the parcel delivery company receives a customer's parcel delivery order, it returns the target date for the planned delivery of the parcel.
  • Under defined terms and conditions (e.g., no customs violations, valid address, etc.), it commits to delivering parcels within 48 hours within the same country, while international shipping takes 5-6 days.
  • However, customers cannot adjust the specific delivery date (e.g., delay it to a more convenient date) or fine-tune the specific delivery time within the selected delivery date.
• Gold Parcel Delivery Service
  • Customers enjoy all the benefits of standard parcel delivery while also being able to adjust the specific delivery address, delivery date, and fine-tune the specific delivery time within the selected delivery date, provided that these adjustments are feasible (e.g., requests are made with sufficient advance notice and do not incur additional costs).

The parcel delivery company electronically provides services to various retailers, allowing them to publish parcel delivery orders, track order locations, and allow authorized customers to make requests to adjust addresses, dates, and planned delivery times through its parcel delivery information system (P.Info) via REST API.

2.1.1 DELIVERYORDER#

P.Info is implemented through an NGSI-LD interface provided by the context broker. DELIVERYORDER is an entity with the following attributes:

• issuer
• pickingAddress
• pickingDate
• pickingTime
• destinee
• deliveryAddress
• PDA (planned date of arrival)
• PTA (planned time of arrival)
• EDA (expected date of arrival)
• ETA (expected time of arrival)

Packet Delivery defines two roles for its P.Info system: P.Info.standard and P.Info.gold, and defines the operations that can be performed on the above attributes through the context broker service based on these roles.

To simplify the scenario description, we will focus on the three attributes of delivery address, planned date of arrival, and planned time of arrival, as we can assume that other attributes will be assigned values at the time of order creation, are always readable, but cannot be changed by users through the defined roles. For these three attributes, once the order is created, the following policies apply to the defined roles:
| Path | Verb | Verb |

Note that orders will be created using different paths (/ngsi-ld/v1/entities/) via POST. An additional role, P.Create, is defined for issuing such requests, which is only assigned to Happy Pets and No Cheaper.

The parcel delivery company offers two products for potential retailers and other types of companies:

• Basic Delivery: Allows companies obtaining the service to offer standard parcel delivery services to their customers.
• Premium Delivery: Allows companies obtaining the service to offer both standard and gold parcel delivery services to their customers.

It is important to note that Packet Delivery should not know the identity of any retailer application users. It only needs to be able to, upon receiving a request:

a) Identify that the request comes from a user associated with a retailer company that obtains its platform products.

b) Determine the role assigned to the user in the retailer company's P.Info application (i.e., P.Info.standard or P.Info.gold).

c) Check whether that role is one that the retailer company can assign, considering the products it has obtained on the platform.

After completing these steps, Packet Delivery only needs to check whether the user with that role can perform the requested operation.

An application created by No Cheaper, regardless of whether it assigned the P.Info.gold role to the user, cannot successfully change the value of the PTA attribute of an order, as the standard parcel delivery service it has obtained does not allow changes to these values (because No Cheaper is a budget company and does not have the authority to assign the P.Info.gold role).

2.2 Data Service Consumer: HappyPets Inc.#

HappyPets Inc. (referred to as HappyPets) is a company that sells pet supplies. It will obtain "Premium Delivery" services on the marketplace. This will enable it to offer standard and gold delivery services to customers through HappyPets' store application. Additionally, there may be certain employees within the company, such as supervisors and agents of the telephone help desk service provided by the company, who may use an internal application (HappyPetsBackOffice) to change the delivery address, PDA, and PTA of a given order.

When customers register on HappyPetsStore, they can be classified as "regular" customers or "premium" customers (who pay an annual fee). "Regular" customers will receive standard parcel delivery services, while "premium" customers will receive gold parcel delivery services. This means they are assigned the roles of P.Info.standard and P.Info.gold, respectively, in the HappyPetsStore application.

On the other hand, different employees are assigned different roles in the HappyPetsBackOffice application, so employees serving as supervisors in physical stores or agents working at the central help desk are also assigned the P.Info.gold role.

Happy Pets Employees:

• Obtain premium parcel delivery products on the platform.
  Happy Pets Customers:
• Register in the Happy Pets store system and are assigned the premium customer role
  • For simplicity, assume that a Happy Pets customer has already registered as a premium customer.
• Place orders in the store system, which essentially creates a parcel delivery order in the P.Info system
  • For simplicity, assume that an order has already been created for that customer in the P.Info system.
• Successfully change the PTA of the order through the Packet Delivery portal
  • We will describe the detailed process for executing this in section 4. Detailed Workflow.

2.3 Data Service Consumer: No Cheaper Ltd.#

No Cheaper is a company that sells various products at larger discounts. It will obtain the basic parcel delivery product from the Packet Delivery company on the platform.

No Cheaper Employees:

• Obtain basic parcel delivery products on the platform.
  No Cheaper Customers:
• Register in the No Cheaper store system and are assigned the regular customer role
  • For simplicity, assume that a No Cheaper customer has already registered as a regular customer.
• Place orders in the store system, which essentially creates a parcel delivery order in the P.Info system
  • For simplicity, assume that an order has already been created for that customer in the P.Info system.
• When attempting to change the PTA of the order through the Packet Delivery portal, they are denied.
• It can also be demonstrated that when No Cheaper employees assign premium customer roles to No Cheaper customers in their own identity provider system, that request will also be denied.

2.4 Data Marketplace Platform#

The marketplace is built on the FIWARE BAE (Business Application Ecosystem) component, which consists of a set of APIs provided by the FIWARE business framework and TMForum. It allows for the monetization of different types of assets throughout the service lifecycle, from offering creation to charging, accounting, and revenue settlement required for billing and payment.

The parameters for parcel delivery orders when creating offers, as well as the necessary steps executed during the acquisition and activation phases, are implemented by dedicated plugins installed in the Charging Backend component.

You can find the dedicated theme for Marketplace UI.

2.5 Trust Anchor Framework#

The system uses verifiable credentials (VC), and participants are identified through did. To effectively and decentralized verify participants' credentials and identities, a blockchain-based trust framework must be implemented to avoid central entity mediation in all authentication flows.

The trust framework consists of two parts:

• Trusted Organization List: A list of trusted organizations' identities stored on the blockchain, along with relevant information for each entity.
• Management Processes: Processes for adding, modifying, and deleting trusted entities, implementing specific governance models.

The design of the trust framework is largely decentralized, representing trust relationships in the real world. Here we describe a possible implementation of a blockchain-based trust framework.

Features:

• Decentralized Trust System: The identities of entities involved in the ecosystem are registered in a public directory on the blockchain, following a hierarchical scheme very similar to the DNS model on the internet.
• Self-managed Sub-entities: Once an entity is registered in the system, it can autonomously add other entities to be managed as sub-entities.
• Clear, Transparent, and Auditable: Any participant can obtain trustworthy information about the current trust structure of the ecosystem, as well as events that led to the system's current state. For example, which entity registered another entity, when it was completed, and what attributes the parent entity assigned to the sub-entity.
• Root Trust Entity: The system can be highly decentralized. However, there is a centralized element: the trust root at the top of the hierarchy should be a trusted entity (or entity alliance) responsible for guiding the system within the ecosystem. Depending on the specific governance framework of the ecosystem, this may be the sole mission of the root entity, which may include monitoring and oversight of the ecosystem. Generally, it should be a regulatory body, public administration, or a neutral organization that is fully trusted by all participants in the ecosystem.
• Hierarchical Structure: The trust framework supports multi-level structures to accommodate different governance needs.

The approach of a single blockchain network is shown in the figure below (this scheme can easily be extended to different blockchain networks, where we hope to establish trust between them so that entities in one network can interact with entities in another network in a trustworthy manner).

• Root: This entity is referred to as a Trusted Registration Authority (TRA) in EBSI and as a "Trust Anchor" in other contexts. We will use the term trust anchor in the description below. Its essential characteristic is that it is the most trusted entity/entity in the ecosystem. The root entity is responsible for registering the identities of other trusted entities.
  • For example, the Ministry of Education can register the identities of regional agencies responsible for managing universities in various regions of a country on the blockchain. As shown in domainA, domainN in the figure.
  • Once this registration is completed, each regional agency can continue to register the identities of their subordinate entities, such as universities, as shown in registerA1, etc.
  • Multi-level management. For example, a university may be large, with several autonomous organizational units that may be geographically distributed. It can create sub-identities and register them as sub-nodes on the blockchain, as shown in subregisterA2_1.

2.5.1 Registering Ecosystem Identities#

New Identity Registration:

• A new identity can only be registered by an already existing identity.
• The only exception is the trust anchor. It is the entity that deploys the smart contract to the blockchain, thus having special permissions. Upon deployment, the smart contract allows registering the identity and relevant information of the trust anchor.
  Domain Name Assignment:
• Each legitimate identity in the system is assigned a domain name, similar to the domain name system on the internet. When creating a new identity, it is assigned a name and automatically set as a subdomain based on the parent identity.
• Exception: The root domain name (i.e., trust anchor) has no name and is the highest-level identity in the system.
  • For example, the entity issuerA1 in the figure has a full domain name: domainA.registerA2.subregisterA2_1.issuerA1. This full domain name uniquely identifies the entity, ensuring that there are no duplicates or confusions in the system. In this example, "domainA" is a top-level domain name that should have already been added to the system by the trust anchor entity.
• Registration Restrictions: An entity can only be registered by its parent entity, and no other entities in the trust framework, including the parent entity's parent entity, can register it. Organizations need to be responsible for all their sub-entities, which are represented as sub-nodes in the trust framework.

External third parties with read access to the blockchain can see the entire trust structure, including immutable historical events since the system's inception. This transparency is crucial for ensuring the system's credibility and security.

2.5.2 Verifying Identity: Universal Resolver#

Functionality of the Universal Resolver:

• The Universal Resolver is a public API that can be used by any participant to verify identities. It resolves decentralized identifiers (DID) and supports multiple DID methods.
• By resolving the DID, it ensures that participants can verify the authenticity of identities.
  DID Resolution Process:
• DID resolution is a key step in obtaining the DID document, involving four main operations: "read," "create," "update," and "deactivate."
• After resolution, DID URL dereferencing can also be performed, which means obtaining the resource represented by the DID URL.
  Application in the SIOP (Self-Issued OpenID Provider) Process:
• In the SIOP process, DID resolution is used to obtain the public key of the entity and verify its signature to ensure the security of information exchange. The public key in the DID document is obtained through DID resolution.
  PS: To avoid centralization risks, it is recommended to run the Universal Resolver on multiple nodes or rely on trusted third parties.

3 Verifiable Credentials in the Ecosystem#

In this section, we will describe the different types of credentials required for the functionality of the ecosystem.

3.1 Packet Delivery Employees#

Packet Delivery issues credentials to some of its employees so that they can access the Marketplace, create products, or purchase products.
This credential is used by Packet Delivery employees to prove to third parties that they are authorized to use certain services provided by third parties on behalf of the employing company (in this case, Packet Delivery). In other words, the credential serves as a mechanism for Packet Delivery to delegate its access control rights to one or more employees.
Basic features of the credential:

• Since its issuance, no one has tampered with the content of the credential. Because the credential is digitally signed by the issuer, Packet Delivery.
• It proves that the issuer is Packet Delivery, as the public key used to verify the credential's signature is cryptographically associated with the true identity of Packet Delivery registered in the trust framework.
• (Optional) It can prove that the credential was issued no later than a given time, as the credential was registered on the blockchain at the time of issuance (timestamp).
  • Note1: The timestamp date can be later than the date in the "issuance date" field contained in the credential. For example, a credential is created and signed, but timestamped the next day (possibly for batch processing with other credentials). The key point is that no one can create a credential from the past. The verifier must check that the field "issuance time" in the credential is not later than the timestamp (at least leaving some leeway to account for clock synchronization differences).
  • Note2: Many credentials may not require timestamps, thus avoiding the overhead of the registration process. This entirely depends on the type of credential, the intended use of the credential, and the assumed risk level. The employee credential discussed here is an example of a credential that does not need to have the same risk level as a timestamp. The only thing the verifier requires is that the holder can prove that when using the credential (e.g., during login), the credential was issued by the employer (in our case, Packet Delivery). Clearly, this does not require a timestamp, as if the employee can provide the credential during login, it can only be done if the credential was issued previously.

From the above description, we can derive the following trust attributes for verifiers receiving the credential:

• The level of trust in the credential issuer's identity depends on the verifier's trust in the registration process implemented in the trust framework. The registration process associates the issuer's public key with its true identity.
• The level of trust in the claims within the credential depends on the verifier's trust in the issuing entity. For example, Packet Delivery could issue employee credentials to individuals who are not actual employees. However, if this occurs, the verifier has a strong non-repudiation mechanism to prove to third parties (e.g., courts) that the issuer stated false facts.
  Thus, it can be seen that Packet Delivery can issue employee credentials containing certain employee data (name, surname, etc.), and the verifier can give a certain level of trust to these claims.

But this only proves that Packet Delivery certifies that the data in the credential (referred to as claims) is true. It does not indicate whether the person submitting the credential online is the same as the person mentioned in the claims. In other words, the person sending the employee credential to the verifier may be different from the employee. This is why the credential includes a public key as one of the claims associated with the employee (in the "credentialSubject" object).

This public key corresponds to the private key generated during the credential issuance process on the employee's device (PC or mobile device). This process will be detailed later, but it essentially involves the following steps:

• The employee generates a pair of public/private keys and sends the public key to the employer via an authenticated and encrypted channel (e.g., HTTPS). This channel can be the mechanism the employee uses to connect to enterprise applications.
• The employer generates a credential containing certain employee data and includes the public key.
• The employer signs the credential and sends it to the employee via the same authenticated channel.

The following example shows the metadata and visualized content of the credential issued by Packet Delivery:

// Credential issued by PacketDelivery to its employees, providing access to 
// Marketplace, either to create offerings or to purchase offerings. 
{ 
   "@context":[ 
   "https://www.w3.org/2018/credentials/v1", 
   "https://marketplace.fiware.io/2022/credentials/employee/v1" 
   ], 
   "id": "https://pdc.fiware.io/credentials/6e14b8b8-87fa0014fe2a", 
   "type": ["VerifiableCredential", "EmployeeCredential"], 
   "issuer": { 
        "id": "did:elsi:EU.EORI.NLPACKETDEL" 
   }, 
   "issuanceDate": "2022-03-22T14:00:00Z", 
   "validFrom": "2022-03-22T14:00:00Z", 
   "expirationDate": "2023-03-22T14:00:00Z", 
   "credentialSubject": { 
       "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
       "verificationMethod":[ 
       { 
            "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
            "type":"JwsVerificationKey2020", 
            "controller": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
            "publicKeyJwk": { 
                 "kid":"key1", 
                 "kty":"EC", 
                 "crv":"P-256", 
                 "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                 "y":"fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
            } 
        } 
   ], 
       "roles": [ 
       { 
            "target": "did:elsi:EU.EORI.NLMARKETPLA", 
            "names": ["seller", "buyer"] 
       } 
       ], 
       "name":"Jane Doe", 
       "given_name":"Jane", 
       "family_name":"Doe", 
       "preferred_username":"j.doe", 
       "email": "[email protected]" 
   } 
} 

The structure of the above credential can be visualized as follows:

This credential type is EmployeeCredential, and to enable access to the marketplace, the embedded roles can be buyer, seller, or both. The URL in the @context field points to the marketplace (https://pdc.fiware.io/2022/credentials/employee/v1), which defines the general requirements for employee credentials. However, participants in the ecosystem can extend it and, of course, can use the roles and role names they need for their purposes.

The credential's credentialSubject part has the following objects:

• id, specified as DID. For privacy reasons, and given that this is a natural person, the Peer Method specified in the W3C Peer DID method specification is used. This method can be used independently of any central source of truth and is designed to be cheap, fast, scalable, and secure. It is suitable for most private relationships between people, organizations, and things.
• verificationMethod, which is a standard W3C VC object specifying the public key associated with the employee's DID. The binding between the employee's DID and the public key is completed when Packet Delivery issues the credential.
• roles is an array containing one or more role specifications. Each specification defines a potential target entity that will receive the credential, along with one or more role names defined by that target entity.
  • target is the DID of the entity that will receive the credential.
  • names is an array containing one or more roles that are recognized by the target entity and will be used by the target entity to apply its own access control policies. In the example, we used the buyer and seller roles defined by the marketplace. Other entities can define their own roles for their specific purposes. The names become unique in the ecosystem due to the target attributes.
• The remaining fields in the credential have the usual meaning in the standard W3C verifiable credential data model.

The top-level "id" field is the identifier of the credential, which can be used for revocation if that functionality is needed. The basic requirements for the "id" field are:

• It is unique within the scope it will be used.
• It is based on a cryptographically secure random number generator, making it difficult for potential attackers trying to revoke a given credential to "guess." Using such an id can reduce the probability of an attacker guessing the id to the same level as guessing the private key,
• It has no relation to the profile contained in the certificate to minimize the risk of correlation.
• UUID version 4 meets all these requirements, but other patterns can also be used.

3.2 Happy Pets or No Cheaper Employee Credentials#

The employee certificates issued by Happy Pets and No Cheaper are essentially the same as the employee certificates from Packet Delivery described above. The main difference lies in the set of roles assigned to employees and the set of roles specified in the "roles" claim.

// Credential issued by HappyPets to its employees, providing access 
// to order creation in PacketDelivery. 
{ 
    "@context":[ 
        "https://www.w3.org/2018/credentials/v1", 
        "https://happypets.fiware.io/2022/credentials/employee/v1" 
    ], 
    "id":"https://happypets.fiware.io/credentials/25159389-8dd17b796ac0", 
    "type": ["VerifiableCredential", "EmployeeCredential"], 
    "issuer": { 
        "id":"did:elsi:EU.EORI.NLHAPPYPETS" 
    }, 
    "issuanceDate": "2022-03-22T14:00:00Z", 
    "validFrom": "2022-03-22T14:00:00Z", 
    "expirationDate": "2023-03-22T14:00:00Z", 
    "credentialSubject": { 
        "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
        "verificationMethod":[ 
        { 
             "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
             "type":"JwsVerificationKey2020", 
             "controller":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
             "publicKeyJwk": { 
                 "kid":"key1", 
                 "kty":"EC", 
                 "crv":"P-256", 
                 "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                 "y":"fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
             } 
        } 
        ], 
        "roles":[ 
        { 
             "target": "did:elsi:EU.EORI.NLPACKETDEL", 
             "names": ["P.Create"] 
        } 
        ], 
        "name":"Jane Doe", 
        "given_name": "Jane", 
        "family_name": "Doe", 
        "preferred_username": "j.doe", 
        "email": "[email protected]" 
    } 
} 

3.3 Happy Pets or No Cheaper Customer Credentials#

Happy Pets uses this credential to delegate access to customers who wish to access services provided by Packet Delivery, which were previously purchased by Happy Pets.

It follows the same model as the employee credentials:

• The credential should be issued by Happy Pets through secure and authenticated channels as part of the previous customer registration process (KYC).
• The roles included in the credential correspond to the customer types, and the role names are defined and understood by the service provider (in this case, Packet Delivery).

// Credential issued by HappyPets to a customer,
// providing access to Gold services at PacketDelivery.
{ 
    "@context":[ 
        "https://www.w3.org/2018/credentials/v1", 
        "https://happypets.fiware.io/2022/credentials/employee/v1" 
    ], 
    "id":"https://happypets.fiware.io/credentials/25159389-8dd17b796ac0", 
    "type": ["VerifiableCredential", "CustomerCredential"], 
    "issuer": { 
        "id":"did:elsi:EU.EORI.NLHAPPYPETS" 
    },
    "issuanceDate":"2022-03-22T14:00:00Z", 
    "validFrom":"2022-03-22T14:00:00Z", 
    "expirationDate":"2023-03-22T14:00:00Z", 
    "credentialSubject": { 
        "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
        "verificationMethod":[ 
        { 
            "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
            "type":"JwsVerificationKey2020", 
            "controller":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
            "publicKeyJwk":{ 
                "kid":"key1", 
                "kty":"EC", 
                "crv":"P-256", 
                "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                "y": "fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
            } 
        } 
        ], 
        "roles":[ 
        { 
            "target":"did:elsi:EU.EORI.NLPACKETDEL", 
            "names": ["P.Info.gold"] // Or P.Info.standard 
        } 
        ], 
        "name": "Jane Doe", 
        "given_name": "Jane", 
        "family_name": "Doe", 
        "preferred_username": "j.doe", 
        "email": "[email protected]" 
    } 
} 

3.4 Role-Based Access Control#

From the credentials above, it can be seen that they contain claims specifying roles. The roles are not defined by the issuer of the credential but by the provider (i.e., the relying party) that will receive the credential and perform authentication and authorization, in this case, Packet Delivery.

The provider defines a role with a specific name that maps to a set of policies that the provider wishes to enforce. A product on the platform represents a role (or multiple roles). When obtaining access to a product on the platform, these roles are issued to the organization that obtains access in the provider's authorization registry. Additionally, the organization that obtains access can assign these roles to their users by embedding them in the VC issued to their users.

When accessing services, the provider's PEP proxy/PDP component retrieves the attribute-based policy set belonging to the assigned roles and performs access authorization evaluation based on the NGSI-LD request.

The scope of this document does not include describing the actual policy language and engine (such as ODRL, Rego, etc.) that enforces these policies.

3.5 Component Deployment#

In addition to the components in Section 2, the following components are also necessary:

• Verifiable Data Registry: In the form of a blockchain network, serving as the core technology for implementing the ecosystem's trust framework. Some entities participating in the ecosystem (not necessarily all entities) should operate blockchain nodes to collaboratively create and operate a suitable blockchain network as the backbone of the trust framework.
• Universal Resolver: The Universal Resolver resolves decentralized identifiers (DID) of various DID methods according to W3C DID Core 1.0 and DID resolution specifications (the original link provided for the materials is no longer accessible).
• Credential Issuer and Verifier Components: These components are typically implemented as extensions of existing components that implement the OpenID Credential (OIDC) process.
• End-User Wallet: The wallet component used by end-users to receive, hold, and present the verifiable credentials issued to them. This component can be implemented as a native mobile application, a PWA application, or even a web application hosted by one or more highly trusted entities in the ecosystem.

4 Detailed Workflow#

When using the SIOP flow with verifiable credentials, it can be observed that the Marketplace does not need to query any other entities in the ecosystem to verify the credentials, as all the required information is contained in the verifiable credentials provided by the employee and accessed through the decentralized verifiable registry (implemented using a blockchain network in our case) via the Universal Resolver.

In other words, the workflow is essentially peer-to-peer, without needing to query a centralized IdP, thus providing an efficient, scalable, private, and resilient framework.

4.1 Order Creation#

Different interactions are illustrated in the architecture overview:

4.1.1 User Access#

1. Packet Delivery employees access the Marketplace portal (provided by BAE Logic Proxy) to log in.

2. The Marketplace portal displays a list of identity providers for selecting the desired identity provider for login. One of the login options is "Login with Verifiable Credentials." Packet Delivery Co employees select the "Verifiable Credentials" login method, which causes the Marketplace portal to generate a QR containing the URL of the Marketplace server's /authentication request endpoint.

3. Employees enable the scanning function in their digital wallet to scan the QR, and the phone calls the /authentication request endpoint. The purpose of scanning is to initiate the authentication process, ensuring that the logged-in user is indeed the employee holding the credential.

4.1.2 Initiating the Authentication Process#

4. The wallet automatically accesses the URL contained in the QR to initiate the authentication process. In this step, the wallet sends a POST request to the specified authentication interface, requesting verification information.

5. SIOP (Self-Issued OpenID Provider) is an open authentication protocol. This will initiate a standard SIOP process.
   In this process, the marketplace acts as the relying party (RP in OpenID Connect terminology), and the employee's mobile device acts as the Self-Issued IDP. In this step, the Marketplace creates an SIOP authentication request. Since the self-issued OP may run as a native application or progressive web application (PWA), the RP may not have a web-addressable endpoint to communicate directly with the OP. We must leverage the implicit flow of OpenID Connect to communicate with these locally running OPs, as described in [https://openid.net/specs/openid-connect-self-issued-v2-1_0.html].

6. The authentication request is returned to the employee's wallet as SIOP. The SIOP flow uses a new response mode post, which is used to request SIOP to pass the result of the authentication process to a certain endpoint. The parameter response_mode is used to carry this value. The endpoint for delivering the authentication result by SIOP is defined in the standard parameter redirect_uri.

4.1.3 Resolving DID#

7. In this step, the employee verifies that the Marketplace is a trusted entity in the ecosystem by resolving the Marketplace's DID received in the client_id parameter of the authentication request.

To resolve the DID, the wallet sends a GET request to one of several trusted server endpoints that can implement the Universal Resolver functionality: /api/did/v1/identifiers/did:elsi.EORI.NLMARKETPLA.

• The Universal Resolver includes a blockchain node, and there can be multiple nodes as needed. Its task is to resolve the DID using the blockchain and return the relevant DID document.
• The DID document (according to W3C) contains relevant information about the DID entity owner. It includes its public key for verifying the entity's digital signature. It also contains the entity's status in the data space ecosystem. It is extensible and can include any public information relevant to the use case. The Universal Resolver server must be operated by a trusted entity of the customer. There can be any number of nodes operated by different entities. At least one of these trusted entities must be configured in the employee's wallet.

8. The wallet can obtain the Marketplace's DID document. The document provides details about the marketplace, including the marketplace's digital signature public key, ensuring that the wallet interacts with a legitimate marketplace entity. It contains trustworthy information about the entity, including the public key associated with the private key used by the Marketplace to digitally sign tokens. For example:

{
    "payload": {
         "@context": [
            "https://www.w3.org/ns/did/v1",
            "https://w3id.org/security/v1"
        ],
        "id": "did:elsi:EU.EORI.NLMARKETPLA",
        "verificationMethod": [
        {
            "id": "did:elsi:EU.EORI.NLMARKETPLA#key-verification",
            "type": "JwsVerificationKey2020",
            "controller": "did:elsi:EU.EORI.NLMARKETPLA",
            "publicKeyJwk": {
            "kid": "key-verification",
            "kty": "EC",
            "crv": "secp256k1",
            "x": "V8XptJkb5wplYkExcTF4nkyYVp7t5H5d5C4UPqCCM9c",
            "y": "kn3nSPxIIvd9iaG0N4v14ceuo8E4PcLXhhGeDzCE7VM"
            }
        }
    ],
    "service": [
    {
        "id": "did:elsi:EU.EORI.NLMARKETPLA#info",
        "type": "EntityCommercialInfo",
        "serviceEndpoint": "https://marketplace.fiware.io/info",
        "name": "Packet Delivery co."
    },
    {
        "id": "did:elsi:EU.EORI.NLMARKETPLA#sms",
        "type": "SecureMessagingService",
        "serviceEndpoint": "https://marketplace.fiware.io/api/sms"
    }
    ],
    "anchors": [
    {
        "id": "redt.alastria",
        "resolution": "UniversalResolver",
        "domain": "marketplace.dataspace",
        "ethereumAddress": "0xbcB9b29eeb28f36fd84f1CfF98C3F1887D831d78"
    }
    ],
    "created": "2021-11-14T13:02:37Z",
    "updated": "2021-11-14T13:02:37Z"
    }
}

4.1.4 Verifying the Identity Request#

9. The wallet verifies the received authentication request. It checks the digital signature of the request to confirm that the signature was generated by a legitimate marketplace entity. Importance: This step ensures that the wallet is interacting with the real marketplace and is not being deceived by a man-in-the-middle attack or other forms of network fraud.
   The DID document contains one or more public keys in the verificationMethod array. The keys are identified by the id field of each element in the array. The employee's wallet uses the kid field received in the authentication request (in the protected header of the JWT) to select the corresponding public key and verify the JWT's signature. It also verifies that the top-level id field in the DID document ("DID:elsi.EORI.NLMARKETPLA") matches the client_id parameter of the authentication request.

4.1.5 Creating the Authentication Response#

10. If the authentication request is verified as legitimate, the wallet generates an authentication response and publishes it to the redirect_uri specified by the Marketplace in step 5. This response will contain a verifiable credential (VC) indicating the employee's identity and permissions.

Key point: This verifiable credential is issued by the parcel delivery company, certifying that the employee is indeed a member of the company and has the corresponding access rights.

11. The wallet sends the authentication response to the Marketplace's SIOP session interface. The marketplace will decide whether to grant the employee access based on the received response.

SIOP sends the authentication response to the endpoint passed in the redirect_uri authentication request parameter using an HTTP POST request encoded as "application/x-www-form-urlencoded." The response contains an ID token and a VP (verifiable presentation) token, as defined for verifiable presentations in OpenID.

POST /siop_sessions HTTP/1.1
Host: marketplace.fiware.io
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&vp_token=...
&state=af0ifjsldkj

The decoded id_token:

{
 "iss": "https://self-issued.me/v2",
 "aud": "did:elsi:EU.EORI.NLMARKETPLA",
 "iat": 1615910538,
 "exp": 1615911138,
 "sub": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
 "auth_time": 1615910535,
 "nonce": "n-0S6_WzA2Mj"
}

Where "sub": "did:peer:99ab5bca41bb45b78d242a46f0157b7d" is the user's DID, which is not registered in the blockchain or any centralized repository for privacy reasons. It must match the DID included in the verifiable credential, which was issued by the parcel delivery company upon the employee's onboarding and propagated in the authentication response.
The vp_token includes the verifiable presentation, which can be in two formats: jwt_vp (JWT encoded) or ldp_vp (JSON-LD encoded). The following example uses JWT encoding:

{
 "format": "jwt_vp",
 "presentation":
 "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0
 MzFjMjc2ZTEyZWNhYiNrZXlzLTEifQ.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxY
 zI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzc
 yI6Imh0dHBzOi8vZXhhbXBsZS5jb20va2V5cy9mb28uandrIiwibmJmIjoxNTQxNDkzNzI0LCJpYXQiO
 jE1NDE0OTM3MjQsImV4cCI6MTU3MzAyOTcyMywibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY
 29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd
 3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZ
 UNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjd
 CI6eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IjxzcGFuIGxhbmc9J2ZyL
 UNBJz5CYWNjYWxhdXLDqWF0IGVuIG11c2lxdWVzIG51bcOpcmlxdWVzPC9zcGFuPiJ9fX19.KLJo5GAy
 BND3LDTn9H7FQokEsUEi8jKwXhGvoN3JtRa51xrNDgXDb0cq1UTYB-rK4Ft9YVmR1NI_ZOF8oGc_7wAp
 8PHbF2HaWodQIoOBxxT-4WNqAxft7ET6lkH-4S6Ux3rSGAmczMohEEf8eCeN-jC8WekdPl6zKZQj0YPB
 1rx6X0-xlFBs7cl6Wt8rfBP_tZ9YgVWrQmUWypSioc0MUyiphmyEbLZagTyPlUyflGlEdqrZAv6eSe6R
 txJy6M1-lD7a5HTzanYTWBPAUHDZGyGKXdJw-W_x0IWChBzI8t3kpG253fg6V3tPgHeKXE94fz_QpYfg
 --7kLsyBAfQGbg"
}

The decoded structure is:

{
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [
    {
        "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://marketplace.fiware.io/2022/credentials/employee/v1"
    ],
    "id": "https://pdc.fiware.io/credentials/6e14b8b8-87fa0014fe2a",
    "type": ["VerifiableCredential", "EmployeeCredential"],
    "issuer": {
    "id": "did:elsi:EU.EORI.NLPACKETDEL"
    },
    "issuanceDate": "2022-03-22T14:00:00Z",
    "validFrom": "2022-03-22T14:00:00Z",
    "expirationDate": "2023-03-22T14:00:00Z",
    "credentialSubject": {
    "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
    "verificationMethod": [
        {
        "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1",
        "type": "JwsVerificationKey2020",
        "controller": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
        "publicKeyJwk": {
        "kid": "key1",
        "kty": "EC",
        "crv": "P-256",
        "x": "lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo",
        "y": "fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0"
        }
    }
 ],
    "roles": [
    {
    "target": "did:elsi:EU.EORI.NLMARKETPLA",
    "names": ["seller", "buyer"]
    }
 ],
    "name": "Jane Doe",
    "given_name": "Jane",
    "family_name": "Doe",
    "preferred_username": "j.doe",
    "email": "[email protected]"
     }
     }
 ]
}

12. The marketplace resolves the parcel delivery company's DID document through the Universal Resolver, verifying the company's identity and public key information. This step ensures that the marketplace interacts with a legitimate company entity. The DID is found within the verifiable credential received in the verifiable presentation. This DID can be found in the "issuer" field of the "verifiableCredential" structure above. The resolution is performed by sending a GET request to the Universal Resolver: /api/did/v1/identifiers/did:elsi.EORI.NLPACKETDEL. The marketplace can use a Universal Resolver operated by different entities, but this lowers the trust level compared to using its own server directly connected to the blockchain network.

4.1.6 Verifying the Identity Response#

13. The marketplace obtains the parcel delivery company's DID document, which contains the company's public key and other necessary information for subsequent verification processes.

The company's public key is associated with the private key used to digitally sign the verifiable credential that the employee just presented as part of the authentication process. Using the public key and the DID in the DID document, it can verify the signature of the verifiable credential and confirm that the parcel delivery company is a trusted entity in the ecosystem and that it is active.

14. The marketplace uses the parcel delivery company's public key to verify the digital signature of the identity response, ensuring that the identity response was indeed generated by a legitimate company.

The above content is only used to verify the verifiable certificate. Additionally, the Marketplace can also verify that the verifiable presentation containing the verifiable credential was sent by the employee and not by a malicious agent. To do this, it uses the employee's public key in the "verificationMethod" of the "credentialSubject" structure. This public key was cryptographically bound to the employee's DID during the onboarding process executed by Packet Delivery Co.

4.1.7 Creating and Obtaining Access Token#

15. After completing all verifications, the Marketplace creates an access token for the employee so that she can use it to access services in the Marketplace server in the future.

16. The marketplace confirms the successful authentication and returns an HTTP 200 status code to the wallet, along with the generated access token.

17. The employee's wallet displays a confirmation message indicating that the authentication and token acquisition process has been successfully completed.

18. After refreshing the portal page, the employee can see new service options based on her identity and permissions.

4.1.8 Requesting Order Creation Service#

At this point, the Packet Delivery Co employee has logged into the Marketplace application. The user can now create catalogs, products, and offerings.

At this time, the information known to the marketplace:

• The Packet Delivery Co belongs to the data space and can issue credentials of type EmployeeCredential, as it is included in the trusted issuer list and is active, as this information is contained in the DID document retrieved in step 13.
• The Packet Delivery Co states that the user is one of its employees. This information is contained in the verifiable credential, which is digitally signed by Packet Delivery Co.

From this point on, the Marketplace can display available services to the user and execute those services if the user is authorized to do so. The Marketplace can use all claims in the credential to perform RBAC/ABAC access control and policy enforcement.

19. Display the services available.

20. Request the creation service.

21. The marketplace provides offer details.

22. The offer can be provided as Standard or Gold. The user makes a selection.

23. Creation is successful, and the marketplace sends a 200 OK message to the wallet.

4.2 Obtaining Rights/Activation#

The process demonstrates how Happy Pets employees obtain access to specific services on the Marketplace using decentralized identifiers (DID) and verifiable credentials (VC). The entire process is designed to ensure secure verification of employee identity and provide transparent access control.

This process is identical to the verification process described in 4.1. The difference is that Happy Pets or No Cheaper employees' initial authentication on the Marketplace is performed using the verifiable credentials issued to their employees, with only the involved names needing to be modified. This will not be elaborated further.

4.3 Accessing Data Services#

The following describes in detail the process by which Happy Pets customers change the PTA attribute when using verifiable credentials.

Participants: Happy Pets (Authorization Registry, Identity Provider), User (Customer SLOP), Packet Delivery (Portal, Proxy, Authorization Registry, Blockchain Node)

1. Happy Pets customers can access the parcel delivery company's portal or launch the parcel delivery company's application on their smartphones to log in.

2. Happy Pets customers are redirected to a page to select the desired identity provider for login. One of the login options is "Verifiable Credentials" or something similar.

3. Happy Pets customers select the "Verifiable Credentials" login method, which causes the Packet Delivery Co. portal to generate a QR containing the URL of the parcel delivery company's IDP's /authentication request endpoint, sent to the customer's wallet.

4. The customer scans the QR with her phone, sending a request to the /authentication-requests endpoint.

5. Upon receiving the authentication request sent by the wallet, the Packet Delivery portal initiates a standard SIOP process, generating a request token and returning it to the customer's wallet. This token contains not only the DID (decentralized identifier) of Packet Delivery but also some other key information. The generation of this token effectively issues a temporary pass to the customer's wallet, which will use it to continue subsequent verification operations. The request token ensures that the following verification steps are unique and secure.

6. The authentication request is returned to the customer's wallet as SIOP. The SIOP flow uses a new response mode post, which is used to request SIOP to pass the result of the authentication process to a certain endpoint. The parameter response_mode is used to carry this value. The endpoint for delivering the authentication result by SIOP is defined in the standard parameter redirect_uri.

Returning URI + Request Token, the Request Token contains a DID of Packet Delivery.

7. In this step, the customer's wallet uses the Universal Resolver to resolve the DID of the Packet Delivery company. The resolution is performed on the DID of the Packet Delivery company received in the client_id parameter of the authentication request, verifying that the parcel delivery company is a trusted entity in the ecosystem.
   

8. The Universal Resolver returns the DID document of the Packet Delivery company, which contains not only the public key of Packet Delivery but also its status information in the trust network. This information helps the customer's wallet confirm that the Packet Delivery company is a trusted entity and that it plays a reliable role in the entire data ecosystem. By checking the information in the DID document, the wallet can further confirm that the data being sent and received will not be tampered with or forged.

9. The customer's wallet uses the information obtained from the DID document to verify the authentication request from the Packet Delivery portal. First, the wallet checks the digital signature of the authentication request to confirm that the request was indeed signed by the Packet Delivery company. This step is akin to checking whether the signature on a passport matches that of the holder to ensure the authenticity and integrity of the request. Next, the wallet verifies that the DID in the authentication request matches the information in the previously resolved DID document, ensuring that the request has not been tampered with and indeed comes from the real Packet Delivery company.

10. The customer's wallet creates an authentication response (URI + id_token), which will be published to the redirect_uri specified by Packet Delivery in step 5. The id_token needs to include the customer's DID, as well as the VC as another claim, which is granted to the customer by Happy Pets.

11. The customer's wallet submits the generated authentication response to the specific API endpoint of the Packet Delivery portal (such as /siop-sessions), which is akin to submitting your pass at a security checkpoint. The Packet Delivery portal checks this response, verifying the customer's identity and the associated verifiable credential to ensure that the customer is authorized to access the corresponding services. This step verifies the customer's digital identity and the integrity of the credential, ensuring that the information has not been tampered with or forged during transmission.

12. The Packet Delivery portal resolves Happy Pets' DID through the Universal Resolver. This DID can be found within the verifiable credential received in the verifiable presentation. This DID can be found in the "issuer" field of the "verifiableCredential" structure above.

13. Packet Delivery receives Happy Pets' DID document, which contains trustworthy information about the company, including the public key associated with the private key used by Happy Pets to digitally sign the verifiable credential that the customer just sent in the verifiable presentation as part of the authentication flow. Using the public key and the DID in the DID document, it can verify the signature of the verifiable credential and confirm that Happy Pets is a trusted entity in the ecosystem.

14. The above content is only used to verify the verifiable certificate. Additionally, the parcel delivery company can also verify that the verifiable presentation containing the verifiable credential was sent by the customer and not by a malicious agent. To do this, it uses the customer's public key in the "verificationMethod" of the "credentialSubject" structure. This public key was cryptographically bound to the customer's DID during the onboarding process executed by Happy Pets.

15. After completing all verifications, the Packet Delivery company creates an access token for the customer so that she can use it to access services in the Packet Delivery company in the future.

16. The wallet (SIOP) receives a successful reply to the POST request.

17. The Packet Delivery company proxy notifies the Packet Delivery portal that the customer has successfully authenticated, and the portal can display the services available to that customer. The user's browser receives an access token created by Packet Delivery, allowing it to request services without going through the previous authentication process. The access token is a standard OAuth access token that contains the information needed for the parcel delivery to access its services.

At this point, the Happy Pets customer has logged into the parcel delivery company portal/application and sees the services that may be offered, including the option to change the PTA of their delivery order.

18. The Happy Pets customer will see the possible services offered by Packet Delivery, including the option to change the PTA of their delivery order.

19. The Happy Pets customer searches for her parcel delivery order and displays its details. She now requests to change the PTA of this order on the parcel delivery company portal/application.

20. The Packet Delivery Portal/APP sends a request to the Packet Delivery Proxy to change the PTA of the delivery order. The request includes the Access Token generated in step 15, as well as information to retrieve policies from the authorization registry.

> Authorization: Bearer IIeD...NIQ // Bearer JWT
> Content-Type: application/json
PATCH https://umbrella.fiware.io/ngsi-ld/v1/entities/urn:ngsild:DELIVERYORDER:001/attrs/pta
> Payload
{
 "value": "<new PTA>",
 "type": "Property"
}

Decoded Bearer JWT payload:

{
    "iss": "EU.EORI.NLHAPPYPETS", // Issuer: Happy Pets
    "sub": "419404e1-07ce-4d80-9e8a-eca94vde0003de", // Customer pseudonym
    "jti": "d8a7fd7465754a4a9117ee28f5b7fb60",
    "iat": 1591966224,
    "exp": 1591966254,
    "aud": "EU.EORI.NLHAPPYPETS",
    "authorisationRegistry": { // AR to retrieve policies from
        "url": "https://ar.packetdelivery.com",
        "identifier": "EU.EORI.NLHAPPYPETS",
        "delegation_endpoint": "https://ar.packetdelivery.com/delegation",
    }
}

21. The Packet Delivery Co. Proxy receives the request to change the PTA of the delivery order from step 19. The access token received from the customer ensures that she has been assigned the delegated evidence of the policy to update the PTA attribute of this specific delivery order (referred to as publishing at the user level). Additionally, since the required customer policy in this scenario is published by a third party (Happy Pets), the proxy must check whether Happy Pets itself allows delegating this policy. Generally, the rule is that the proxy needs to check for the existence of valid policies through the issuer chain until it itself (in this case, the parcel delivery company) becomes the issuer. In this scenario, the proxy will check policies at two different levels: organizational level (from Packet Delivery company to Happy Pets) and user level (from Happy Pets to the customer). The verifiable credential is responsible for user-level policies.

22. To check whether Happy Pets allows delegating the policy to its customers, the proxy will check whether the policy exists in the Packet Delivery Authorization Registry. The proxy sends a request to the endpoint of the Packet Delivery Authorization Registry.

23. The proxy receives the delegated evidence policy sent from Packet Delivery to Happy Pets.

24. Upon receiving the delegation information from the Packet Delivery company Authorization Registry, the proxy (or more accurately, the PDP) can now evaluate whether the organizational policy contained allows updating the PTA attribute, thus assessing whether Happy Pets is allowed to delegate access to its customers. If the proxy receives a valid policy, access will be granted at the organizational level.

If the requested delegated evidence cannot be found, or if the returned policy contains Deny rules, the PTA change will be rejected by the Packet Delivery company proxy, and an error will be returned to the Packet Delivery company portal/application, while displaying it to the Happy Pets customer. The following steps can be omitted.

25. As described in the previous steps, the PDP evaluates granting the change of PTA for the specific delivery order at both the organizational and user levels. Therefore, the request to change the PTA is forwarded by the proxy to the context broker, which holds the information about the parcel delivery order. The PTA of the parcel delivery order is changed, and the context broker returns an HTTP code 204 success response. The context broker's response returns to the Portal in response to the request in step 26.

26. The successful PTA change is presented to the Happy Pets customer.

4.4 No Rights#

This section describes the variations of the above steps in the No Cheaper customer scenario.

Basically, the sequence of steps is the same as for Happy Pets. In contrast, in the rights acquisition process described in [4.2 Obtaining Rights/Activation], No Cheaper only acquires standard services, so its customers can only read the attributes of the delivery order. This means that in the parcel delivery authorization registry, only a policy has been created allowing No Cheaper to issue GET access to the delivery order.

This scenario can be divided into two cases to demonstrate the different policy-based access denial at the organizational and user levels.

1. In the No Cheaper authorization registry, a verifiable credential is issued to No Cheaper customers, allowing only GET requests to the parcel delivery service (representing the P.Info.standard role). When executing the step to change the PTA value of the delivery order (as described in the previous section), the process will stop at step 19, at which point access will be denied because there is no necessary policy assigned at the user level for No Cheaper customers.

2. In the No Cheaper authorization registry, a verifiable credential is issued to No Cheaper customers, allowing both GET and PATCH requests to the parcel delivery service (representing the P.Info.gold role). When executing the step to change the PTA value of the delivery order, as described in the previous section, the process will stop at step 23, at which point access will be denied because the necessary policy to delegate premium access to its customers has not been assigned in the parcel delivery company authorization registry.

Thus, access will be denied at the organizational level. This is to indicate that even if the No Cheaper organization issues access to premium services to its customers in its own Authorization Registry, access will still be denied.

In general, the requests to change the PTA should be denied in both cases. However, it can be shown that No Cheaper customers are able to view the attributes of their delivery orders.

4.5 Publishing Tokens for Connectors / Application Context#