This paper explores some challenges that can arise in authentication and authorisation processes between holder and verifier in the paradigm of Self-Sovereign Identity (SSI ). The authentication phase within the SSI framework is crucial in ensuring the integrity of secure and private data exchanges between the holder and verifier. In particular, we analyse the unauthorised use of credentials, which can be a source of privacy and protection concerns. For instance, sending data to unauthorised third parties could give them access to more information than necessary. We propose a prospective solution for monitoring access to users' personal information. The focus is on defining a Disclosure Policy (DP) within an Attribute-Based Access Control (ABAC) model based on the Originator Control (ORCON ) paradigm.
In an interconnected digital environment, the accidental exposure of sensitive information to unintended third parties poses a significant threat to individual privacy and security. The abundance of personal data shared online and stored in diverse databases raises concerns about potential mishandling or unauthorised access. The consequences of such disclosures extend from identity theft and financial fraud to reputational damage and physical harm, posing a substantial risk to users’ digital identities.
In response to these challenges, Identity and Access Management (IAM) approaches have evolved from
traditional centralised models to more contemporary user-centric ones. The primary objective is to
empower users with greater control over their personal data. Various options, including the utilisation
of Personal Authentication Devices (PADs) like smartphones or smartcards, have been considered to store
authentication credentials, eliminating the need for a third-party entity such as an Identity Provider
(IdP) [
However, as noted in previous studies [
Furthermore, a correlated problem is exposing sensitive information to an unauthorised actor [
This paper addresses potential authentication and authorisation challenges associated with the IAM
model, which may lead to misusing users’ credentials and jeopardising privacy. The issue we will
address is the transmission of user credentials to an unauthorised entity. Our proposed solution involves
monitoring access to credentials using ABAC combined with ORCON. The latter enables the originator
of the credentials to define access requirements rather than the possessor, as in a Discretionary Access
Control (DAC) model. Furthermore, we selected an attribute-based access control model because it
ofers greater flexibility and improves access control accuracy. It allows for more precise rules and a
greater range of variable combinations without specifying the individual relationships between each
subject and each object [
The proposed solution involves leveraging the Ethereum blockchain to develop a Disclosure Policy (DP), which is an access control policy defined in a smart contract whose main objective is the protection of user credentials. The creator of the DP is also known as the originator of the credentials or the issuer in the SSI system. This model is suitable for use in contexts where the credentials require additional protection, such as organisation or company VCs. Furthermore, as previously stated, our model is based on an ABAC model, which considers the verifier’s attributes, and an ORCON model, in which the policy is defined by the issuer, i.e., the creator of the verifiable credential.
The rest of this paper is divided as follows. Section 2 overviews the information regarding the types and terminology used in Self-Sovereign Identity and Access Models. SSI authentication and authorisation problems are reported in Section 3 along with proposed solutions based on AC models. Finally, Section 4 defines some related literary works, and Section 5 concludes with suggestions for further research.
This section presents the background necessary to comprehend the following topics better. In particular, we explain the SSI concept and Access Control (AC) models.
In the preceding section, we briefly introduced the concept and evolution of Identity and Access
Management (IAM) systems. Before delving into a classification of these models, it is essential to
highlight three fundamental concepts: identification , authentication, and authorisation. Identification
involves recognising an individual through unique attributes or identifiers , such as an email address.
Authentication verifies the identity of a user, agent, or device, while authorisation grants the right or
permission for system entities to access resources [
The increasing demand for digital identities has spurred the development of IAM models, ofering
services related to identity creation, management, and removal, as well as authentication and
authorisation for resource access. In traditional IAM models, SP and IdP play key roles. SPs ofer specific
services and products, while IdPs enable users to authenticate across diferent services using the same
credentials [
The transition from centralised to SSI models is depicted in Figure 1. SPs and IdPs are indistinguishable in centralised systems, leading to usability concerns and password reuse. IdPs were introduced to simplify authentication, allowing users to register with a few IdPs and use the credentials across various SPs, reducing the burden on both users and SPs.
Protocols such as SAML, OAuth 2.0, and OpenID Connect were developed to facilitate secure interactions. While these models simplified identifier and password management, they also resulted in the creation of large silos of private information. The evolution from centralised to SSI models reflects a shift towards more secure, user-centric, and privacy-preserving IAM systems.
As we transition towards more decentralised systems, the distinction between service and identity
providers becomes clearer. SSI emerges as a cutting-edge solution, ensuring high privacy for users’
information. Recent studies aim to establish an IAM system without a central trusted third party,
leveraging SSI. The fundamental concept involves empowering individuals to own and manage their
digital identity, fostering a user-centric model [
As mentioned, credentials are typically stored in private storage, but specific information requires
public storage. For instance, public keys associated with SSI entities are stored in a Distributed Ledger
Technology (DLT ), commonly referred to as a blockchain. Blockchain technology facilitates new methods
of personal data management due to its decentralised consent protocol and distributed approach [
Verifiable, decentralised digital identification is also made possible by the novel identifier known
as Decentralised Identifiers (DID) [
Access Control (AC) systems are used in a variety of settings where it is necessary to link user
characteristics to their roles or groups [
The properties considered by the model and the policy’s author alter the kind of AC system. Indeed, there are many diferent models (RBAC, ABAC, MAC, etc.); however, in this paper, we will discuss just a few of them. In particular, we will describe the ORCON after explaining briefly the MAC and DAC models.
The Mandatory Access Control (MAC) model is a security paradigm in which a central authority
defines and enforces access rules for system objects and users. This implies that the end-user has
no management or control over the service’s security. This model is often used in high-security
environments, such as the military or government, to ensure tight control over access. MAC governs
access in a system based on classifying subjects and objects [
In contrast, the Discretionary Access Control (DAC) model assigns access control over objects to their
owners, allowing users to grant or revoke access [
The access control policy known as Originator Control (ORCON ) is positioned between MAC and
DAC, as noted in [
As was previously noted, protecting one’s private information is quite important. Recognising that the material to be provided is sensitive is one of the biggest challenges for a user. A user may be unaware of the various issues, such as privacy violations, arising from the quantity and kind of information revealed. Privacy violations stem from information disclosed in one context seeping into another. Data reduction, or limiting the information sought and received to the bare minimum required, is the advised preventive approach. Global regulations like the General Data Protection Regulation (GDPR)2 and the Health Insurance Portability and Accountability Act (HIPAA)3 define some rules and practices to adopt when dealing with sensitive information.
In verifiable credentials, issuers should adhere to data minimisation by limiting content to what
potential verifiers need. This includes selective disclosure through a signature scheme or the atomisation
of information. An example would be a driver’s license with more information than is necessary to
determine age, such as ID number, height, weight, birth date, and residential address [
One notable privacy risk in SSI revolves around the aggregation of verifiable credentials. Even when information is sourced through distinct channels, possessing two pieces of knowledge about the same subject often unveils more comprehensive insights. Each source may contribute unique perspectives or details that others do not. Comparing these two pieces of knowledge allows a deeper understanding of the subject. In the context of SSI, verifiers may request multiple credentials from users through diferent channels or a single one, and users are compelled to share these credentials to gain access to specific resources. While this practice is commonly employed for security purposes to verify identity and grant access, it raises concerns about potential abuse by verifiers. The risk lies in verifiers acquiring more information than necessary, potentially compromising the user’s sensitive data and enabling the construction of a detailed identity profile.
Managing the actions of third parties with access to personal information presents a complex challenge. Whether it be vendors, partners, or service providers, the potential for data mishandling increases when information is shared outside the immediate control of the data owner. It becomes crucial to establish and enforce stringent contractual agreements, conduct regular audits, and implement secure data-sharing practices to mitigate these risks. Nevertheless, the dynamic nature of digital ecosystems makes it inherently dificult to monitor and control every action performed by third parties.
Blockchain technology, known for its decentralised and tamper-resistant nature, can improve traceability and security in access control systems. It creates an immutable ledger of access permissions and data transactions using smart contracts, ensuring transparency and accountability. This reduces reliance on a single point of control, making it harder for malicious actors to compromise. Blockchain is a trusted custodian, ensuring credentials are used according to established arrangements and protecting the ecosystem from threats.
Integrating an access management system in a decentralised system like SSI proves advantageous for both issuers and holders when interacting with the verifiers. Specifically, implementing a smart contract containing an access policy enables any verifier to authenticate the access requirements for information held by the holder. This ensures robust control against unauthorised access and fosters transparency in the administration of access policies.
It should be emphasised that when a holder’s information is shared with a third party, managing and monitoring how it will be used becomes complex. In this case, we move from management within
an IT context to management within a legislative context. For instance, the termsOfUse property in verifiable credentials provides information about the conditions under which a verifiable credential or presentation was issued. The issuer incorporates their terms into the VC, while the holder includes theirs in a VP. It outlines required, prohibited, or permitted actions necessary for acceptance. This feature is expected to be applied in government-issued credentials, guiding digital wallets to restrict usage to similar entities to protect citizens from unexpected data usage. Also, private industry-issued credentials may limit their use to specific departments or business hours.
Listing 1: Example of termsOfUse property [
} ]
In Listing 1, the verifier (“https://wineonline.example.org”), who is also the assignee (row 7 of Listing 1), is prohibited from utilising the information supplied to correlate the holder (the assigned) via a thirdparty service. The terms under which the holder generated the presentation would be broken if the verifier uses a third-party service for correlation.
As anticipated, the idea is to create an SSI system with an ORCON-type Access Control model to track
access to a given holder’s VCs. In particular, we assume that the creator of the holder’s VCs, i.e. the
issuer, is also the creator of the access policy. Such a system could be applied in specific contexts, such
as a corporate or military context [
According to our concept, it is feasible to confirm that the credentials are being used appropriately since the issuer generates and applies an Smart Policy (SP), also called a Disclosure Policy, to the holder’s credentials. A Disclosure Policy (DP) is a smart contract that includes an access policy designed to regulate VCs’ disclosure. Although the holder fully owns the credentials, implementing a policy ideally aims to limit and trace their use. This is due to the potential risk of the holder sharing their information with unauthorised verifiers, which would violate the issuer’s policy. Moreover, in our proposal, the verifier’s attributes are verified between the holder and the DP. The DP is responsible for checking attributes and maintaining an updated list of verifiers who can access the holder’s credentials. The holder is responsible for requesting the credential from the verifier and verifying its validity, i.e., expired/revoked credentials or invalid signatures. This creates a separation of duties among system components, particularly useful in organisations for maintaining administrative control and preventing security compromises.
Figure 2 summarises the workflow of our proposal. The DP limits and monitors their access by saving information such as the name or date of access. Therefore, the DP can be defined as a credential data access log registry where an Log List (LL) is used to save the verifier’s public information. The LL is a hash table that stores data as key-value pairs, where the key is the verifier Ethereum address, and the value is a structure of diferent types of information. It is intended as a list showing the last access attempt made by a given verifier and is part of the DP smart contract. In this instance, when a verifier performs attribute checks, their information and results are overwritten. In this case, Solidity events can be employed to check the access history of a verifier. The issuance of events is contingent upon the verification of attributes. Events represent an abstraction of Ethereum’s logging and event-watching protocol. This makes it straightforward to retrieve the history of the results of the attribute check. All transactions related to a verifier’s attributes can be easily located in this manner. However, the LL structure can also be represented as an array containing the verifier information. In Paragraph 3.1, a comparison is presented in terms of execution costs of the DP methods based on diferent LL structures. Table 1 provides an illustrative example of an LL record. A record comprises a verifier’s DID, the name of the holder’s VC where the DP is applied, the timestamp related to the time of the access attempt and the verification result.
One potential development of the DP is incorporating a time control referencing the most recent positive verification by a specific verifier. The time control entails verifying whether the verifier’s attribute check was successful and the time elapsed since the verification was done. This approach enables the establishment of a temporal limit within which a verifier may access the holder’s information, after which it is deemed unauthorised access. This approach could be beneficial in the context of medical prescriptions with a short expiry date. In such instances, the verifier (i.e. doctor or pharmacist) could not access a user’s expired prescription.
A local blockchain, namely Ganache, was employed as a test environment. Ganache is a personal blockchain that ofers a secure environment for developing, deploying, and testing distributed applications for Filecoin and Ethereum. The Ethereum accounts created by Ganache were utilised when the workspace was established. In particular, three accounts were required for the three entities in our system: issuer, holder, and verifier. Each entity was assigned a DID and its public and private keys. The resolution of the DID necessitates the retrieval of the on-chain information stored in a DID Registry. In order to interact with the smart contract, we opted for the web3.js4 library, which is a collection of modules that contain functionality for the ethereum ecosystem.
The issuer is responsible for creating and deploying the disclosure policy, which includes functions
for controlling attributes and saving information. Furthermore, the disclosure policy is capable of
performing attribute checks. Information designated as public, which is defined as the DID of the
verifier and their Ethereum account, is presumed to be non-sensitive and, therefore, can be made public.
In our case, the verifier’s attributes considered for control are non-sensitive information, such as the
company name or country of origin. This is because information becomes public when a call is made
and a transaction occurs with the DP. Therefore, concerns may arise regarding the privacy of private or
sensitive information due to the transparency feature of blockchain. [
Key address 0x6· · · 3491 0x6· · · 7942
Following the workflow depicted in Figure 2, let us consider the scenario in which the holder requests a service from a verifier. The verifier, in turn, requests access to the holder’s information in order to provide the service. The holder is aware of the DP applied to his or her work-related VCs, and thus requests the attributes that are required for the verification process. The verifier then prepares a VP containing the requested information and sends it to the holder, who verifies the validity and calls the function to check the attributes with the required parameters as shown in Table 1. The verifier information is stored in the LL for successful and unsuccessful verifications. It is the responsibility of the issuer and the holder to ensure that company-related information is only submitted to an authorised verifier and that the holder’s VC is delivered in compliance with the issuer’s requirements. If the holder provides their information to an unauthorised verifier, the verifier will unlawfully own material to which they were not permitted access. This will result in the absence of any transactions being recorded in the DP history or any records being kept in the LL.
The Disclosure Policy is written in Solidity5 and is composed of the following functions: • evaluate_attributes(): This function evaluates the attributes needed for the holder’s VC access.
It receives the attributes to be verified from the verifier’s VP. Then, the function saves it in the LL along with relevant information such as the verifier’s DID, the name of the credential held by the holder and the verification result (either positive or negative). The verifier address is associated with all relevant information by the LL, including the details above and a timestamp indicating the time of the transaction. • check_LL(): this function allows to check whether a particular verifier has already performed an attribute verification. It takes an account as input, checks its presence in the LL, and returns the associated values. • add_LL(): This function is a private function called by the evaluate function and adds the record to the LL, as shown in Table 1. It takes as input parameters the attribute to check and all the necessary information required for storage. • isAdressListed(): This function allows anyone to check if a user is in the access list by providing their address. It returns a boolean value indicating whether or not they’re in the access list. • Time_call(): This function returns the current timestamp (block’s timestamp).
Execution costs. In considering the costs associated with the functions, we have considered the functions evaluate_attributes and check_LL. Given that the function check_LL does not alter the state of the contract, it could be executed without incurring any costs. However, we have also considered the possibility of maintaining a record of who has read the LL via the transactions made and have therefore calculated the cost of this latter possibility. Given the earlier considerations, we calculated the function call cost as GasUsed × GasPrice. The gas price is determined based on the cost of gas units in Gwei, which is equivalent to one gas unit equal to 15.49 Gwei in April 20246. The gas used for a transaction is retrieved by Table 2, which shows the cost of performing each function. It shows the cost in gas units and the corresponding value in Gwei, also calculated in Ether.
Function evaluate_attributes check_LL
Gas Used 232262 42092
About the data structure employed for the LL, it is also possible to use an array. This stores not only the most recent access attempt made by a verifier but also the entirety of the access history for the VC. Consequently, in this instance, it would be unnecessary to utilise events to ascertain the access history of a verifier. The primary distinction is the cost of executing the functions. Indeed, we found that the function check_LL exhibited a higher cost in their execution. The iteration cost of the search function probably causes this. Table 3 shows the respective costs of functions performed on the local environment.
Function evaluate_attributes check_LL
Gas Used 229148 68858
To better understand the application scenarios of our proposal, we report an example related to bank
accounts. Firms are addressing the financial crime business by extending their Know Your Customer
(KYC) initiatives. The KYC strategy is a collection of standards financial institutions and enterprises use
to assess the identity, suitability, and risks of present or future clients to detect suspect conduct such
as money laundering and financial terrorism before it occurs [
In this section, we are going to mention some related works. In particular, the AC model approach
with an ABAC methodology applied in an Ethereum blockchain was defined in Maesa et al. paper [
Karthikeyan’s master thesis [
The paper by Belchior et al. [
Wu et al. [
In this paper, we studied several SSI authentication and authorisation problems and a potential AC control solution for monitoring holder’s VC access. During our discussion, we identified various problems with the communication between the verifier and the holder in SSI. These issues, such as potential security risks, can significantly afect the overall system. To address these concerns, we explored access control techniques that can be applied to SSI for traceability. The issuer, also known as the policy originator, can control the authorised access to the holder’s VC. If the holder sends credentials to unauthorised users, this can be verified by checking for a transaction to the DP and the record in the LL.
This section also looks into future developments that might be included in the model. A ZKP may be implemented in the attributes sharing from the holder to the DP, as previously mentioned in Section 4. Instead of receiving unencrypted data, the policy receives proof that the verifier possesses particular attributes. Our model does not handle this option, which might benefit verifier/holder and DP/holder communications.
Furthermore, it is proposed that specific negotiating strategies may be applied in the holder-verifier exchange. Following a positive policy verification, negotiation can also be employed in an AC model that has been proposed. Negotiation techniques can assist both parties in reaching a mutually beneficial agreement on the terms of access control. By engaging in negotiation after policy verification has been successful, the holder and verifier can ensure that the credentials shared are appropriate and suficient for the requested access level.
Another interesting aspect to study is the problem of inference. Inference is the unintentional disclosure of sensitive information from non-sensitive information. To illustrate, consider a scenario in which a verifier asks two questions: whether the holder is over 18 and then whether they are under 20 years old. If the holder responds positively to both questions, the verifier may assume that the holder is 19 years old, even if a ZKP is employed. The sensitivity of the information, particularly when combined, and the extent to which a verifier can infer from it, should be analysed.
The authors are members of the Gruppo Nazionale Calcolo Scientifico-Istituto Nazionale di Alta Matematica (GNCS-INdAM) and Consorzio Cini. This work has been partially supported by: • GNCS-INdAM, CUP_E53C22001930001 and CUP_E53C23001670001; • European Union - Next Generation EU PNRR MUR PRIN - Project J53D23007220006 EPICA: “Empowering Public Interest Communication with Argumentation”; • University of Perugia - Fondo Ricerca di Ateneo (2020, 2021, 2022) - Projects
BLOCKCHAIN4FOODCHAIN, FICO, AIDMIX, “Civil Safety and Security for Society”; • European Union - Next Generation EU NRRP-MUR - Project J97G22000170005 VITALITY: “Innovation, digitalisation and sustainability for the difused economy in Central Italy”; • Piano di Sviluppo e Coesione del Ministero della Salute 2014-2020 - Project I83C22001350001 LIFE: “the itaLian system Wide Frailty nEtwork” (Linea di azione 2.1 “Creazione di una rete nazionale per le malattie ad alto impatto” - Traiettoria 2 “E-Health, diagnostica avanzata, medical devices e mini invasività”); • project “SERICS” (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union - NextGenerationEU; • PNRR project “Advanced and Quantum-safe Solutions for Digital Identity and digital Tracing (AQuSDIT)”.