In this work, we study the problem of producing a delegation of verifiable presentations derived from verifiable credentials to enable a credential holder (the delegator) to securely authorize another party (the delegatee) to present a credential on their behalf. We define the notion of a verifiable presentation delegation scheme , with the core algorithms for delegation issuance, delegated presentation, and presentation verification, and formalize the security properties that such a scheme must satisfy, namely correctness and unforgeability. Then, we design a verifiable presentation delegation scheme that can be applied to the verifiable credentials used in the European Digital Identity Wallet Architecture Reference Framework (EUDI ARF) and we prove that our scheme satisfies the security properties under the assumption of a secure digital signature scheme. Finally, we briefly discuss and provide some insight on how to instantiate our scheme in the context of the European Blockchain Services Infrastructure (EBSI) and EUDI frameworks.
The eIDAS 2.0 regulation [
disclose a subset of the attributes included in a credential. This operation minimizes the amount of data
shared with third parties, in accordance with the privacy principles required by the GDPR [
An important extension of VC schemes that would improve their usability is the ability to support delegation of VPs. In this context, a credential holder (the delegator), using its VC, can create a delegation that instructs another holder (the delegatee) to act on its behalf to execute a specific and predetermined operation while interacting with a verifier. VP delegation is developed as a mechanism allowing one to cover use cases such as: someone authorizes a family member to pick up a prescription from the pharmacy, an elderly person authorizes their adult child to represent them in a public online service, or a person delegates an intermediary to perform financial operations on its behalf.
For simplicity in this work, we consider a system in which every user is provided a “main credential”, like an ID card, by a trusted issuer that every holder can use to delegate other holders. Our definition of a VP delegation scheme builds on top of such a VC scheme. In particular, we describe a delegation mechanism that allows a delegator to generate delegations that must specify: • the scope for which the delegation is being created. This might include a period of validity, an identifier of the verifier to which it must be presented, and an identifier of the operation that the delegatee must perform; • the delegatee identifier , a statement that the identity (or the VC) of the delegatee must satisfy. For example, the delegatee identifier could be “the delegatee is over 18”, then any over 18 holder would be allowed to present such delegation, or more specific statements such as “the delegatee name is Name and their surname is Surname”, in such a case only a holder named Name Surname would be allowed to present such delegation. This identifier is sent by the delegatee to the delegator before the latter produces the delegation; • the delegator payload, a statement about the delegator’s identity that contains (at least) the information the verifier would request from any holder to perform the operation specified in the scope; • a proof that the delegator identity (or VC) satisfies the delegator payload.
The delegatee, with the delegation, interacts with the verifier to present the delegation and to execute the operations specified in the scope. The delegatee proves to be an authorized delegatee by showing, using its own VC, that it satisfies the delegatee identifier information specified in the delegation. Finally, the verifier checks that the delegation and the presentation of the delegation are valid and accepts (or rejects) the delegated presentation, allowing the delegatee to perform (or preventing the delegatee from performing) the operation specified in the scope.
has gained significant importance. This is confirmed by its inclusion in the EUDI Wallet Reference Implementation Roadmap 1. In fact, EU citizens will soon be issued verifiable credentials that will be used to securely prove statements about their identity. In addition to that, VCs can be used to enhance the security of how users delegate specific, predetermined tasks to others, providing a more secure alternative to the paper-based methods too often used today.
A related problem, which has received significantly more attention in the literature, is the delegation
of the issuance of anonymous credentials while concealing the delegation chain and revealing only
the root issuer. This problem was firstly approached by Chase and Lysyanskaya [
the ID cards to their citizens. With these credentials, the citizens can prove to verifiers to be European citizens without revealing the authority who issued their credential, and therefore their country.
the privacy-preserving features) using standard digital signature schemes by instructing the issuer to sign the public key of its delegatee, as is well explained in [12, Section 1].
applications from the delegation of VCs. In both cases the delegatee takes charge of carrying out operations on behalf of the delegator: for what concerns the delegation of VCs, such an operation is the issuance of VCs to users, and in our case such an operation is the showing of VPs to verifiers.
and for this reason, we fill this gap laying the ground to formalize the notion of VP delegation scheme.
Let denote the security parameter. The issuer’s private and public keys are denoted as skIss and pkIss, respectively. The set of messages or attributes is denoted by a = ()∈[], where [] represents the set {1, . . . , }. When presenting a VC supporting selective disclosure, a subset of attributes, whose indices are denoted by Hid, can be hidden, while the set of indices of the disclosed attributes is Rev = [] ∖ Hid. We denote by stmt the set of revealed attributes, and with the set of possible statements. The delegator, delegatee, and verifier are indicated by , Δ, and , respectively. Each party is provided with a single VC. The delegator’s credential is represented as credD, and the delegatee’s credential is denoted as credΔ. The delegatee identifier is indicated by ΔID, the delegator payload is denoted as DP, while the delegation scope is referred to as scope. In the security definitions, we will define the following tables: a credential table CT, a presentation table PT, and a delegation table DT. Finally, we consider a function : N → R to be negligible if, for every > 0, there exists an integer 0 ∈ N such that for all ≥ 0, it holds that () = (1/). This notation will be used throughout the paper to formalize the schemes and algorithms presented.
Definition 1 (Verifiable Credential Scheme) . A verifiable credential scheme is defined by the following algorithms: • Issuer Setup (IssuerSetup( →)− $ pp, (skIss, pkIss)): this algorithm is executed by the issuer, and it generates the public parameters pp for the verifiable credential scheme together with the issuer key pair. • Credential Issuance (CredIssuance(skIss, {}∈[]→)− $ cred): The issuer executes this algorithm to generate a verifiable credential cred for the attributes {}∈[]. • Credential Presentation (CredPresentation(cred, stmt→)− $ pres): This algorithm is executed by the holder to generate a proof (the presentation pres) that it possesses a credential cred that satisfies a statement stmt2.
necessary to prove stmt. • Presentation Verification (PresVer(pres, stmt→)− ${ 0, 1}3): The verifier executes this algorithm to verify the validity of the presentation provided by the holder, ensuring that it satisfies stmt.
described in [
, sample a random sa l−t{← $ 0, 1} and compute com = (||salt). To open a commitment com, it is necessary to reveal the message-salt pair (||salt), and the verifier can check if com = (||salt). The digital signature scheme can be any UF-CMA secure digital signature scheme 4.
described. Even pkIss is omitted, since we assume for simplicity that there is only one issuer in the system.
Definition 2 (ARF-Compliant Verifiable Credentials) . Let = (Setup, KeyGen, Sign, Vf) be a digital signature scheme and a cryptographic hash function. The verifiable credentials which are ARF-Compliant can be described as follows: • Credential issuance: cred− ← $ CredIssuance({}∈[], skIss)
The issuer executes the following operations: • Issuer setup: pp, (skIss, pkIss− ) ← $ IssuerSetup( )
The issuer executes the issuer setup algorithm which consists in executing the Setup and KeyGen algorithms of the underlying digital signature scheme .
– sample uniformly at random salts salt1, . . . , sal t−{← $ – compute com ← (||salt) ∀ ∈ []; 0, 1} ; − ← $ Sign(({com}∈[], pkcred), skIss); – set cred ← ((, {com}∈[], pkcred), {}∈[], {salt}∈[], skcred)5. – generate (skcred, pkcred− ) ← $ KeyGen(pp); – sign the commitments and the public key of the credential ({com}∈[], pkcred) computing • Credential presentation: pre− s ← $ CredPresentation(cred, stmt, nonce)
The statement stmt = {}∈Rev is given by the set of attributes that the holder wants to reveal Rev ⊆ [], and the nonce nonce is sent by the verifier to the holder to guarantee the freshness of the presentation. The holder performs the following operations: – compute pres′ ← ((, {com}∈[], pkcred), {salt}∈Rev, {}∈Rev, nonce); – sign pres′ computing − ′ ← $ Sign(pres′, skcred); – set pres ← (pres′, ′). • Presentation Verification : {0, 1−} ← $ PresVer(pres, stmt)
The verifier performs the following operations: – parse pres → (pres′, ′) and then pres′ → ((, {com}∈[], pkcred), {salt}∈Rev, {}∈Rev); – verify the signature of the issuer: 1 ← Vf(, ({com}∈[], pkcred), pkIss); – check that com = (||salt), ∀ ∈ Rev; – verify the signature of the holder: 1 ← Vf( ′, pres′, pkcred).
If the previous checks are satisfied, the verifier accepts and outputs 1, otherwise it outputs 0. 3In this context, 1 = success, indicating that the presentation satisfies the statement, while 0 = fail, indicating it does not.
5To ensure a secure binding between a credential and the device storing it, the secret key of the credential (skcred) is stored within a hardware security module (HSM) or a trusted execution environment (TEE) embedded in the device.
according to Definition 1. A VP delegation scheme must define the algorithms (1) to allow the delegator
to a verifier generating a presentation pres and (4) to verify the delegated presentation pres.
Definition 3 (VP delegation scheme). A VP delegation scheme is defined by the the following algorithms: • Delegation issuance: DelegIssuance(credD, DP, scope, ΔID→)− $ (ΔID, scope, DP, DP) where: ⏟ del⏞ – DP is the delegator payload containing the information that the delegator must disclose about its identity (e.g. it is entitled to withdraw a specific drug); – scope is the delegation scope, describing the operation that can be performed by the delegatee interacting with specified verifiers 6; – ΔID is the delegatee identity which is a statement that must be satisfied by the delegatee presenting del (and its credential); – DP is a proof that the holder knows a credential credD for the claims in DP. The proof must be bound to scope and ΔID.
See Section 1.1 for a better intuition about the semantic meaning of these fields. • Delegation verification : DelegVer(del→)− ${ 0, 1}
This algorithm is executed by a delegatee (or by a verifier) to verify the validity of the delegation. • Delegated presentation: DelegPres(del, credΔ, nonce→)− $ (del, del) ⏟ pre⏞s The delegator contacts the verifier to which it wants to present the delegation. The verifier sends to the delegatee a random nonce which is used to guarantee the freshness of the delegated presentation. After parsing del as (ΔID, scope, DP, DP), the delegatee computes del which is a proof of knowledge of a credential credΔ satisfying the delegatee identity ΔID included in del. • Delegated presentation verification : DelegPresVer(pres→)− ${ 0, 1}
This is the verification algorithm executed by the verifier. Parse pres as (del, del). Upon receiving the proof del and the delegation del, the verifier checks that – DelegVer(del) → 1; – del is a valid proof for the value ΔID in del; – scope included in del, which is part of pres, is satisfied.
If these checks pass, the delegated presentation is accepted, and the algorithm outputs 1.
Correctness Property. The correctness property specifies that a delegation algorithm always allows a honest delegator (who generates a delegation for a DP consistent with its identity), to generate a delegation del and delegate another user. Then, if the user is a honest delegatee (its identity satisfies ΔID) it can always present del to a verifier satisfying scope.
presentations to verify it. A more detailed analysis of this aspect is out of scope and will be treated in a future work. Interaction framework among Delegator, Delegatee, and Verifier Delegator D(credD)
Delegatee ∆( cred∆ ) ∆ ID ∈ S
Verifier V ∆ ID del ← DelegIssuance(credD, DP, scope, ∆ ID) del nonce
nonce ←−$ {0, 1}λ pres ← DelegPres(del, cred∆ , nonce) pres
DelegPresVer(pres) −→$ {0, 1}
= (DelegIssuance, DelegVer, DelegPres, DelegPresVer), we say that the scheme is correct if DelegPresVer(pres) → 1 whenever: • de− l ← $ DelegIssuance(credD, DP, scope, ΔID) where credD satisfies the statements contained in
DP (which is contained in del); • pre− s ← $ DelegPres(del, credΔ, nonce), where credΔ satisfies the statements contained in ΔID.
delegation algorithm DelegIssuance, which means that an adversary cannot forge a delegation from a credential it does not possess, and the unforgeability of the delegation presentation algorithm DelegPres, which means that an adversary cannot present a delegation that is not issued to its identity (i.e., its identity does not satisfy ΔID). We capture these two notions of unforgeability in a single experiment.
The experiment captures that an adversary , after receiving the public key of the issuer pkIss, the public parameters pp, and performing a training, cannot forge a delegation presentation. The training considers an adversary that can learn information from the system in the following ways: it can (1) corrupt a polynomial number of users, (2) receive a polynomial number of delegations from users it does not control, and (3) verify a polynomial number of delegated presentations (i.e., receive a polynomial number of presentations of its choice). These operations are modeled by allowing to query a polynomial number of credentials to the oracle Oiss, of delegations to the oracle Odel and of presentations of delegations to the oracle Opres.
gated presentations, but also presentations of verifiable credentials (generated using the algorithm
assume that credentials presentations can be seen as delegated presentations associated to an empty delegation (del, nonce) = (⊥, ⊥).
Experiment 1 (ExpDelPresUnforgeability(1 )). The experiment is given by the following phases.
Setup phase receives from the challenger of the experiment the public key pkIss of the issuer and the public parameters pp of the underlying VC scheme. Training phase can interact with random oracles Oiss, Odel and Opres, to which it can send a polynomial number of issuing queries, delegation queries, and delegated presentation queries, respectively. Each query has the following input-output specification: 1. Issuing queries to Oiss: can query for the issuance of a credential for a set of attributes {}∈[] of its choice; the oracle computes a credential cred ← CredIssuance({}∈[], skIss), adds cred to the credential table CT and sends it to . 2. Delegation queries to Odel: can query Odel for the issuance of a delegation for (ΔID, scope, DP) of its choice; the oracle computes a delegation del ← (ΔID, scope, DP, DP), stores del in a delegation table DT and sends it to . 3. Delegated presentation queries to Opres: can query for the presentation of a delegation for the values (del, nonce); the oracle Opres generates a presentation pres for (del, nonce), adds pres to a presentation table PT and sends it to .
Forgery phase eventually outputs a delegated presentation pres⋆ = (del⋆, del⋆ ). Winning conditions Parse pres⋆ = (del⋆, del⋆ ) as (ΔID⋆, scope⋆, DP⋆, DP⋆ , del⋆ ).
The adversary wins the experiment if DelegPresVer(pres⋆) → 1 and one of the following conditions is satisfied: • forgery of the delegation: del⋆ is forged, i.e.
– it is not a delegation queried by to Odel, i.e. del⋆ ̸∈ DT; – del⋆ was not generated using the credentials issued to . • forgery of the delegated presentation: del⋆ is forged, i.e.
– ∀pres ∈ PT, pres ̸= pres⋆; – del⋆ was not generated using the credentials issued to .
Definition 5 (Unforgeability of VP delegation scheme). We say that a VP delegation scheme is unforgeable if for any PPT adversary executing ExpDelPresUnforgeability(1 ),
Pr[︁ wins ExpDelPresUnforgeability(1 )]︁ ≤ ( ),
where ( ) is negligible in the security parameter .
In this security model, we assume that every interaction between holders/delegatees and verifiers is identified by a unique session identifier. This prevents an adversary from replaying messages exchanged during diferent sessions. When the protocol is instantiated, the protocol designer must take care of issues related to the creation of the communication sessions between the parties involved. To test the security of the approach used, it is advised to use automated tools like Tamarin or ProVerif; nonetheless, addressing this issue is beyond the scope of this paper.
verifiable credential schemes supporting selective disclosure which are compliant with the EUDIW ARF
[
Definition 6 (ARF-Compliant VP Delegation Scheme). Given a verifiable credential scheme as defined in Definition 2, which uses the digital signature scheme and the hash function , we can define the following delegation scheme (see Definition 3). • Delegation issuance: DelegIssuance(credD, DP, scope, ΔID→)− $ (ΔID, scope, DP, DP) ⏟ del⏞ On input (credD, DP, scope, ΔID) with credD = (︀ (, {com}∈[], pkcredD ), {}∈[], {salt}∈[], skcredD ︀) , the delegator D computes DP as a variant of a presentation of credD which is bound to DP but also to scope and ΔID: – pres′ ←
((, {com}∈[], pkcredD ), {salt}∈DP, DP, scope, ΔID); – − ′ ← $ Sign(pres′, skcredD ) and DP ← (pres′, ′); – return del ← ((ΔID, scope, DP, DP)). • Delegation verification : DelegVer(del→)− ${ 0, 1}
To verify the delegation, parse:
del → (ΔID, scope, DP, DP), DP → (pres′, ′), pres′ → ((, {com}∈[], pkcredD ), {salt}∈DP, DP, scope, ΔID).
Then, perform the following checks: – Verify the signature of the issuer: 1− ← ? Vf(, ({com}∈[], pkcredD ), pkIss). This means that the delegation is created from a valid VC issued by pkIss; – Check that com = (||salt), ∀ ∈ DP. This means that the delegation has a DP consistent with the credential used to generate it; – verify the signature ′ of pres′ using the public key pkcredD : −1 ← ? Vf( ′, pres′, pkcredD ). This means that the delegation (for scope and ΔID) was created by the holder of the associated credential. • Delegated presentation: DelegPres(del, credΔ, nonce→)− $ (del, del) ⏟ pre⏞s After parsing del → (ΔID, scope, DP, DP), the delegatee computes del as a presentation of ΔID using credΔ which is bound to del: – compute pres′′ ←
((, {com}∈[], pkcredΔ ), {salt}∈ΔID , del, nonce); – the delegatee signs pres′′ computing −′′ ← $ Sign(pres′′, skcredΔ ), sets del ←
returns pres ← (del, del). • Delegated presentation verification : DelegPresVer(pres→)− ${ 0, 1}
Parse pres → (del, del), where del → (pres′′, ′′) ((, {com}∈[], pkcredΔ ), {salt}∈ΔID ), del, nonce). The verifier checks that (pres′′, ′′) and and pres′′ → – the delegation is valid, i.e. DelegVer(del) → 1; – del is a valid presentation of credΔ for the attributes in ΔID specified in del, i.e.: 1. the signature ′′ of pres′′ is valid using pkcredΔ : 1 ← 2. com = (||salt) ∀ ∈ ΔID; 3. the signature of the issuer is valid: 1 ←
Vf(, ({com}∈[], pkcredΔ ), pkIss).
Vf( ′′, pres′′, pkcredΔ ); – the value scope included in del is satisfied according to the associated verification procedure.
If these checks pass, the delegated presentation is accepted, and the algorithm outputs 1.
Theorem 1. The delegation scheme described in Definition 6 instantiated using the digital signature is correct, assuming that the digital signature is correct and that is modeled as a random oracle.
proof DP to include in del, and since the digital signature is correct del is a valid delegation. Then, if the delegation is presented by a delegatee whose identity matches with the identity ΔID included in del, the delegatee can always successfully present the delegation, again because is correct.
In the security proof of the unforgeability, we must introduce a technicality which simplifies the description of our reduction. In particular, we show that the adversary to the unforgeability of the VP delegation scheme can be used to build a reduction to a variant of the unforgeability under chosen message attacks (UF-CMA) of the digital signature . In this variant, which we refer to as v-UF-CMA, the reduction can open a polynomial number of sessions of standard UF-CMA experiments (each associated with a diferent public key with the same public parameters pp), and the reduction wins the v-UF-CMA experiment if it produces a forgery for at least one of the public keys it is provided by the challenger of the experiment. Informally, the queries that the adversary can make are queries for the opening of a new session , for which it receives a public key pk, and signing queries specifying a message and one of the public keys it has previously received (, pk ), for which it receives a valid signature of under the public key pk .
of the v-UF-CMA experiment, and the success probability remains the same. However, it is also easy to see that an adversary of v-UF-CMA of can be used as a subroutine for a reduction to the UF-CMA of with a loss in the probability of success proportional to the number of sessions the adversary of v-UF-CMA can open. 6.2.1. Unforgeability Proof Theorem 2. The delegation scheme described in Definition 6 is unforgeable according to Definition 5 assuming that the digital signature is (v-UF-CMA) unforgeable, that is modeled as a random oracle and that the commitment scheme is binding.
oracle is programmed. Moreover, since we prove the security in the random oracle model and the commitment is binding 7, the adversary cannot open a commitment to two diferent values because this would imply that it has found a collision, which happens with negligible probability. Proof Sketch. We prove that if there exists an adversary of Experiment 1 who can win the experiment with non-negligible probability, then we can use to build a reduction ℬ to the v-UF-CMA experiment of the underlying digital signature scheme , which wins the experiment with non-negligible probability. The reduction ℬ interacts with the challenger of the v-UF-CMA experiment and simulates the challenger of Experiment 1.
Setup ℬ sends a query for a new public key in the v-UF-CMA experiment. sends to ℬ a public key pk and public parameters pp. ℬ sets pkIss ← pk, and forwards (pp, pkIss) to the adversary . Training phase We show how ℬ answers to the queries can send during the training phase. 7The output in bits of the random oracle is suficiently large operations: • Queries to Oiss: sends in input a set of attributes {}∈[]. ℬ performs the following ture of ({com}∈[], pkcred) using skIss.
and adds cred to CT. 1. it generates a key pair (skcred, pkcred), the salts {salt}∈[], computes a commitment com = RO(||salt) (where RO is a random oracle programmed by ℬ) to , ∀ ∈ []; 2. it sends a signing query to with input (({com}∈[], pkcred), pkIss): returns a signa3. sends to the credential cred ←
((, {com}∈[], pkcred), {}∈[], {salt}∈[], skcred)
Upon receiving a query ℬ performs the following operations: • Queries to Odel: can query for a delegation for the values (ΔID, scope, DP) of its choice. adds del to DT.
({com}∈[], pkcred), and receives from the signature ; 1. generates a set of random attributes {}∈[] which satisfies DP and computes the commitments com as before generating the salts and programming the random oracle; 2. opens a new session with of UF-CMA with from which it receives a public key pkcred and sends a signing query (({com}∈[], pkcred), pkIss) for a signature with skIss of 3. sends a signing query (pres′, pkcred) to for a signature with skcred of pres′ = ((, {com}∈[], pkcred), {salt}∈DP, DP, scope, ΔID). returns the signature ′; 4. ℬ sets DP = ( ′, pres′) sends to the delegation del = (ΔID, scope, DP, DP) and its choice. Upon receiving a query ℬ performs the following operations: • Queries to Opres: can query for a delegated presentation giving in input (del, nonce) of 1. ℬ generates a credential with the help of as it is done for queries to Odel up to Item 2, but instead of choosing the attributes that satisfy DP, they satisfy ΔID included in del received in input. The credential is associated to the public key pkcred, whose secret counterpart is not known to ℬ; 3. ℬ sends pres = (del, ( ′′, pres′′), nonce) to and stores pres in PT.
((, {com}∈[], pkcred), {salt}∈ΔID , del, nonce) using skcred. returns ′′. (pres′′, pkcred) to for a signature of pres′′ = = ︂) and ΔID⋆ :
︂( used in the generation of the forgery.
Note that ℬ knows only the secret keys associated to the credential issued to that can not be Forgery Phase sends to ℬ a delegated presentation pres⋆ = (del⋆, del⋆ ) as its forgery.
Instantiation and analysis of the winning condition of Experiment 1
winning condition of Experiment 1, and we rewrite it considering the experiment instantiated with the
The adversary’s output is a
presentation (ΔID⋆, scope⋆, DP⋆, DP⋆ ). We recall the structure of the proofs DP⋆ and del⋆ . pres⋆ = (del⋆, del⋆ ), with del⋆ 1. DP⋆ is a presentation of a credential for the attributes specified in DP⋆ containing also scope⋆ DP⋆ = ′ = Sign(pres′, skcredD ), ((, {com}∈[], pkcredD ), {salt}∈DP⋆ , DP⋆, scope⋆, ΔID⋆) , ⏟ pres⏞′ of ({com}∈[], pkcredD ) (part of credD) using skIss. with ′ being the signature of pres′ using the secret key associated to pkcredD and is the signature 2. d⋆el is a presentation of a credential credΔ for the attributes in ΔID bounded to del⋆ and nonce⋆, del⋆ = ′′ = Sign(pres′′, skcredΔ ), ((, {com}∈[], pkcredΔ ), {salt}∈ΔID⋆ , del⋆, nonce⋆) ︂) ⏟ pres⏞′′ signature of ({com}∈[], pkcredΔ ) (part of credΔ) using skIss.
with ′′ being the signature of pres′′ using the secret key associated to pkcredΔ and is the
Remark 1. The challenger of the unforgeability experiment (Experiment 1) generates public keys pkcred and signs them (together with a set of commitments {com}∈[]) using skIss as a consequence of: 1. issuing queries: in this case, the challenger also gives to the adversary the associated secret key and adds the credential to CT; does not reveal skcred to the adversary. 2. delegation queries (delegated presentation queries): in this case, the issuer also signs pres′ in DP (pres′′ in del) using the secret key skcred associated to pkcred, adds the delegation to DT (PT), and Note that the challenger of Experiment 1 never signs public keys it has not generated 8 The adversary wins the experiment if DelegPresVer(pres⋆) → 1 and one of the following conditions • forgery of the delegation: del⋆ is forged, i.e.
– it is not a delegation queried by to Odel, i.e. del⋆ ̸∈ DT; – del⋆ was not generated using the credentials issued to . signature of ({com}∈[], pkcredD ) must be a forgery of pkIss.
If it is generated by the challenger, since the delegation Remark 2. The public key pkcredD in del⋆ has been generated either by the challenger or by . del⋆ does not correspond to any credential issued to , then does not know the secret counterpart skcredD . Also, since del⋆
̸∈ 9 ((, {com}∈[], pkcredD ), {salt}∈DP⋆ , DP⋆, scope⋆, ΔID⋆), therefore ′, included in DP⋆ , is a forgery of pkcredD . If pkcredD
is generated by (who would know the value skcredD ), then the DT, the challenger has never signed with skcredD the message • forgery of the delegated presentation: del⋆ is forged, i.e.
– it is not a presentation queried by , i.e. pres⋆ ̸∈ PT; – del⋆ was not generated using the credentials issued to .
Remark 3. The public key pkcredΔ is created either by the challenger or by . If it is created by the challenger, does not know the associated secret key since del⋆ is not generated using a credential issued to . But also pres⋆ ̸∈ PT, therefore it means that the issuer has never signed the message ((, {com}∈[], pkcredΔ ), {salt}∈ΔID⋆ , del⋆, nonce⋆), therefore ′′ (in del⋆ ) is a forgery of pkcredΔ . If pkcredΔ is generated by , then ({com}∈[], pkcredΔ ) must be a forgery of pkIss. experiment, and this concludes the security proof.
This means that at least one of the public keys that ℬ has received by , corresponding to the sessions opened in the v-UF-CMA experiment, has been forged. Therefore, ℬ would also win the v-UF-CMA 8For the sake of clarity, note that in the security proof, the challenger of Experiment 1 is the reduction ℬ . The reduction 9Also does not know the secret key skIss but can ask for signatures of messages of its choice using skIss sending queries to , the challenger of the v-UF-CMA experiment. Again, the public keys pkcred that get signed using skIss have been generated by ℬ.
might be a forgery of pkIss (because the adversary might have changed the set of commitments), but even if it is the case, ′ would be a forgery of pkcredD .
or in the EUDI Wallet context without defining new data structures, only new verification procedures.
The delegation del can be a VC issued by the delegator that has as attributes the components we have described, namely scope, ΔID, DP and DP. The delegator signs this credential (as an issuer) using the same secret key used to generate the DP as specified in Definition 6. This additional signature on the whole delegation is needed for compatibility reasons, because every VC must be signed by the issuer, in this case the delegator. This special credential, which does not require the use of a key pair (pkcred, skcred) to guarantee the binding to the device that receives it, will be fully disclosed by the delegatee when the time comes to present the delegation.
When the delegatee creates a delegated presentation, it presents del (which is structured as a VC) disclosing all its attributes, namely, scope, ΔID, DP and DP; the delegatee then creates a verifiable presentation del using its own VC, revealing the attributes included in ΔID. The outcome of the delegated presentation is derived from the combination of these two presentations. The only modification to the verification protocol is that the verifier must check that DP is indeed a valid presentation of the statement DP and that the presentation del created by the delegatee using creddel is a valid presentation of ΔID.
In EBSI, the only entities entitled to issue credentials are legal persons whose DID (a reference to, at least, their public key) is registered in the Trusted Issuer Registry (TIR)10. This means that credential holders who are physical persons are not allowed to issue credentials and therefore cannot generate the delegation as we have mentioned above. If the delegator is only a physical person we must consider two cases: • the delegatee is a legal person: in this case, the delegator can generate the attributes for the delegation VC scope, ΔID, DP and DP and sends them to the delegatee who generates the VC containing this information and signs it in turn. Note that this signature is only useful to guarantee the compatibility and create a VC issued by an entity registered in the TIR. The delegatee can choose not to sign it, which is perfectly fine, but cannot change the information sent by the delegator because DP is cryptographically bound to scope, ΔID and DP. • if the delegatee is also only a physical person, the delegator must have the delegation VC signed by a third party registered in the TIR, which may be the issuer of the credential used to generate the delegation or a third party with this specific role.
Acknowledgements
scholarship. Andrea Gangemi and Andrea Flamini are supported by the QUBIP project, funded by the European Union under the Horizon Europe framework program [grant agreement no. 101119746].