The BBS# protocol

The BBS# protocol

Technical details

Date: June 2024

Table des matières

Introduction : the context ..................................................................................................................... 5

1. Foundations of the BBS# protocol ........................................................................................... 10
1.1 Cryptographic tools ................................................................................................10
1.1.1 Commitment schemes ............................................................................................... 10
1.1.2 Zero Knowledge Proofs ............................................................................................. 11
1.2 Stakeholders presentation ......................................................................................11
1.2.1 The identity provider ................................................................................................... 12
1.2.2 The service provider / RP .......................................................................................... 12
1.2.3 The users ..................................................................................................................... 12
1.3 Main phases ...........................................................................................................12
1.3.1 VCs issuance............................................................................................................... 12
1.3.2 Access to the RP and VP generation ...................................................................... 12
1.3.3 VP verification ............................................................................................................. 13
2. BBS# and selective disclosure : compliance with the ISO mDL standard ......................... 14
2.1 Cryptographic preliminaries ....................................................................................14
2.1.1 Notations ...................................................................................................................... 14
2.1.2 Bilinear maps ............................................................................................................... 15
2.1.3 Computational hardness assumptions .................................................................... 15
2.1.4 The Pedersen commitment scheme ........................................................................ 15
2.1.5 Issuance of VCs with BBS+: ..................................................................................... 16
2.1.6 Verifiable presentation of a digital identity credential in BBS+ format with selective
attribute disclosure following the ISO mDL standard. ........................................................... 19
3. Security......................................................................................................................................... 28
4. Performances .............................................................................................................................. 31
5. Anonymous credential protocols in a pre-quantum and post-quantum world ................... 32
6. Conclusion ................................................................................................................................... 33
7. References................................................................................................................................... 33

2
 Solving the eIDAS2 conundrum today: BBS style
privacy with SOG-IS based hardware security

Summary
eIDAS 2.0 is a very ambitious regulation aimed at equipping European citizens with a digital
wallet that not only needs to achieve a high level of security but also needs to be available as
soon as possible for a large number of citizens and respect their privacy (as per GDPR). As of
today (June 2024), it does not seem that this goal has been achieved in the European Digital
Identity Architecture and Reference Framework (ARF). This document aims to propose the
foundations of a digital identity wallet solution that could help move closer to this objective by
leveraging the proven anonymous credentials protocol BBS (also known as BBS+) but
modifying it to avoid the limitations that have hindered its widespread adoption, especially in
certified infrastructures requiring hardware implementation. Thus, the solution we propose
does not use bilinear pairings and only requires the implementation in hardware of well-known
digital signature schemes such as ECDSA or ECSDSA (also known as ECSchnorr) using
classical elliptic curves. Additionally, this solution can be implemented while adhering to the
ISO mDL and SD-JWT protocol formats, allowing for its use not only in online contexts but also
in face-to-face/proximity contexts. Furthermore, this protocol retains the well-known anonymity
properties of BBS+, such as unlinkability and everlasting/unconditional privacy. We also
introduce a simple method for plausible deniability for transactions related to services that do
not require audits. We provide various improvements in terms of implementation efficiency (a
single holder binding proof for verifiable presentations containing multiple (Q)EAA) and
security (impossibility for a Wallet Secure Cryptographic Device (WSCD) to generate a proof
without the holder's involvement), as well as a highly efficient new method to prove the non-
revocation of (Q)EAA used in a transaction. We provide formal security and privacy proofs for
our protocol (named BBS#); we believe that BBS# should be deployable quickly on certified
infrastructures such as HSMs or SEs and should also simplify the implementation of eIDAS
services that rely on the ARF. For example, proofs of non-revocation of all kinds can be done
much more simply. Key management can also be greatly simplified, with only a single private
key required on users’ WSCD. We believe that this proposal fully addresses the challenges
posed by the eIDAS 2 regulation by ensuring GDPR's obligation to be state-of-the-art in
personal data protection, while maintaining great deployment flexibility for wide and immediate
availability and a certain ability to be certified quickly.

3
Aim of this document: The objective of this document is to present the technical details of
the BBS# anonymous credentials protocol, a variant of the BBS protocol (currently being
standardized at the IETF), that meets the requirements of the future European digital identity
wallet in terms of security and privacy. To illustrate this, we will focus on one of the main use
cases of this type of digital identity wallet: selective disclosure of attributes. Specifically, we will
show how the BBS# protocol preserves the privacy of digital identity wallet holders by allowing
them to only disclose to third parties (service providers) the information that is strictly
necessary for accessing their services (for example, they can prove that they hold a driver's
license, so that they can access sites reserved for adults, without having to reveal their identity
or date of birth). As we will see, BBS# is also compatible with the ISO/IEC 18013-5 standard
(Mobile driving license application), which is one of the main digital identity management
standards considered in the ARF, but it improves it by offering better privacy protection for
holders of digital identity credentials (following the ISO/IEC 18013-5 format).
While the propositions of this document can be implemented immediately in today's existing
smartphones (we've done it), we reckon that this document does not go into all the details and
does not follow the form that could be expected from, e.g. a peer reviewed document in an
applied crypto conference (which we do intend to do before the end of the year). Given the
ongoing direction taken by the ARF and the associated debates and surrounding initiatives, it
seemed important to us to have the word out as soon as possible and allow people to make
up their mind with the raw material, thus offering alternative options in the design of privacy
preserving eIDAS 2 wallets.

Structure of the document: This technical report is organized as follows. Firstly, we present
the two main identity management models, federated identity and self-sovereign identity, and
the privacy challenges that these models raise. We then recall how the ISO/IEC 18013-5
standard works, which is one of the main standards for managing digital identity credentials,
and why it inadequately protects the privacy of credential holders. The following sections are
dedicated to the BBS# protocol, which aims to address the privacy limitations of the ISO/IEC
18013-5 standard. In Section 1, we present the main building blocks of our cryptographic
protocol (commitment schemes and zero-knowledge proofs) and recall the basic principles of
a self-sovereign identity system (the actors and the main exchanges that can take place
between these actors, such as the issuance of a digital identity credential and its presentation
to a service provider). In Section 2, we describe the functioning of the BBS# protocol (in the
specific case of selective disclosure of attributes). In Section 3, we prove that our protocol is
secure (namely that BBS# credentials are unforgeable) relatively to a well-established
computational assumption (the q-SDH assumption) and demonstrate that presentations of
verifiable credentials, using the BBS# protocol, are perfectly anonymous (everlasting privacy):
for example, in an online survey, it will be impossible for anyone, even with unlimited
computational power, to obtain any information about the individuals who answered to the
survey (and therefore to identify them); the only information revealed will be that these
individuals were part of the chosen panel for the survey and that they answered only once. In
Section 4, we compare the efficiency (in terms of key size and computation time for credential
issuance and presentation) of BBS# with that of ISO mDL/SD-JWT (instantiated with the
ECDSA signature scheme) and PQ-ABC, a recent post-quantum anonymous credential
scheme that will appear at the forthcoming ACM CCS conference. In Section 5, we compare
these three protocols (BBS#, ISO mDL with ECDSA, and PQ-ABC) in terms of the level of
security and privacy they offer. We conclude this report in Section 6.
4
Introduction : the context
Many use cases of daily life (either online or through face-to-face interactions) require that
users provide some of their identity credentials to implement the corresponding business
process. Most of the time, in the physical world, that involves showing some documents issued
by official authorities (id cards, driving licenses, etc…) or by regulated private businesses
(electricity or telecom bills, medical certificates, etc…).

Often, after presenting only the necessary identity elements to access the service, the
credential is returned to the user. By selecting the presented identity elements and retaining
the (physical) credential, the user retains control over their identity elements and manages
their dissemination. The development of services accessible via the internet requires the
implementation of dedicated tools for digitizing the elements present on the aforementioned
physical credentials, potentially in a structured manner, and allowing their sharing with the
service provider after user consent. Major players on the internet have so far structured the
domain of digital identity management in line with their business model. For example, through
the OIDC (OpenID Connect) protocol, they have developed an offer that centralizes the user's
identity data and, under the user’s control, after identification/authentication and user consent,
authorizes the service (called Relying Party) to access all or part of the user's identity data..
One of the main problems with this type of architecture (known as Federated Identity, see
Figure 1) is that the identity provider knows, each time a user consumes one of the services
(Relying Party), when the operation takes place and which identity elements the user shares
with the service provider being accessed. The identity provider is thus able to compile the
history of the user's access activities and the identity elements required by the various services
visited. This data allows them to build a profile of the user's service consumption with service
providers and to use it for often commercial purposes.

Figure 1: Federated identity model

5
Self-Sovereign Identity (SSI) is another approach to digital identity that gives users full control
over their identity elements. Users can present these elements to access a service either to
prove who they are or one of their qualities. Only the service provider and the user interact
during the identity sharing phase. To generate trust between the user and the service, the user
presents identity elements that have been certified by a third party (the identity provider) which
the service provider trusts1. In this logic, the user holds identity elements about themselves
that have been issued and certified2 by one or more trusted entities, controls their
dissemination to service providers (after consent), and protects their privacy from the identity
provider by excluding them from the relationship they have with the service provider. The
protocol is completely asynchronous.

In this digital identity model, an accreditation is a personal attestation allowing its holder to
convince others (such as a service provider) that they have a particular authorization or
qualification. Diplomas, student cards, or driving licenses are examples of traditional
credentials used in everyday life. They are specific to an individual and issued by a trusted
entity (an identity provider) using digital signatures. However, standard digital signature
mechanisms require full disclosure of the signed/certified data, even to prove the authenticity
of only a part of it, and enable users to be traced. Let us take the example of a transport card:
to prove the validity of their card to a verifier (e.g. a turnstile), the user will have to provide all
the certified information associated with their card, including their card identifier, which
unfortunately makes it possible to trace their trips.

Figure 2: Self-sovereign or decentralized identity model

To best protect his or her privacy, a user should be able to reveal to a service provider only
the credential data strictly necessary for the requested service. This property is known as

1In this case, we are referring to "Verifiable Presentation" (VP).

2In this case, we are referring to "Verifiable Credential" (VC). In the eIDAS 2.0 terminology, this is referred to as
(Q)EEAs.

6
selective disclosure of attributes. For example, to benefit from a discounted train ticket as a
student, a user should be able to prove their student status to the railway company booking
website without having to disclose their full identity and/or the specific course they are studying.

Selective disclosure of attributes is easily achieved in the physical world. For example,
concealing (or "redacting") information on one's credential with one's hand (or with a black felt-
tip pen), leaving only certain identity data visible, is a selective disclosure of attributes. (see
Figure 3). The ISO/IEC 18013-5 standard explains how to transpose this manual redaction
technique (see Figure 3) to credentials.

Figure 3 : Selective disclosure of identity data

The ISO/IEC 18013-5 standard is an international standard concerned with the design of a
mobile driving license (mDL) credential carried in a native application running in a mobile
device. It specifically defines an (extensible) data model3 for such credentials, as well as a
protocol enabling the selective disclosure of attributes associated with such a credential.

The working principle of the selective disclosure method used in the ISO/IEC 18013-54
standard is as follows (see also Figure 4)5.

Issuance of a credential; the Identity Provider (IdP) or Issuer has a pair of keys, consisting
of a private key (𝑆𝐾𝐼 ) and a public key (𝑃𝐾𝐼 ), of a digital signature algorithm such as ECDSA.
The user also has their own key pair, consisting of a private key (𝑆𝐾) and a public key (𝑃𝐾) of
a digital signature algorithm, which they will use to authenticate their VPs. The user must have
their key pair and attributes related to their driving license certified by the IdP. We will denote
the attributes as (𝑎1 , 𝑎2 , 𝑎3 , … , 𝑎𝑛 ).
During the issuance phase of such a (verifiable) credential (VC), the Identity Provider (IdP) will
first authenticate the user. Then, the IdP will randomly pick 𝑛 secret values, denoted as {𝐾𝑖 }𝑛𝑖=1 .
Next, the IdP will compute 𝑛 digests (cryptographic hashes), one for each attribute. Each of
these 𝑛 digests will be labeled with a unique digest identifier, denoted as 𝐻𝐼𝐷𝑖 . The digest,
denoted as 𝐻𝑖 , for each attribute is calculated using its digest identifier (𝐻𝐼𝐷𝑖 ), attribute
identifier (denoted by 𝐼𝐷𝑎𝑖 ), attribute value ( 𝑎𝑖 ) and the secret key generated and associated
with that attribute during the creation of the identity credential: 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 )

3 This model can, of course, be extended to any other form of digital identity document on a mobile phone (social
security card, national identity card, passport, etc.).
4 It is also referred to as ISO mDL in the subsequent context.
5 We will voluntarily use the terminology commonly used in the context of SSI (VC, VP, user, identity provider,

service provider, etc.) for this description, rather than the terminology used in the ISO/IEC 18013-5 standard
(mDL, mdoc, MSO, etc.).

7
where ℋ is a cryptographic hash function (such as SHA-256; the notation 𝑠𝑡𝑟1 ∥ 𝑠𝑡𝑟2 denotes
the concatenation of the strings 𝑠𝑡𝑟1 and 𝑠𝑡𝑟2 ).
The Identity Provider (IdP) then computes a digital signature using its private key 𝑆𝐾𝐼 on the
data structure comprising the user's public key 𝑃𝐾 and the 𝑛 digests 𝐻𝑖 . Let's denote 𝐻 = 𝑃𝐾 ∥
𝐻1 ∥ 𝐻2 ∥ … ∥ 𝐻𝑛 and 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 = 𝑆𝑖𝑔𝑛𝑆𝐾𝐼 (𝐻) as the signature of the IdP on 𝐻.
The IdP then transmits 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and the keys 𝐾𝑖 to the user.
The user's verifiable credential (VC) (or Mobile Security Object - MSO in the terminology of the
ISO/IEC 18013-5 standard) consists of their public key 𝑃𝐾, the digests {𝐻𝑖 }𝑛𝑖=1 and the
certificate 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 on this data : 𝑉𝐶 = (𝑃𝐾, {𝐻𝑖 }𝑛𝑖=1 , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 ). The secret data associated with this
VC are 𝑆𝐾 and the secret keys {𝐾𝑖 }𝑛𝑖=1 .

Verifiable presentation of a digital identity document with selective disclosure: we will

denote by 𝔇, the list of indices of the attributes requested by the RP. For example, 𝒟 = {1, 5, 7}
will mean that the RP wants the user to disclose attributes 𝑎1 , 𝑎5 , and 𝑎7 .
1. The user anonymously connects to the RP's website. The RP sends them the access
conditions for their site (i.e., the list 𝒟 of required attributes) along with a random value
(nonce), specific to this session, to prevent (VP) replay attacks.
2. The user calculates a signature (𝜎𝑈𝑠𝑒𝑟 ) using their private key 𝑆𝐾 on a set of data called
"DeviceAuthenticationBytes" in the ISO/IEC 18013-5 standard, denoted as 𝑚𝐷𝐴𝐵 in the
remainder of this document. The DeviceAuthenticationBytes6 includes the nonce (or
any other equivalent element specific to the current session with the RP to prevent VP
replay attacks), optionally the set of data disclosed to the RP, and other contextual
data: 𝜎𝑈𝑠𝑒𝑟 = 𝑆𝑖𝑔𝑛𝑆𝐾 (𝑚𝐷𝐴𝐵 ).
The VP consists of the public key 𝑃𝐾𝐼 of the IdP, the public key 𝑃𝐾 of the user, the digests {𝐻𝑖 }𝑛𝑖=1 ,
the set of data disclosed to the RP (𝒟𝑑𝑖𝑠𝑐𝑙𝑜𝑠𝑒𝑑 = {𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } ), and the signatures
𝑖∈𝒟
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and 𝜎𝑈𝑠𝑒𝑟 : 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾, {𝐻𝑖 }𝑛𝑖=1 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ).
𝑖∈𝒟

3. The user transmits the 𝑉𝑃 to the RP.

The RP first calculates 𝐻′𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) for each 𝑖 ∈ 𝒟.
It then verifies that:
1) 𝐻′𝑖 = 𝐻𝑖 for each 𝑖 ∈ 𝒟 ;
2) 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 is a valid signature on 𝐻 = 𝑃𝐾 ∥ 𝐻1 ∥ 𝐻2 ∥ … ∥ 𝐻𝑛 using the public key 𝑃𝐾𝐼 ;
3) 𝜎𝑈𝑠𝑒𝑟 is a valid signature on 𝑚𝐷𝐴𝐵 (which the RP can reconstruct) using the public key
𝑃𝐾 certified by the issuer.
If all these conditions are met, the RP grants access to its site.
Note 1: the signature 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 authenticates all the data disclosed by the user ({ 𝑎𝑖 }𝑖∈𝒟 )) as well
as the public key 𝑃𝐾. The signature 𝜎𝑈𝑠𝑒𝑟 , on the other hand, convinces the RP that this VP
originates from the holder of the 𝑉𝐶 = ( 𝑃𝐾, {𝐻𝑖 }𝑛𝑖=1 , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 ) and is not a replay of a previous
VP.
Note 2: the secret keys (𝐾𝑖 ), included in the computation of the digests 𝐻𝑖 , are used to prevent
exhaustive search attacks aimed at recovering the undisclosed attributes. Without these secret
keys, brute-force attacks would easily succeed against attributes with low entropy, such as
those related to the user's "date of birth" or "identity document serial number". Indeed, if 𝐻𝑖

6 The ISO/IEC 18013-5 standard is not very explicit about the content of "DeviceAuthenticationBytes".

8
had been computed as follows: 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ), without the secret key 𝐾𝑖 , it would be
easy to retrieve the attribute "date of birth" (𝑎𝑖 ) by testing all possible values (𝑎′𝑖 ) until obtaining
the correct one, i.e., the one that satisfies the equality 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎′𝑖 ) (where 𝐻𝐼𝐷𝑖
and 𝐼𝐷𝑎𝑖 are public data accessible to everyone).

Figure 4: Selective disclosure of attributes

Drawback 1: From a data protection perspective, this solution has a significant flaw: the user
is traceable by the RP (and also by the IdP). Indeed, all VPs of this user will systematically
contain the signature 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and the public key 𝑃𝐾, indicating that they have been produced
by a single user. Worse still, if the RP and the IdP collude, they can certainly identify who
produced a given VP (indeed the IdP knows to whom it issued the signature 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and can
therefore identify the author of any VP).

Drawback 2: the user’s private key 𝑆𝐾, which is used to authenticate their VPs (via the
signature 𝜎𝑈𝑠𝑒𝑟 ), is an extremely sensitive key that must be properly protected; indeed, the
compromise of this key would risk the user's identity being usurped. ISO/IEC 18013-5
recommends that this key be stored in a "secure hardware element with appropriate
certifications" for this purpose. However, such devices (Secure Element or SE) have limited
computational power and do not support all the mathematical operations used by certain
classical digital signature algorithms (especially those, like BBS+, involving bilinear pairings in
the generation of a signature and/or the verification of a signature). This constraint therefore
strongly limits the type of digital signature algorithms that can be used to issue the
signatures 𝝈𝑼𝒔𝒆𝒓 and/or verify the signatures 𝝈𝑰𝒔𝒔𝒖𝒆𝒓 .

9
1. Foundations of the BBS# protocol
We propose a solution to these two drawbacks (traceability, by the IdP and the RP, of the
signature issued by the IdP and the user's public key), while remaining compliant with the
recent ISO/IEC 18013-57 standard. In other words, the user will be able to reveal to a service
provider only the attributes strictly necessary to access the services the latter offers, but without
being able to be traced by the IdP and/or the RP from their VPs. The selective disclosure
method we use is fully compliant with that described in ISO/IEC 18013-5 (and briefly described
above).

1.1 Cryptographic tools

For our protocol, we will rely on a set of well-proven cryptographic techniques: an additive
homomorphic commitment scheme and zero-knowledge proofs (ZKP). We will briefly explain
these concepts, trying to minimize as much as possible the underlying mathematical
formalism. Readers familiar with these concepts can skip this section and proceed to the next
one.

1.1.1 Commitment schemes

The commitment of a value is a cryptographic process that allows a sender (Alice) to commit
to a value (such as a secret) to a recipient (Bob) without initially revealing it, ensuring that this
commitment cannot be changed afterwards. The value can be revealed by the sender at a
later stage if necessary.
Thus, the recipient can be assured that once the commitment is made, the sender can no
longer change their mind about the committed value. To illustrate this, a commitment can be
seen as a closed safe, containing the secret, that is given to Bob. Later Alice can provide Bob
with the key to open it.
For example, a simple way to build a commitment scheme is to use a hash function 𝐻. It is
important to note that such a function should be collision-resistant, meaning it should be
infeasible (in practice) to find two messages 𝑚 and 𝑚′ such that 𝐻(𝑚) = 𝐻(𝑚′). Additionally,
the function should be computationally difficult to invert: given a hash 𝐶, it should be difficult to
find a message 𝑚 such that 𝐶 = 𝐻(𝑚).
To commit to a value 𝑥 (such as the winning combination for the next horse race or lottery
draw) with Bob, Alice chooses a random value 𝑟 and calculates the commitment 𝐶 = 𝐻(𝑥||𝑟),
which she sends to Bob.8. By doing so, Alice can no longer change her mind. Otherwise, it
would mean she could find another value 𝑥′ ≠ 𝑥 (along with another random value 𝑟′) such
that 𝐶 = 𝐻(𝑥′||𝑟′), which would contradict the assumption that the hash function 𝐻 is
collision-resistant.

7 In particular, we adhere to the data model and the protocols for issuing VCs and selective disclosure as defined
in this standard. Additionally, the cryptographic tools employed in our solution involve only classical
mathematical operations such as point addition or scalar multiplications on elliptic curves, which are efficient
enough to be executed by constrained devices such as secure elements (smart cards) as recommended by the
ISO/IEC 18013-5 standard.
8
The symbol || refers to the concatenation symbol.

10
Furthermore, Bob who was given 𝐶 is unable to recover the value that has been committed.
Otherwise, it would mean that he can invert the hash function 𝐻.9
At the end of the race, Alice can prove to Bob that she had the trifecta r by revealing the pair
(𝑥, 𝑟). Bob can check that Alice did not lie by verifying that 𝐶 = 𝐻(𝑥|| 𝑟).
For our protocol, we will use the commitment scheme proposed by Pedersen in 1992 [Ped92].
This scheme provides commitments that are perfectly hiding10 and computationally binding11.

1.1.2 Zero Knowledge Proofs

A Zero-Knowledge Proof (ZKP) [GMR85] is an interactive protocol that allows a verifier to be
convinced that a certain prover knows a secret 𝑆 that satisfies a given predicate 𝑃 - for
example, the factorization (𝑝, 𝑞) of a very large public number 𝑁 which is the product of these
two prime numbers 𝑝 and 𝑞 (𝑁 = 𝑝 ∗ 𝑞). Furthermore, the proof reveals no information about
the secret 𝑆 to the verifier (the factorization of 𝑁 in our example), except for the fact that it
satisfies the given predicate 𝑃. In the sequel, to represent Zero-Knowledge Proofs, we will
sometimes use the standard notation introduced by Camenisch and Stadler [CS97]: PoK{α,β,·
· · : predicate on α,β,· · · }, where the Greek letters correspond to the secrets known by the
prover. For example, PoK{α : 𝑦 = 𝑔𝛼 } will denote a proof of knowledge of the discrete logarithm
of (the public value) 𝑦 in the base (public value) 𝑔. In our constructions, we will rather use the
non-interactive versions of Zero-Knowledge Proofs (also called Signatures of Knowledge”),
obtained through heuristic transformations such as the one due to Fiat-Shamir [FS86]. More
precisely, a ”Signature of Knowledge” is a non-interactive protocol that allows a prover to
convince a third party that they know a secret 𝑆 that satisfies a predicate 𝑃, and which also
guarantees the authenticity and integrity of a message 𝑚. We denote such a Signature of
Knowledge with secret values (α,β,𝛾,..) that satisfy a given predicate and authenticate a
message 𝑚 as follows SoK{α,β, 𝛾,· · · : predicate on α,β, 𝛾,· · · }(𝑚), where the Greek letters
correspond to the secrets known by the prover and 𝑚 is the authenticated message. For
example, SoK{α : 𝑦 = 𝑔𝛼 }(𝑚) will denote a signature of knowledge of the discrete logarithm of
(the public value) 𝑦 in the base (public value) 𝑔, authenticating the message 𝑚. A signature of
knowledge on a message 𝑚 has the same characteristics as a digital signature: it guarantees
both the authenticity and integrity of the message 𝑚.

1.2 Stakeholders presentation

In an architecture following the self-sovereign digital identity model, several entities are
involved:

• Identity providers (sometimes called "Issuers")

• Service providers (also known as Relying Party or RP or verifier)
• Users

9 The use of the random value r is crucial. Given that there is a limited number of possible combinations, Bob
could have found the winning combination x by a brute-force attack if Alice had simply sent him C = H(x) instead
of C = H(x, r).
10
An attacker in possession of a commitment C will not learn any information about the secret value (the winning
combination for the next horse race) that was committed, even if they have unlimited computational power.
11
Given a commitment 𝐶 of a message m, it is hard to find another message 𝑚′ such that 𝐶 is also a
commitment to the message 𝑚′.

11
 1.2.1 The identity provider
Its role is to issue VCs to users, containing their attributes, after authenticating them. Users
can then present these VCs when accessing a service to prove who they are or one of their
qualities. In the following, the IdP will use the BBS+ protocol (described later) to certify the
identity elements (attributes) of users, instead of a more classical digital signature scheme.

1.2.2 The service provider / RP

It delivers services to users after ensuring that they meet the conditions for accessing its
services. For example, to access a web site with adult content, the service provider has a legal
obligation to verify that the user is of legal age. The user must therefore provide proof of age
by means of a Verifiable Presentation (VP) generated from a Verifiable Credential (VC),
certifying their age, issued by an Identity Provider (IdP) that the Service Provider (SP) trusts
(such as the State agency in charge of issuing official documents for a driving license).

1.2.3 The users

They have a set of VCs that allow them to prove their identity or qualities (such as majority,
seniority, degrees, etc.) to service providers in order to access the services they offer. They
have a digital identity wallet (ID Wallet) that allows them to store and manage their various
VCs and generate VPs for access to SP services. Their private keys and secrets (which are
used to prove ownership of the VCs they present) are stored (ideally) in secure devices such
as Secure Elements, HSMs, or TEEs.

1.3 Main phases

We will consider the following three main phases in our digital identity system:

• Issuance of VCs
• Access to a service provider and generation of a VP taking into account selective
attribute disclosure
• Verification of a VP

1.3.1 VCs issuance

This is an interactive protocol between an identity provider and a user. After authenticating the
user, the identity provider issues a VC (a signed credential in ISO/IEC 18013-5 format)
containing the user's identity elements, whether they are official or non-official. With such a
VC, the user can, if necessary, convince a service provider that they meet all the conditions to
access the services offered by the latter (for example, proving that they are of legal age to
access an adult content website, without revealing their date of birth or any other identifying
information).

1.3.2 Access to the RP and VP generation

This is an interactive protocol between a service provider and a user. The user who wishes to
access the services offered by a service provider receives its access policy. This policy may
include specific attributes such as the user's city of residence for a citizen consultation, their
student status to benefit from a preferential rate, or their date of birth or proof of legal age for
access to an online betting site. If the user meets the SP’s access policy, they select one or
more of their VCs (in ISO/IEC 18013-5 format) attesting to this (for example, their driving

12
license for a proof of majority) and instructs their Wallet to generate a VP (also in ISO/IEC
18013-5 format), based on one or more of their VCs, demonstrating that they indeed meet the
access policy of the service provider. Of course, in compliance with GDPR, a VP only reveals
the information requested by the service provider and nothing more. In the case of access to
an adult content website, for example, the service provider will only know that the user is of
legal age; it will not know their date of birth or any other information that could be used to
identify or trace them.

1.3.3 VP verification
The process of verifying a VP is the same as described in the ISO/IEC 18013-5 standard.

13
2. BBS# and selective disclosure : compliance with the ISO mDL
standard
In the following sections of this document, we will describe the procedures for issuing a VC
and generating a VP, in accordance with the ISO/IEC 18013-5 standard, based on a variant
(which we introduce) of the BBS+ protocol [BBS24]12. The BBS+ protocol has two
drawbacks for being used as is within the context of the ISO/IEC 18013-5 standard. The
first drawback is that in order to verify the validity of a VC issued by the Identity Provider, the
user's device must be able to handle bilinear pairings (which unfortunately are not supported
by current Secure Elements). The second drawback is that the computation time for generating
a VP with BBS+ is linear in the number of attributes (𝑛) of the underlying VC. Specifically, the
user's device needs to compute a linear number of scalar multiplications on elliptic curves.
However, such operations (scalar multiplications on elliptic curves) are extremely time-
consuming for devices such as Secure Elements. Therefore, we will modify the BBS+ protocol,
without compromising its security or privacy properties, so that the user's device (Secure
Element) does not need to compute any bilinear pairings and only needs to perform a constant
number of scalar multiplications on elliptic curves (specifically, only one scalar multiplication).

The various proofs of knowledge that will be implemented during the generation of a VP are
relatively standard13 and for this reason will not be detailed in this document.

2.1 Cryptographic preliminaries

In this section, we introduce our notations and provide a brief description of the cryptographic
building blocks that are at the core of our BBS+ construction (such as the Pedersen
commitment scheme [Ped92]), as well as the main computational assumption that underlies
the security of our cryptographic protocol.

2.1.1 Notations

In the following, we will use the notation PoΚ(𝛼1 , 𝛼2 ,…, 𝛼𝑛 ∶ ℛ(𝛼1 , 𝛼2 ,…, 𝛼𝑛 )) to denote a
Zero-Knowledge Proof of Knowledge (ZKPK) of elements 𝛼1 , 𝛼2 ,…, 𝛼𝑛 satisfying the relation
ℛ. For example, a proof of knowledge of the two prime factors of a public RSA modulus 𝑁
would be denoted as : PoΚ(𝛼1 , 𝛼2 ∶ 𝑁 = 𝛼1 ∙ 𝛼2 ⋀ ( 𝛼1 ≠ 1) ⋀ ( 𝛼2 ≠ 1) ). Similarly, we will use
the notation SoΚ(𝛼1 , 𝛼2 ,…, 𝛼𝑛 ∶ ℛ(𝛼1 , 𝛼2 ,…, 𝛼𝑛 ))(𝑚) to denote a signature of knowledge
(ZKPK) of elements 𝛼1 , 𝛼2 ,…, 𝛼𝑛 satisfying the relation ℛ and authenticating the message 𝑚.
𝑍𝑝 denotes the set {0, 1, 2,…, 𝑝-1}, where 𝑝 is a prime integer and 𝑍𝑝∗ the set {1, 2,…, 𝑝-1}.

12 This protocol, initially named BBS+, is now referred to as BBS, which could potentially cause confusion. The
BBS algorithm typically refers to the group signature scheme introduced by Boneh, Boyen, and Shacham at
Crypto 2004, while BBS+ refers to its generalization to an anonymous credential system, introduced by Au, Susilo,
and Mu in 2006 [ASM06]. BBS+ has since then been improved in terms of performance in 2016 [BBDT16, CDL16],
and its security has been further strengthened in 2023 [TZ23].
13
The article [Bra97] is indeed an excellent reference for building such proofs.

14
 2.1.2 Bilinear maps
Bilinear groups14, are a set of three cyclic groups15 𝐺1 , 𝐺2 and 𝐺𝑇 of order 𝑝, with 𝑝 being a
prime numberalong with a bilinear map, called 𝑒: 𝐺1 × 𝐺2 → 𝐺𝑇 satisfying the following three
properties :

1. (Bilinearity) ∀ 𝑔1 ∈ 𝐺1 , ∀ 𝑔2 ∈ 𝐺2 and ∀ (𝑎, 𝑏) ∈ 𝑍𝑝2 , 𝑒(𝑔1𝑎 , 𝑔2𝑏 ) = 𝑒(𝑔1 , 𝑔2 )𝑎𝑏 .

2. (Non-degeneracy) For 𝑔1 ≠ 1𝐺1 and 𝑔2 ≠ 1𝐺2 , 𝑒(𝑔1 , 𝑔2 ) ≠ 1𝐺𝑇 .
3. (Computability) ∀ 𝑔1 ∈ 𝐺1 , ∀ 𝑔2 ∈ 𝐺2 , there exists an efficient algorithm to compute
𝑒(𝑔1 , 𝑔2 ).
In practice, the groups 𝐺1 , 𝐺2 and 𝐺𝑇 will be chosen such that there is no efficiently computable
homomorphism between 𝐺1 and 𝐺2 .16

2.1.3 Computational hardness assumptions

The security of the cryptographic mechanisms we use relies in part on the assumption that the
following problem is hard. In other words, if an attacker is able to compromise the security of
these mechanisms, it means that they are also capable of solving this problem, which is known
to be "hard".

q-SDH problem. Given a cyclic group 𝐺 of prime order 𝑝 and an element 𝑥 ∈ 𝑍𝑝 , the q-strong
1⁄
Diffie-Hellman (q-SDH) problem consists of computing a pair of the form (𝑔 𝑥+𝑐 , 𝑐) ∈ 𝐺 × 𝑍𝑝
𝑥2 𝑥3 𝑥𝑞
given (𝑔, 𝑔 𝑥 , 𝑔 , 𝑔 , … , 𝑔 ).

q-DL problem. Given a cyclic group 𝐺 of prime order 𝑝 and an element 𝑥 ∈ 𝑍𝑝 , , the q-Discrete
2 3 𝑞
Logarithm (q-DL) problem consists of finding 𝑥 given (𝑔, 𝑔 𝑥 , 𝑔 𝑥 , 𝑔 𝑥 , … , 𝑔 𝑥 ).

The q-SDH problem was introduced by Boneh, Boyen, and Sacham to prove the security of
their group signature scheme BBS [BBS04]. The difficulty of this mathematical problem has
been further studied by Cheon [Che06] and Jao and Yoshida [JY09]. Moreover, the q-SDH
assumption trivially implies the slightly more standard q-DL assumption. The converse is not
known to be true in general, but it is true for algebraic adversaries [BFL20].

2.1.4 The Pedersen commitment scheme

The most commonly used commitment scheme is the one introduced by Pedersen [Ped92].
Below, we provide a brief description of this scheme.

Let 𝐺 be a cyclic group of prime order 𝑝 and let 𝑔 and ℎ be two arbitrary random generators of
𝐺. We assume that the discrete logarithm of ℎ to the base 𝑔 is unknown.

Commitment: To commit to a chosen message 𝑚 ∈ 𝑍𝑝 , the sender selects a random value

𝑟 ∈ 𝑍𝑝 and calculates 𝐶 = 𝑔𝑚 ℎ𝑟 , then sends it to the recipient.

14
In fact, this document describes the two versions of the BBS# protocol (i.e., with or without pairings). Current
SE/HSM/TEE devices do not support such mathematical operations nor the associated "pairing-friendly" curves,
so the version without pairings was preferred for our various implementations on WSCD (SE/TEE) of the BBS#
protocol (see section 4). This version without pairings relies on the protocol called MAC_BBS introduced by Barki
et al. at the SAC 2016 conference [BBDT16].
15
For convenience, we will assume that the group law in 𝐺1 and 𝐺2 is multiplication.
16
Such pairings are known as Type 3 pairings in the literature.

15
Opening: The sender sends the values 𝑚 and 𝑟 to the recipient, who verifies the equality: 𝐶 =
𝑔𝑚 ℎ𝑟 .

In the sequel, we will rather use in fact the generalization of this scheme to several committed
values (see figure 5, for the computation of the value 𝐴)

2.1.5 Issuance of VCs with BBS+:

First, the identity provider defines the public parameters of the BBS+ system: 𝑝𝑝 =
(𝐺, 𝐺2 , 𝐺𝑇 , 𝑒, 𝑝, 𝑛, 𝑔, 𝑔0 , 𝑔1 , 𝑔2 , . . , 𝑔𝑛 , 𝑔̃, 𝑓) where

• 𝐺 is a cyclic group, and we assume that the q-SDH problem is hard in this group.
• 𝑝 is the order of the group 𝐺 (a prime integer)
• 𝑛 is the number of attributes to be certified.
• 𝑔, 𝑔0 , 𝑔1 , 𝑔2 , . . , 𝑔𝑛 , 𝑔̃ are 𝑛+3 randomly chosen (in a verifiable way) generators of 𝐺
(such that no one knows the discrete logarithm of one generator with respect to
another). Each {𝑔𝑖 }𝑛𝑖=1 is associated with a specific attribute type (e.g., 𝑔1 is associated
with the "name" attribute, 𝑔2 with the « first name » attribute, 𝑔3 with the « age »
attribute, 𝑔4 with the « gender » attribute, etc.). This allows us to differentiate attributes
and avoid any ambiguity.
• 𝑓 is a generator of 𝐺2

In the following, all computations involving exponents will be performed modulo 𝑝 (mod 𝑝).

Keys generation :

The identity provider (IdP) randomly generates an integer 𝑠𝑘𝐼 from the set {1, 2,…, p-1} and
computes 𝑃𝐾𝐼 = 𝑔̃ 𝑠𝑘𝐼 and 𝑃𝐾′𝐼 = 𝑓 𝑠𝑘𝐼 (along with a zero-knowledge proof Π that its key pair
(𝑃𝐾𝐼 , 𝑃𝐾′𝐼 ) has been correctly computed : Π = PoK {𝛼: 𝑃𝐾𝐼 = 𝑔̃𝛼 ∧ 𝑃𝐾′𝐼 = 𝑓 𝛼 }17. Its private key
will be 𝑠𝑘𝐼 and its public key (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 ).

We assume that each user U also has a pair of keys, private and public, generated and
managed exclusively by their WSCD: (𝑠𝑘, 𝑃𝐾 = 𝑔 𝑠𝑘 ).

We also assume that the IdP has published 𝑛 public values18, randomly chosen from 𝑍𝑝 and
denoted {𝐾𝑖 }𝑛𝑖=1 as well as another integer (also public), randomly selected from 𝑍𝑝 and
denoted as 𝔄𝒹 (for « Undisclosed ») in the following.

To obtain a VC on its attributes (𝑎1 , 𝑎2 , 𝑎3 , … , 𝑎𝑛 ) known to the IdP and on its public key 𝑃𝐾,
the user U and the IdP must execute the following protocol (Figure 5), after U‘s authentication
by the IdP (or at least their WSCD). For security reasons, the public key PK transmitted to
the IdP must be authenticated as coming from a WSCD (typically through a signed
attestation)19.
First, the IdP will compute 𝑛 digests (cryptographic hashes), one for each attribute. Each of
these 𝑛 digests will be labeled with a unique digest identifier denoted as 𝐻𝐼𝐷𝑖 . The digest,

17 The groups 𝐺2 and 𝐺𝑇 , the bilinear map 𝑒, the generator 𝑓, the key 𝑃𝐾′𝐼 , as well as the proof Π are obviously
not necessary in the version of BBS# without pairings
18
These public values will be used for all VC issuances carried out by this IdP.
19 For obvious security reasons, the corresponding private key 𝒔𝒌 will be fully managed by the WSCD and

known only to it. It will be unknown to the user and their Wallet application.

16
denoted 𝐻𝑖 , is computed for each attribute using its digest identifier (𝐻𝐼𝐷𝑖 ), the attribute
identifier (denoted as 𝐼𝐷𝑎𝑖 ), the value of the attribute ( 𝑎𝑖 ) and the secret key generated and
associated with the attribute during the creation of the identity credential20: 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥
𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) where ℋ denotes a cryptographic hash function producing digests in 𝑍𝑝 (such
as SHA-256, for example).
The IdP then computes a BBS+ digital signature using its private key 𝑆𝐾𝐼 , on the data structure
consisting of the user's public key 𝑃𝐾 and the 𝑛 digests 𝐻𝑖 . Let 𝐻 = 𝑃𝐾 ∥ 𝐻1 ∥ 𝐻2 ∥ … ∥ 𝐻𝑛 and
𝐵𝐵𝑆+
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 = 𝑆𝑖𝑔𝑛𝑆𝐾 𝐼
(𝐻) be the IdP’s signature on 𝐻.
The IdP then transmits 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 to the user. The user's digital identity credential (VC) (or Mobile
Security Object - MSO in the terminology of ISO/IEC 18013-5) consists of their public key 𝑃𝐾,
the digests {𝐻𝑖 }𝑛𝑖=1 and the certificate 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 on this data : 𝑉𝐶 = ( 𝑃𝐾, {𝐻𝑖 }𝑛𝑖=1 , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 ). The
secret data associated with this VC is 𝑠𝑘.

Note 3 : In the following, we will assume that the private key 𝑠𝑘 is stored and managed
exclusively by the user's Secure Element (e.g., their SIM card) and that the attributes
(𝑎1 , 𝑎2 , 𝑎3 , … , 𝑎𝑛 ) as well as the 𝑉𝐶 = ( 𝑃𝐾, {𝐻𝑖 }𝑛𝑖=1 , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 ) are stored and managed by a
dedicated native application on their mobile phone.

20
The ISO/IEC 18013-5 standard requires this representation of attributes. It is understood that our solution
would also apply to any other representation of attributes.

17
 U IdP
Public input: 𝑝𝑝, Public input: 𝑝𝑝, 𝑃𝐾𝐼 ,
𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝔄𝒹, {𝐾𝑖 }𝑛𝑖=1 , 𝑃𝐾′𝐼 , 𝑎1 , 𝑎2 , 𝑎3 , … , 𝑎𝑛 , 𝔄𝒹,
𝑛 𝑛
{𝐻𝐼𝐷𝑖 }𝑛𝑖=1 , {𝐼𝐷𝑎𝑖 } {𝐾𝑖 }𝑛𝑖=1 , {𝐻𝐼𝐷𝑖 }𝑛𝑖=1 , {𝐼𝐷𝑎𝑖 }
𝑖=1 𝑖=1
Private input: 𝑠𝑘 Private input: 𝑠𝑘𝐼
𝑐ℎ
←
Computes :
• 𝜋𝑈 = SoK {𝛼: 𝑃𝐾 = 𝑔𝛼 }(𝑐ℎ)21

𝑃𝐾,𝜋𝑈,𝐴𝑡𝑡𝑒𝑠𝑡𝑎𝑡𝑖𝑜𝑛
→
Verifies the proof 𝜋𝑈
(terminates the protocol if it is
invalid)

Randomly chooses :
𝑒 ∈ 𝑍𝑝∗
Computes 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥
𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) for 𝑖 in [1, 𝑛],
then :
𝑛
1
𝐻
𝐴 = (𝑔0 𝑃𝐾 ∏ 𝑔𝑖 𝑖 )𝑠𝑘𝐼+𝑒
𝑖=1
𝐻
% Let 𝐵 = 𝑔0 𝑃𝐾 ∏𝑛𝑖=1 𝑔𝑖 𝑖
% this implies that 𝐴 𝑠𝑘𝐼+𝑒 = 𝐵
% and then that 𝐴 𝑠𝑘𝐼 = 𝐵𝐴−𝑒
% Let 𝐶 = 𝐴 𝑠𝑘𝐼 = 𝐵𝐴−𝑒
IdP generates a proof Π𝐼 =
PoK {𝛼: 𝐶 = 𝐴𝛼 ∧ 𝑃𝐾𝐼 = 𝑔̃𝛼 }.

𝐴,𝑒,𝜋𝐼
←

Computes
𝐻
• 𝐵 = 𝑔0 𝑃𝐾 ∏𝑛𝑖=1 𝑔𝑖 𝑖
• 𝐶 = 𝐵𝐴−𝑒 = 𝐴 𝑠𝑘𝐼
Verifies the proof Π𝐼
If the proof is valid, records
in their wallet their VC
signature (𝐴, 𝑒) on their

21 The 𝜋𝑈 proof is a proof of knowledge of the discrete logarithm of 𝑃𝐾 in the base 𝑔 (i.e., the private key 𝑠𝑘).
The algorithm called ECSchnorr or ECDSA [ISO14888] could be judiciously used for this proof. However, any other
algorithm that can prove knowledge of the private key 𝑠𝑘 could also be implemented. In the context of SSI, it is
generally the ECDSA algorithm [ISO14888] that is used for the 𝜋𝑈 proof, although strictly speaking, an ECDSA
signature does not constitute a proof of knowledge of the signing private key.

18
 attributes 𝑎1 , … , 𝑎𝑛 and their
public key 𝑃𝐾.22
(𝑨, 𝒆) is actually a BBS+
signature [BBS24] on 𝑷𝑲
and {𝑯𝒊 }𝒏𝒊=𝟏

Figure 5 : BBS+ VC issuance

2.1.6 Verifiable presentation of a digital identity credential in BBS+

format with selective attribute disclosure following the ISO mDL
standard.

In the following, we will denote by 𝔇 the list of indices of the attributes requested by the RP.
For example, 𝒟 = {1, 5, 7} will mean that the RP wants the user to reveal the attributes 𝑎1 , 𝑎5 ,
and 𝑎7 . For each attribute not belonging to 𝒟, the user will send the value 𝔄𝒹 to the RP.
• The user anonymously connects to the RP's website. The RP sends to the user its
access policy (i.e. the list 𝒟 of required attributes) as well as a specific random value
(nonce) for this session to prevent a replay attack of a VP.
• The user will first "anonymize" their public key (so that neither the issuer nor the RP
can trace them from this key). To do this, they will randomly pick an integer 𝑟 in 𝑍𝑝 and
compute using this value: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔 𝑠𝑘+𝑟 . They will then "anonymize" the BBS+
signature of their VC, to also prevent the issuer and the RP from tracing them from this
element, and "adapt" it to be on 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 and the {𝐻𝑖 }𝑛𝑖=1 (and not on 𝑃𝐾 and the
{𝐻𝑖 }𝑛𝑖=1)23. To do this, they will choose integers 𝑟1 , 𝑟2 ∈ 𝑍𝑝∗ and compute :

• 𝐴̂ = 𝐴𝑟1 ×𝑟2
• 𝐷 = 𝐵𝑟2
• 𝐵̅ = 𝐴̂−𝑒 𝐷 𝑟1 =𝐴̂ 𝑠𝑘𝐼
• 𝑟3 = 𝑟2−1 (mod 𝑝)
𝐻
• Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 = PoK{𝛼, 𝛽, 𝛾, 𝛿, {𝜏𝑖 }𝑖∉𝒟 : 𝐵̅ = 𝐴̂−𝛼 𝐷𝛽 ∧ 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝑖 𝑖 =
−𝜏
𝐷 𝛾 ∏𝑖∉𝒟 𝑔𝑖 𝑖 𝑔𝛿 }.24 This ZKP (Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ) being relatively standard, we will not
detail it in this document.
• 𝐵𝑙𝑖𝑛𝑑
Let 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 = (𝐴̂, 𝐵̅, 𝐷, Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 )

22
The particularity of this proof Π𝐼 is that it can be verified by constrained devices such as Secure Elements (SE)
because it only involves operations in the group 𝐺 (which are supported by these devices), unlike the proofs
proposed by the state of the art that require pairing calculations which are not supported by such devices.
23 This is possible with BBS+ signatures without compromising the security (unforgeability) of such signatures

(see section 3).

𝐻𝑖
24 We have the following two equalities, hence the ZKP Π ̅ ̂ −𝑒 𝑟1
𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 : 𝐵 = 𝐴 𝐷 and 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝑖 =
−𝐻
𝐷 𝑟3 ∏𝑖∉𝒟 𝑔𝑖 𝑖 𝑔𝑟

19
 Plausible Deniability: for use cases that allow it, instead of using a standard ZKP
(Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ), we could use a "Designated Verifier Proof" (DVP) [JSI96] to provide the user
with the ability to deny having generated a given VP (Plausible Deniability). A DVP, as the
name suggests, is a zero-knowledge proof generated for a designated verifier chosen in
advance (the RP in our case). They will be the only one able to verify and be convinced by
this particular proof. For everyone else, obtaining this proof is useless and provides no
information.
In our context, it would suffice to replace the proof Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 = PoK{𝛼, 𝛽, 𝛾, 𝛿, {𝜏𝑖 }𝑖∉𝒟 : 𝐵̅ =
𝐻 −𝜏
𝐴̂−𝛼 𝐷𝛽 ∧ 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝑖 𝑖 = 𝐷 𝛾 ∏𝑖∉𝒟 𝑔𝑖 𝑖 𝑔𝛿 } with the following DVP : DVP𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 =
𝐻 −𝜏
PoK{𝛼, 𝛽, 𝛾, 𝛿, 𝜇, {𝜏𝑖 }𝑖∉𝒟 : 𝐵̅ = 𝐴̂−𝛼 𝐷𝛽 ∧ 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔 𝑖 = 𝐷 𝛾 ∏𝑖∉𝒟 𝑔 𝑖 𝑔𝛿 ∨ 𝑃𝐾𝑅𝑃 = 𝑔𝜇 }
𝑖 𝑖
where 𝑃𝐾𝑅𝑃 would represent the certified public key of the RP (for which only it would
normally know the corresponding private key). DVP𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is therefore a proof of knowledge
of secrets {𝛼, 𝛽, 𝛾, 𝛿, 𝜇, {𝜏𝑖 }𝑖∉𝒟 } satisfying the predicate 𝑃 = 𝑃1 ∨ 𝑃2 where 𝑃1 = Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 and
𝑃2 = PoK{𝜇: 𝑃𝐾𝑅𝑃 = 𝑔𝜇 }. The RP will be convinced that if DVP𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is valid, it is
necessarily because 𝑃1 is true (since the RP is assumed to be the only one who knows the
private key associated with 𝑃𝐾𝑅𝑃 , 𝑃2 cannot therefore be true). On the other hand, it will
not be able to convince others that 𝑃1 is true. Indeed, as the RP can itself generate a proof
that 𝑃2 is true, it could be that DVP𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is valid, simply because 𝑃2 is true.

Similarly, the IdP could, when issuing the user's VC, replace the proof Π𝐼 (see figure 5)
with a DVP (in this case, the "designated verifier" would be the user). By doing so, the user
would no longer have the ability to convince others of the validity of their VC (only the IdP
would be able to do so). This property (deniability of a VC) is essential for designing
"coercion-resistant" online voting systems (see for example [ABBT16]); that is, to thwart
and render useless any attempt to buy votes or coerce a voter.)

• The user computes, using the random value 𝑟 and its private key 𝑠𝑘, a signature of
knowledge (𝜎𝑈𝑠𝑒𝑟 ) on a set of data, referred to as « DeviceAuthenticationBytes »25 in
the ISO/IEC 18013-5 standard and denoted 𝑚𝐷𝐴𝐵 in the following : 𝜎𝑈𝑠𝑒𝑟 =
𝑆𝑜𝐾{𝛼: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔𝛼 }(𝑚𝐷𝐴𝐵 ). The signature 𝜎𝑈𝑠𝑒𝑟 is a signature of knowledge of the
discrete logarithm of 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 in the base 𝑔 (i.e. of the private key, 𝑠𝑘 + 𝑟). The algorithm
called ECSchnorr could therefore be judiciously used for this signature of knowledge.
However, any other algorithm that allows proving knowledge of the private key 𝑠𝑘 could
also be implemented. In the context of SSI, the ECDSA algorithm is generally used for
such a signature (𝜎𝑈𝑠𝑒𝑟 ), although, strictly speaking, ECDSA is not a proof of
knowledge of the private signing key.
Note 4: In practice, Secure Elements (SE) are relatively closed devices. While most of them
support common digital signature algorithms like ECDSA, developers do not have the ability
to implement new cryptographic functionalities for security reasons. Therefore, it is difficult to
use these SEs for purposes other than what they were initially designed for (such as generating
ECDSA signatures, for example). As a result, an SE cannot "anonymize" its own public and
private keys because it has not been programmed to perform such operations. It cannot carry

25The DeviceAuthenticationBytes includes the nonce (or any other equivalent element specific to the current
session with the RP, which helps prevent replay attacks of VPs), possibly the set of data disclosed to the RP, and
other contextual data. However, the ISO/IEC 18013-5 standard is not very explicit about the exact content of the
"DeviceAuthenticationBytes".

20
out these basic operations, even though they may seem straightforward : generate a random
value 𝑟 and calculate 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 = 𝑠𝑘 + 𝑟 (𝑚𝑜𝑑 𝑝), its anonymized private key. Similarly, an SE
cannot generate the signature 𝜎𝑈𝑠𝑒𝑟 , i.e., a signature of knowledge of the discrete logarithm of
𝑃𝐾𝐵𝑙𝑖𝑛𝑑 in the base 𝑔 (i.e. of the private key, 𝑠𝑘 + 𝑟 (𝑚𝑜𝑑 𝑝)).
Below, we explain how the Secure Element (SE) and the associated mobile application
(referred to as M-Wallet) can jointly anonymize the public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 and calculate the
signature 𝜎𝑈𝑠𝑒𝑟 . It is important to note that only the SE knows the private key 𝑠𝑘 corresponding
to the user’s public key 𝑃𝐾.

We propose two variants of BBS#: in the first one, we assume that the digital signature
algorithm supported by the SE (Secure Element) is ECSchnorr, while in the second one,
we assume it is ECDSA.

Joint computation of 𝑷𝑲𝑩𝒍𝒊𝒏𝒅 and 𝝈𝑼𝒔𝒆𝒓 with ECSChnorr : We assume that the SE supports
the classical ECSchnorr digital signature algorithm, also known as ECSDSA in ISO/IEC 14888-
3 standard. It should be noted that in this standard, the so-called "Weak" version of the Fiat-
Shamir heuristic is implemented; however, in certain contexts, this version is vulnerable to an
attack introduced at Asiacrypt 2012 by Bernhard et al. [BPW12]. Although this attack does not
apply in our context, we will nevertheless indicate how to use the so-called Strong version of
the Fiat-Shamir heuristic (Strong FS) with ECSDSA (as specified in ISO/IEC 14888-3
standard). The attack by Bernhard et al. [BPW12] does not apply to non-interactive proofs
using the Strong version of the Fiat-Shamir heuristic.
The joint computation of the signature 𝜎𝑈𝑠𝑒𝑟 = 𝑆𝑜𝐾{𝛼: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔𝛼 }(𝑚𝐷𝐴𝐵 ) could be
performed in the following way (see figure 6) :
1. The SE will first calculate a signature of knowledge (denoted 𝜎) of the discrete logarithm
of 𝑃𝐾 in the base 𝑔 (i.e. of its private key 𝑠𝑘) : 𝜎 = 𝑆𝑜𝐾{𝛼: 𝑃𝐾 = 𝑔𝛼 }(𝑚𝐷𝐴𝐵 )26. The
algorithm called ECSDSA will be used to compute this signature. This signature of
knowledge is computed as follows using the ECSDSA algorithm. The SE generates a
random value 𝜔 and computes 𝑇 = 𝑔𝜔 , 𝑐 = ℋ(𝑇 ∥ 𝑚𝐷𝐴𝐵 ) and 𝜌 = 𝜔 + 𝑐 𝑠𝑘 (mod 𝑝)
where ℋ denotes a cryptographic hash function (e.g., SHA-256). The signature 𝜎
consists of the pair (𝑐, 𝜌) : 𝜎 = (𝑐, 𝜌). It is valid if 𝑐 ′ = ℋ(𝑔𝜌 × 𝑃𝐾 −𝑐 , 𝑚𝐷𝐴𝐵 ) = 𝑐 and
invalid otherwise.
2. The M-Wallet chooses a random value 𝑟 and computes 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔𝑟 × 𝑃𝐾 = 𝑔 𝑠𝑘+𝑟
and 𝜌𝐵𝑙𝑖𝑛𝑑 = 𝜌 + 𝑐 × 𝑟 = 𝜔 + 𝑐 × 𝑠𝑘 + 𝑐 × 𝑟 = 𝜔 + 𝑐 × (𝑠𝑘 + 𝑟) (mod 𝑝).
The signature 𝜎𝑈𝑠𝑒𝑟 = (𝑐, 𝜌𝐵𝑙𝑖𝑛𝑑 ) is a valid ECSDSA signature on 𝑚𝐷𝐴𝐵 with respect to the
public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 (Q.E.D).

26 𝑚𝐷𝐴𝐵 is typically transmitted to the SE by the M-Wallet. The M-Wallet could include 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 in it if we prefer
to use the Strong version of the Fiat-Shamir heuristic instead of the weak version. However, it is important to
note that the attack by Bernhard et al. would not apply in our context with the weak version of the Fiat-Shamir
heuristic.

21
 Figure 6 : Joint computation of 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 and 𝜎𝑈𝑠𝑒𝑟 with ECSChnorr (ECSDSA)

The VP consists of the public key of the IdP, the public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , the {𝔄𝒹}𝑖∉𝒟 , the set of
attributes disclosed to the RP (𝒟𝑑𝑖𝑠𝑐𝑙𝑜𝑠𝑒𝑑 = {𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } ), and the signatures
𝑖∈𝒟
𝐵𝑙𝑖𝑛𝑑 𝐵𝑙𝑖𝑛𝑑
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and 𝜎𝑈𝑠𝑒𝑟 : 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ).
𝑖∈𝒟

• The user transmits 𝑉𝑃 to the RP.

The RP first computes 𝐻′𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) for each 𝑖 ∈ 𝒟.
It then verifies that :
1) 𝐻′𝑖 = 𝐻𝑖 for each 𝑖 ∈ 𝒟 ;
2) 𝜎𝑈𝑠𝑒𝑟 is a valid ECSDSA signature on 𝑚𝐷𝐴𝐵 (which the RP can reconstruct) using the
public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 certified by the issuer. The verification algorithm for this SoK
(𝑆𝑜𝐾{𝛼: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔𝛼 }(𝑚𝐷𝐴𝐵 )) being relatively standard, we will not detail it in this
document.
𝐵𝑙𝑖𝑛𝑑
3) 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 is a valid BBS+ signature on 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝐻𝑖 }𝑖∈𝒟 and {𝐻′𝑖 = 𝔄𝒹}𝑖∉𝒟 , using the public
key of the IdP. To do this, it must first ensure that the following equality 𝐵̅ = 𝐴̂ 𝑠𝑘𝐼 is
satisfied27 and secondly that Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is valid. The verification algorithm for this ZKP
(Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ) being relatively standard, we will not detail it in this document.

If all these conditions are met, the RP grants access to its site.

27There are several methods to do this, with [BBS24] or without bilinear pairings (see for example [BBDT16] or
the solution based on Blind Tokens, described below for the "semi-offline" mode). If the IdP has implemented
the BBS+ version using bilinear pairings, then this verification could be done as follows: 𝑒(𝐴̂, 𝑃𝐾′𝐼 ) = 𝑒(𝐵̅ , 𝑓)

22
Joint computation of 𝑷𝑲𝑩𝒍𝒊𝒏𝒅 and 𝝈𝑼𝒔𝒆𝒓 with ECDSA: This time, we will assume that the SE
supports the classic digital signature algorithm ECSDSA [FIPS186-4, ISO/IEC 14888 3].

The joint computation of the signature ECDSA (𝜎𝑈𝑠𝑒𝑟 ) on the message 𝑚𝐷𝐴𝐵 using the private
key 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 = 𝑠𝑘 × 𝑟 (𝑚𝑜𝑑 𝑝), could be performed in the following way (see figure 7) :
1. The M-Wallet calculates 𝑀 = 𝑟 −1 × ℋ(𝑚𝐷𝐴𝐵 )28 mod 𝑝 and transmits 𝑀 to the SE after
authenticating itself with the latter.
2. The SE chooses a random value 𝑘 ∈ 𝑍𝑝∗ and calculates 𝑔𝑘 = (𝑖, 𝑗)29 and 𝑥 = 𝑖 (mod 𝑝).
3. If 𝑥 = 0 then go back to step 2.
4. The SE calculates 𝜎0 = 𝑘 −1 (𝑀 + 𝑠𝑘 × 𝑥) mod 𝑝.
5. If 𝜎0 = 0 go back to step 2. Otherwise, the SE transmits 𝜎0 to the M-Wallet.
6. The M-Wallet computes 𝜎 = 𝑟 × 𝜎0 = 𝑘 −1 (ℋ(𝑚𝐷𝐴𝐵 ) + 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 × 𝑥) mod 𝑝
The signature 𝜎𝑈𝑠𝑒𝑟 = (𝑥, 𝜎) is a valid ECDSA signature on 𝑚𝐷𝐴𝐵 with respect to the public
key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 (Q.E.D).

Figure 7: Joint calculation of 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 and 𝜎𝑈𝑠𝑒𝑟 with ECDSA

The VP consists of the public key of the IdP, the public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , the {𝔄𝒹}𝑖∉𝒟 , the set of
attributes disclosed to the RP (𝒟𝑑𝑖𝑠𝑐𝑙𝑜𝑠𝑒𝑑 = {𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } ), and the signatures
𝑖∈𝒟
𝐵𝑙𝑖𝑛𝑑 𝐵𝑙𝑖𝑛𝑑
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and 𝜎𝑈𝑠𝑒𝑟 : 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ).
𝑖∈𝒟

• The user transmits 𝑉𝑃 to the RP.

The RP first computes 𝐻′𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) for each 𝑖 ∈ 𝒟.
It then verifies that:
1) 𝐻′𝑖 = 𝐻𝑖 for each 𝑖 ∈ 𝒟 ;

2) 𝜎𝑈𝑠𝑒𝑟 is a valid ECDSA signature on 𝑚𝐷𝐴𝐵 (which the RP can reconstruct) using the
public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 certified by the issuer. The verification algorithm for an ECDSA

28 𝑚𝐷𝐴𝐵 could include 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 if one wishes to protect against a similar attack to that of Bernhard et al. (against
the ECSchnorr algorithm using the weak version of the Fiat-Shamir heuristic) that also applies to ECDSA.
29 Here, we are abusively using multiplication (instead of addition) to denote the group operation in 𝐺. The

element 𝑔𝑘 is indeed a point on the underlying elliptic curve.

23
 signature being relatively standard (see for instance [FIPS186-4, ISO/IEC 14888-3]),
we will not detail it in this document.

𝐵𝑙𝑖𝑛𝑑
3) 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 is a valid BBS+ signature on 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝐻𝑖 }𝑖∈𝒟 and {𝐻′𝑖 = 𝔄𝒹}𝑖∉𝒟 , using the public
key of the IdP. To do this, it must first ensure that the following equality 𝐵̅ = 𝐴̂ 𝑠𝑘𝐼 is
satisfied30 and secondly that Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is valid31. The verification algorithm for this ZKP
(Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ) being relatively standard, we will not detail it in this document.
If all these conditions are met, the RP grants access to its site.
Note 5: If all the conditions are met, it can be easily demonstrated that the attributes {𝑎𝑖 }𝑖∈𝒟
have been certified by the IdP and that the VP indeed originates from the user whose attributes
are the {𝑎𝑖 }𝑖∈𝒟 .

𝐵𝑙𝑖𝑛𝑑
Note 6: the 𝜎𝑈𝑠𝑒𝑟 signature would be generated by the user's SE, while the 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 signature
would be computed by the dedicated mobile application running on the user's mobile phone.
With our solution, the SE would not need to perform any bilinear pairings and would only need
to perform a single scalar multiplication on the elliptic curve to generate the 𝜎𝑈𝑠𝑒𝑟 signature
(compared to a linear number in 𝑛 with the original version of BBS+ currently being
standardized at IETF [BBS24]). For certain versions of BBS+, the user's secure device would
only need a constant number of scalar multiplications on the elliptic curve to generate the 𝜎𝑈𝑠𝑒𝑟
signature but would need to interact multiple times with the mobile application to compute this
signature, which could be problematic if a remote secure device like an HSM is implemented
(HSMs generally do not handle session management very well).

It can be easily proved that neither the issuer nor the RP can trace a user based on their VP
(provided, of course, that the user has not disclosed any personally identifiable attributes or
attributes that can be used to identify them), see section 3. In other words, with the solution
presented above, a user will be able to only disclose the attributes required by the service
provider to access its services, without being traceable by the IdP and/or the RP. Furthermore,
the selective disclosure method we use fully complies with the ISO/IEC 18013-5 standard
(which unfortunately, in its "standard usage" i.e., without the method described in this paper,
would allow colluding IdPs and RPs, to trace the usages of their common customers).

30 There are several methods to do this, with [BBS24] or without bilinear pairings (see for example [BBDT16] or
the solution based on Blind Tokens, described below for the "half-offline" mode). If the IdP has implemented the
BBS+ version using bilinear pairings, then this verification could be done as follows : 𝑒(𝐴̂, 𝑃𝐾′𝐼 ) = 𝑒(𝐵̅ , 𝑓)
31 In the ECDSA case, the proof Π ̅
𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 would be the following : Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 = PoK{𝛼, 𝛽, 𝛾, 𝛿, {𝜏𝑖 }𝑖∉𝒟 : 𝐵 =
−𝜏𝑖 𝐻𝑖
̂ −𝛼 𝛽 𝛿 𝛾∏
𝐴 𝐷 ∧ 𝐹 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝐷 𝑖∉𝒟 𝑔𝑖 ∧ 𝛿 ≠ 0 (𝑚𝑜𝑑 𝑝)} where 𝐹 = 𝑔0 ∏𝑖∈𝒟 𝑔𝑖 . We have the following two
−𝑟×𝐻𝑖
equalities, hence the validity proof Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 : 𝐵̅ = 𝐴̂−𝑒 𝐷 𝑟1 and 𝐹 𝑟 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝐷 𝑟×𝑟3 ∏𝑖∉𝒟 𝑔𝑖

24
Half offline mode : In the ISO 18013-5 standard, two verification modes for a VP are
proposed. One mode, which we will refer to as "offline," does not require the user or the RP to
be connected to generate and verify a VP. The other mode, which we will refer to as "half-
offline" (HOL), requires one of these two actors to be connected for the transaction (VP) to be
successfully completed. The offline mode is the one described in the previous sections. The
HOL mode corresponds to the synchronous mode (or federated identity model) described in
Figure 1, during which the user, after authenticating with the IdP, will receive a Token from the
IdP attesting that they meet the access policy of the RP.

In the following, we also propose a solution for the HOL mode, which does not have the
aforementioned drawbacks of the federated identity model. In particular, the IdP will not know
which RP the user is using the Token with and therefore cannot trace the user's usage. Please
note that this works both when the splitting is done with ECSDSA as when it is done
with ECDSA.

In the following, we assume that the user already possesses the VC signature = (𝐴, 𝑒) (see
figure 5) that they intend to use to access the services of the RP.
• The user will first "anonymize" their public key (to prevent the issuer and the RP from
tracing them based on this key). To do this, they will randomly pick an integer 𝑟 in 𝑍𝑝
and compute: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔 𝑠𝑘+𝑟 (see Note 6 above for the joint computation of this public
key).
• They will then "anonymize" the BBS+ signature of their VC to also prevent the issuer
and the RP from tracing them based on this element, and "adapt" it to be on 𝑃𝐾𝐵𝑙𝑖𝑛𝑑
and the {𝐻𝑖 }𝑛𝑖=1 (rather than on 𝑃𝐾 and the {𝐻𝑖 }𝑛𝑖=1 )32. To do this, they will choose
integers 𝑟1 , 𝑟2 ∈ 𝑍𝑝∗ and compute :

• 𝐴̂ = 𝐴𝑟1 ×𝑟2
• 𝐷 = 𝐵𝑟2
• 𝐵̅ = 𝐴̂−𝑒 𝐷 𝑟1 =𝐴̂ 𝑠𝑘𝐼
• 𝑟3 = 𝑟2−1 (mod 𝑝)
𝐻
• Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 = PoK{𝛼, 𝛽, 𝛾, 𝛿, {𝜏𝑖 }𝑖∉𝒟 : 𝐵̅ = 𝐴̂−𝛼 𝐷𝛽 ∧ 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝑖 𝑖 =
−𝜏
𝐷 𝛾 ∏𝑖∉𝒟 𝑔𝑖 𝑖 𝑔𝛿 }.33 This ZKP (Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ) being relatively standard, we will not
detail it in this document.
• The user will then attempt to obtain, online, from the IdP, a blind proof that
𝐵̅ = ̂𝐴 𝑠𝑘𝐼 where 𝐴̂ = 𝐴𝑟1 ×𝑟2 . We will refer to this proof as 𝜋𝐸𝑄 (SoK). By blind, we
mean that the IdP, although contributing to the generation of this proof (as only
they know 𝑠𝑘𝐼 ), will be unable, in the presence of such a proof, to determine
which user it was intended for. This proof described in Figure 8 can be obtained
using the blind signature protocol of Chaum-Pedersen [CP92]34, which is

32 This is possible with BBS+ signatures without compromising the security (unforgeability) of such signatures.
33 We have the following two equalities, hence the validity proof Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 : 𝐵̅ = 𝐴̂−𝑒 𝐷 𝑟1 and
𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝐻 𝑖
𝑖 = 𝐷 𝑟3 ∏ −𝐻𝑖 𝑟
𝑖∉𝒟 𝑔𝑖 𝑔
34 Benhamouda et al. [BLL+22] have shown that certain blind signature schemes are vulnerable to a parallel

attack (ROS attack). Specifically, a user who concurrently executes a large number (𝑙) of sessions of the Chaum-
Pedersen blind signature protocol with the IdP could, after these 𝑙 sessions, succeed in forging an additional valid

25
 standardized in ISO/IEC ([ISO18370], mechanism 4). In fact, it is this protocol
that is implemented in Figure 8.

The VP consists of the public key of the IdP, the public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , the {𝔄𝒹}𝑖∉𝒟 , the set of
𝐵𝑙𝑖𝑛𝑑
data disclosed to the RP (𝒟𝑑𝑖𝑠𝑐𝑙𝑜𝑠𝑒𝑑 = {𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } )35, the signatures 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 and
𝑖∈𝒟
𝜎𝑈𝑠𝑒𝑟 and the proof 𝜋𝐸𝑄 : 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } ,
𝑖∈𝒟
𝐵𝑙𝑖𝑛𝑑
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 , 𝜋𝐸𝑄 ).
• The user transmits 𝑉𝑃 to the RP.
The RP first computes 𝐻′𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 ) for each 𝑖 ∈ 𝒟.
It then verifies that :
1) 𝐻′𝑖 = 𝐻𝑖 for each 𝑖 ∈ 𝒟 ;
2) 𝜎𝑈𝑠𝑒𝑟 is a valid ECSDSA signature on 𝑚𝐷𝐴𝐵 (which the RP can reconstruct) using the
public key 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 certified by the issuer. The verification algorithm for this SoK
(𝑆𝑜𝐾{𝛼: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔𝛼 }(𝑚𝐷𝐴𝐵 )) is described above (see Note 6).
𝐵𝑙𝑖𝑛𝑑
3) 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 is a valid BBS+ signature on 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝐻𝑖 }𝑖∈𝒟 and {𝐻′𝑖 = 𝔄𝒹}𝑖∉𝒟 , using the public
key of the IdP. To do this, it must first ensure that the 𝜋𝐸𝑄 proof is valid36 (see figure 8)
and secondly that Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is valid. The verification algorithm for this ZKP (Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 )
being relatively standard, we will not detail it in this document.

If all these conditions are met, the RP grants access to its site.
Note 7 : The particularity of our solution, for the HOL mode, is that it does not require the use
of pairings, which makes it much more efficient than solutions that implement these kind of
computations. Its security also relies on computational problems that are more widely accepted
() by the scientific community.

signature (𝑙+1 signatures instead of 𝑙). However, this attack would not apply to our context; in fact, the requests
(per user) would only be made in sequential mode (or in a very limited number in concurrent mode).
35 To illustrate selective disclosure with BBS#, we deliberately relied on the ISO/IEC 18013-5 standard. However,

it is important to note that any other representation of attributes and any other method enabling selective
disclosure (such as using commitments and zero-knowledge proofs) could be implemented with BBS#.
36 This 𝜋
𝐸𝑄 proof effectively constitutes a proof that the user's VC has not been revoked. Indeed, a IdP will refuse
to provide this proof if the user's VC signature = (𝐴, 𝑒) has been revoked. This technique is therefore a very simple
(comparable to using a protocol such as OCSP - Online Certificate Status Protocol) and privacy-preserving method
to prove the non-revocation of a (Q)EEA involved in a transaction/VP.

26
 U IdP
Public input: 𝑝𝑝, Public input: 𝑝𝑝, 𝑃𝐾𝐼 ,
𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , {𝐾𝑖 }𝑛𝑖=1 , {𝐻𝐼𝐷𝑖 }𝑛𝑖=1 , 𝑃𝐾′𝐼 , 𝑎1 , 𝑎2 , 𝑎3 , … , 𝑎𝑛 , {𝐾𝑖 }𝑛𝑖=1 ,
𝑛 𝑛
{𝐼𝐷𝑎𝑖 } , 𝑃𝐾, 𝐴, 𝑒 {𝐻𝐼𝐷𝑖 }𝑛𝑖=1 , {𝐼𝐷𝑎𝑖 } , 𝑃𝐾, 𝐴, 𝑒
𝑖=1 𝑖=1
Private input: 𝑠𝑘, 𝑙 = 𝑟1 × 𝑟2 , Private input: 𝑠𝑘𝐼
𝐴̂ = 𝐴𝑟1 ×𝑟2 , 𝐵̅
𝑐ℎ
←
Computes:
• 𝜋𝑈 = SoK {𝛼: 𝑃𝐾 = 𝑔𝛼 }(𝑐ℎ)

𝜋𝑈
→
Verifies the proof 𝜋𝑈 (aborts if
it is invalid)

Randomly chooses :
𝑠 ∈ 𝑍𝑝∗
% Let 𝐻𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥
𝑎𝑖 ∥ 𝐾𝑖 ) for 𝑖 in [1, 𝑛],
𝐻
% Let 𝐵 = 𝑔0 𝑃𝐾 ∏𝑛𝑖=1 𝑔𝑖 𝑖
% We have
𝐵𝐴−𝑒 = 𝐴 𝑠𝑘𝐼
% Let 𝐶 = 𝐴 𝑠𝑘𝐼 = 𝐵𝐴−𝑒
IdP computes:
𝐴0 = 𝑔̃ 𝑠
𝐵0 = 𝐴𝑠

𝐴0 ,𝐵0
←

Chooses :
𝑢, 𝑣 ∈ 𝑍𝑝∗
Computes :
• 𝐴̈0 = (𝐴0 × 𝑔̃𝑣 )𝑢
• 𝐵̈0 = (𝐵0𝑙 × 𝐴̂𝑣 )𝑢
• 𝑐 = ℋ(𝐴̂ ∥ 𝐵̅ ∥ 𝐴̈0 ∥
𝐵̈0 ∥ 𝑚𝐷𝐴𝐵 )
• 𝑐0 = 𝑐/𝑢 (mod 𝑝)

𝑐0
→

𝑟0 =𝑠+𝑐0 × 𝑠𝑘𝐼 (𝑚𝑜𝑑 𝑝)

←

27
 Calculates :
• 𝑟 = ( 𝑟0 + 𝑣)𝑢 (mod 𝑝)

The proof 𝜋𝐸𝑄 = (𝐴̂, 𝐵̅, 𝑐, 𝑟).

It is a valid proof (SoK) on the
message 𝑚𝐷𝐴𝐵 if :
𝑐 ′ = ℋ(𝐴̂ ∥ 𝐵̅ ∥ 𝑔̃𝑟
× 𝑃𝐾𝐼−𝑐 ∥ 𝐴̂𝑟
× 𝐵̅−𝑐 ∥ 𝑚𝐷𝐴𝐵 )
=𝑐
Figure 8: Blind computation of the 𝜋𝐸𝑄 proof

3. Security
It is worth reminding that a VC issued using the BBS/BBS+ signature algorithm is unforgeable
under the q-SDH assumption [TZ23]. Two other fundamental security properties for
anonymous credential systems have been defined (see, for example, [BBDT16]): the
unforgeability of VPs and the anonymity of such VPs.
Informally, the first property characterizes the fact that an adversary must be unable to
generate a VP that will be accepted by an RP if they do not possess a valid VC (issued by an
IdP) that satisfies the access policy of that RP.
The second property expresses the fact that a VP reveals no other information than the
attributes that the user agreed to disclose to the RP. In the particular case where the user does
not disclose any identifying attributes (or any attributes at all), they will be perfectly anonymous
among the set of users sharing the same attributes as them. For example, if the disclosed
attribute is the “year of birth”, the user will be perfectly anonymous among all individuals born
in the same year and who obtained a VC from the same IdP.
Firstly, we will prove that the unforgeability of BBS# VPs relies on the q-SDH assumption. In
other words, if a VP is accepted by an RP, then this implies that the user knows a valid VC
that satisfies the access policy of that RP, as well as the private key associated with that VC.37
Unforgeability of VPs
𝐵𝑙𝑖𝑛𝑑
Proof: Let 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ) be a
𝑖∈𝒟
given VP where 𝜎𝐼𝑠𝑠𝑢𝑒𝑟𝐵𝑙𝑖𝑛𝑑
= (𝐴̂, 𝐵̅, 𝐷, Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ). We recall that 𝜎𝑈𝑠𝑒𝑟 = 𝑆𝑜𝐾{𝛼: 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 =
𝑔𝛼 }(𝑚𝐷𝐴𝐵 ). Therefore, the signature 𝜎𝑈𝑠𝑒𝑟 is a proof of knowledge of the discrete logarithm of
𝑃𝐾𝐵𝑙𝑖𝑛𝑑 in the base 𝑔. By using the extractor for this proof of knowledge, we can extract
𝑠𝑘𝐵𝑙𝑖𝑛𝑑 such that :
𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 (𝟏)

37 It is worth noting that the private key associated with a VC is necessarily managed by a WSCD. Indeed, during
the issuance of a VC, the IdP ensures, beforehand, before issuing a VC, that the request is legitimate and that the
public key presented to it comes from a WSCD (via an attestation, for example). Furthermore, Tessaro and Zhu
[TZ23] have demonstrated, under the q-SDH assumption, that the only way to obtain a valid VC is to request it
from an IdP.

28
By using the extractor for the Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 proof, we can extract values 𝑒, 𝑟, 𝑟1 , 𝑟3 , {𝐻𝑖 }𝑛𝑖=1 such that:

𝐵̅ = 𝐴̂−𝑒 𝐷𝑟1 (𝟐)

𝐻 −𝐻𝑖 𝑟
𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏ 𝑔𝑖 𝑖 = 𝐷 𝑟3 ∏ 𝑔𝑖 𝑔 (𝟑)
𝑖∉𝒟
𝑖∈𝒟

We also know that if the VP is accepted by the RP, then:

𝐵̅ = 𝐴̂ 𝑠𝑘𝐼 (𝟒)
(2) and (4) therefore implies that:
𝐴̂ 𝑠𝑘𝐼+𝑒 = 𝐷 𝑟1 (𝟓)
If 𝑟1 = 0 (mod 𝑝), (5) implies that 𝑠𝑘𝐼 = −𝑒 (mod 𝑝) and therefore our reduction has found the
private key of the IdP. This is impossible under the discrete logarithm assumption. Therefore,
we will assume that 𝑟1 ≠ 0 (mod 𝑝).
𝐻
From (3) and (1), we can deduce that 𝐷 𝑟3 = 𝑔0 𝑔 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 −𝑟 ∏𝑛𝑖=1 𝑔𝑖 𝑖 (6)
𝐻
• If 𝑟3 = 0 (mod 𝑝) then 𝑔0 = 𝑔 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 −𝑟 ∏𝑛𝑖=1 𝑔𝑖 𝑖 . We have therefore found a
representation of 𝑔0 in the base (𝑔, {𝑔𝑖 }𝑛𝑖=1 ). This is also impossible under the discrete
logarithm assumption. Therefore, we will assume that 𝑟3 ≠ 0 (mod 𝑝).
−1 𝑠𝑘𝐼 +𝑒
• If 𝑟3 ≠ 0 (mod 𝑝), from the equalities (5) and (6), we obtain (𝐴̂𝑟3 𝑟1 ) =
𝑔0 𝑔 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 −𝑟 ∏𝑛𝑖=1 𝑔𝑖𝐻𝑖 .
−1
Therefore, we have extracted a valid BBS+ signature (𝐴̂𝑟3 𝑟1 ,𝑒) on (𝑠𝑘𝐵𝑙𝑖𝑛𝑑 − 𝑟,{𝐻𝑖 }𝑛𝑖=1).
Under the q-SDH assumption, the user therefore holds a valid BBS+ signature (i.e., a VC) on
the {𝐻𝑖 }𝑖∈𝐷 . The {𝐻𝑖 }𝑖∈𝐷 disclosed to the RP have thus been certified by the IdP and presented
by the user to whom the corresponding VC was issued (as the user knows the key
𝑠𝑘 = 𝑠𝑘𝐵𝑙𝑖𝑛𝑑 − 𝑟). ∎
We will now demonstrate that BBS# VPs are perfectly anonymous (everlasting privacy).
Anonymity of VPs
𝐵𝑙𝑖𝑛𝑑
Proof. Let 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } , 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ) be the
𝑖∈𝒟
𝐵𝑙𝑖𝑛𝑑
VP received by the RP where 𝜎𝐼𝑠𝑠𝑢𝑒𝑟 = (𝐴̂, 𝐵̅, 𝐷, Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 ).
Let's show that this VP could have been generated by any user 𝒰’ (different from the actual
user 𝒰 who generated the above VP but sharing the same attributes disclosed by 𝒰 to the RP)
who obtained a VC from the IdP with the key pair (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 ).
Let VC’ = (𝐴’, 𝑒’) be the VC obtained by 𝒰’ on their public key 𝑃𝐾′ = 𝑔 𝑠𝑘′ (where their private
key 𝑠𝑘′ is exclusively managed by their WSCD) and their attributes (𝑎′1 , 𝑎′2 , 𝑎′3 , … , 𝑎′𝑛 ).
As 𝐷 is an element of a cyclic group of order 𝑝 and 𝐷 is different from 1 (the neutral element
of this group, considered here as multiplicative), this implies that there exists an integer 𝑟′2 ∈
𝐻′
𝑍𝑝∗ such that 𝐷 = 𝐵′𝑟′2 where 𝐵′ = 𝑔0 𝑃𝐾 ∏𝑛𝑖=1 𝑔𝑖 𝑖 and 𝐻′𝑖 = ℋ(𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎′𝑖 ∥ 𝐾𝑖 ).
For the same reasons, there exists an integer 𝑟′1 ∈ 𝑍𝑝∗ such that 𝐴̂ = 𝐴′𝑟′1 ×𝑟′2
Let’s show that 𝐵̅ = 𝐴̂−𝑒′ 𝐷𝑟′1 = 𝐴̂ 𝑠𝑘𝐼 .

By definition : 𝐴′𝑠𝑘𝐼+𝑒′ = 𝐵′ and thus 𝐴′𝑠𝑘𝐼 = 𝐵′𝐴′−𝑒′ .

29
Which therefore implies that :
′
𝐴̂ 𝑠𝑘𝐼 = 𝐴′𝑟′1 ×𝑟′2 ×𝑠𝑘𝐼 = 𝐵′𝑟′1 ×𝑟′2 𝐴′𝑟′1 ×𝑟′2 ×(−𝑒 ) = 𝐷 𝑟′1 𝐴̂−𝑒′ = 𝐵̅
Furthermore, there exists 𝑟′ ∈ 𝑍𝑝∗ such that 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 = 𝑔 𝑠𝑘+𝑟 = 𝑔 𝑠𝑘′+𝑟′. 𝜎𝑈𝑠𝑒𝑟 is therefore a valid
ECSchnorr signature produced with the private key 𝑠𝑘 ′ + 𝑟 ′ = 𝑠𝑘 + 𝑟 (mod 𝑝).
𝐻 −𝐻′𝑖 𝑟′
Let’s also show that 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑖∈𝒟 𝑔𝑖 𝑖 = 𝐷 𝑟′3 ∏𝑖∉𝒟 𝑔𝑖 𝑔 where 𝑟′3 = 𝑟′−1
2 (mod 𝑝).
𝐻′ 𝐻′
By definition, 𝐷 𝑟′3 = 𝐵′ = 𝑔0 𝑃𝐾′ ∏𝑛𝑖=1 𝑔𝑖 𝑖 = 𝑔0 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 ∏𝑛𝑖=1 𝑔𝑖 𝑖 𝑔−𝑟′. Therefore, we have the
equality above since 𝐻𝑖 = 𝐻′𝑖 for 𝑖 ∈ 𝒟 (since we have assumed that 𝒰′ shares the same
disclosed attributes to the RP as 𝒰)
Given that the proof Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 is witness-indistinguishable, it reveals no information (even to an
attacker with unbounded computational power) about the elements (𝛼, 𝛽, 𝛾, 𝛿, {𝜏𝑖 }𝑖∉𝒟) ) used to
produce the proof Π𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 .
Therefore, an attacker, even with unbounded computational power, has no way to determine
whether 𝒰 or 𝒰′ generated the 𝑉𝑃 = (𝑃𝐾𝐼 , 𝑃𝐾′𝐼 , 𝑃𝐾𝐵𝑙𝑖𝑛𝑑 , {𝔄𝒹}𝑖∉𝒟 ,{𝐻𝐼𝐷𝑖 ∥ 𝐼𝐷𝑎𝑖 ∥ 𝑎𝑖 ∥ 𝐾𝑖 } ,
𝑖∈𝒟
𝐵𝑙𝑖𝑛𝑑
𝜎𝐼𝑠𝑠𝑢𝑒𝑟 , 𝜎𝑈𝑠𝑒𝑟 ). This concludes the demonstration that BBS# VPs offer perfect anonymity
(Everlasting Privacy). ∎

30
4. Performances
In this section, we compare the efficiency (in terms of key size and computation time for
credential issuance and presentation) of BBS# with that of ISO mDL/SD-JWT (instantiated with
the ECDSA signature scheme) and PQ-ABC, a recent post-quantum anonymous credential
scheme that will appear at the forthcoming ACM CCS conference [AGJ+24].

Space Efficiency (bytes)

Private Key Public Key Credential Presentation

(Holder, Issuer) (Holder, Issuer) Size Proof

BBS# (32, 32) (32, 32) 128 416+𝑈 × 32

SD-JWT and
(32, 32) (32, 32) 64 64+𝑁 × 32
mDL1

PQ-ABC2 (0,25 KB, 10 KB) (2,38 KB, 47, 53 KB) 6,81 KB 79,58 KB3

▪ 𝑁: number of signed attributes

▪ 𝑈: number of undisclosed attributes
1. with ECDSA used on both the Holder and Issuer’s side
2. [AGJ+24]
3. For 𝑈 = 10 tI

Time Efficiency*

Credential Present Present Verify

Issuance1 WSCD Wallet Presentation

𝑁 𝔼𝐺1 1 𝔼𝐺1 (𝑁+9) 𝔼𝐺1 (𝑁+12) 𝔼𝐺1

BBS#
(630 𝜇s ) (50 ms) (3,8 ms) (1,4 ms)

SD-JWT and 1 𝔼𝐺1 1 𝔼𝐺1 2 𝔼𝐺1

-
mDL2 (63 𝜇s ) (50 ms) (126 𝜇s )

PQ-ABC3,4 400ms N.A5 355 ms 147 ms

*We do not consider operations in 𝑍𝑝 since their cost is negligible compared to the other ones

▪ 𝔼𝐺1 : cost of an exponentiation /scalar multiplication in 𝐺1 :

▪ 63 𝜇s on an Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
▪ 0,2 ms on a Samsung S10e over the secp256r1 curve
▪ 50 ms on a Javacard 2.2.2 SIM card, Global Platform 2.2 compliant, over the secp256r1 curve
▪ 𝑁: number of signed attributes
▪ 𝑈: number of undisclosed attributes

1. N =10
2. with ECDSA used on both the Holder and Issuer’s side
3. Benchmarked on an Intel Core i7 12800H CPU running at 4.6 GHz
4. [AGJ+24]
5. Current WSCD do not support the computations involved in [AGJ+24]

31
5. Anonymous credential protocols in a pre-quantum and post-
quantum world
In this section, we compare the three aforementioned protocols (BBS#, ISO mDL with ECDSA,
and PQ-ABC) in terms of the level of security and privacy they provide.

Security and Privacy

Credential VP Unlinkability VP Unlinkability VP

Unforgeability Colluding RPs Colluding RP-Issuer Unforgeability

Unconditional2 Unconditional
BBS# NPQ Assumption1 NPQ Assumption
(Everlasting Privacy) (Everlasting Privacy)

SD-JWT3 Unknown Assumption Unknown Assumption

No No
and mDL (NPQ security) (NPQ Security)

PQ-ABC PQ Assumption PQ Assumption PQ Assumption PQ Assumption

1. Classical assumption (i.e. not PQ) , namely q-SDH

2. Even against an adversary with unbounded computational power
3. With ECDSA used on both the Holder and Issuer’s side

32
6. Conclusion
What we aimed to demonstrate through this technical report is that it is possible to achieve SSI
transactions, particularly for EUDIW eIDAS 2.0, which are not only secure and certifiable at
the highest level but also provide strong (optimal) privacy protection for EUDIW users.
Furthermore, what seems to be new is that this can be accomplished by leveraging existing
security infrastructures that are already deployed everywhere, whether in smartphones or in
the cloud. This result demonstrates that by using proven and conceptually simple
cryptographic primitives (such as "classic" Schnorr-style ZKPs or "Sigma Protocols"), it is
possible to combine the following seemingly contradictory properties: security (including
hardware), full unlinkability, and everlasting privacy..

The proposed solution is, of course, not an end in itself but rather the foundation upon which
privacy-respecting services, picularly those based on the principle of maximum minimization,
could be built (by relying on relatively simple ZKPs). Therefore, we encourage the entire eIDAS
2.0 ecosystem to provide feedback on the proposed solution and to consider these ZKPs for
their true value, especially in a privacy-by-design approach, both for the definition of the ARF
and for eIDAS 2.0 services that are built on top of it.

7. References
[ABBT16] Roberto Araújo, Amira Barki, Solenn Brunet, Jacques Traoré: Remote
Electronic Voting Can Be Efficient, Verifiable and Coercion-Resistant.
Financial Cryptography Workshops 2016: 224-232

[AGJ+24] Sven Argo, Tim Güneysu, Corentin Jeudy, Georg Land, Adeline Roux-
Langlois, Olivier Sanders: Practical Post-Quantum Signatures for Privacy.
IACR Cryptol. ePrint Arch. 2024: 131 (2024)

[ASM06] Man Ho Au, Willy Susilo, Yi Mu: Constant-Size Dynamic k-TAA. SCN 2006:
111-125

[BBDT16] Amira Barki, Solenn Brunet, Nicolas Desmoulins, Jacques Traoré: Improved
Algebraic MACs and Practical Keyed-Verification Anonymous Credentials.
SAC 2016: 360-380

[BBS04] Dan Boneh, Xavier Boyen, Hovav Shacham: Short Group Signatures.
CRYPTO 2004: 41-55

[BBS24] The BBS Signature Scheme, published 31 January 2024 : The BBS
Signature Scheme (identity.foundation).

[BFL20] Balthazar Bauer, Georg Fuchsbauer, and Julian Loss. A classification of

computational assumptions in the algebraic group model. In Daniele
Micciancio and Thomas Ristenpart, editors, CRYPTO 2020, Part II, volume
12171 of LNCS, pages 121–151. Springer, Heidelberg, August 2020.

[BLL+22] Fabrice Benhamouda, Tancrède Lepoint, Julian Loss, Michele Orrù, Mariana
Raykova: On the (in)Security of ROS. J. Cryptol. 35(4): 25 (2022)

33
[BPW12] David Bernhard, Olivier Pereira, Bogdan Warinschi: How Not to Prove
Yourself: Pitfalls of the Fiat-Shamir Heuristic and Applications to Helios.
ASIACRYPT 2012: 626-643

[Bra97] Stefan Brands: Rapid Demonstration of Linear Relations Connected by

Boolean Operators. EUROCRYPT 1997: 318-333

[CDL16] Jan Camenisch, Manu Drijvers, Anja Lehmann: Anonymous Attestation Using
the Strong Diffie Hellman Assumption Revisited. IACR Cryptol. ePrint Arch.
2016: 663 (2016)

[Che06] Jung Hee Cheon. Security analysis of the strong Diffie-Hellman problem. In
Serge Vaudenay, editor, EUROCRYPT 2006, volume 4004 of LNCS, pages
1–11. Springer, Heidelberg, May / June 2006.

[CP92] David Chaum, Torben P. Pedersen: Wallet Databases with Observers.

CRYPTO 1992: 89-105

[CS97] J. Camenisch and M. Stadler. Efficient group signature schemes for large
groups (extended abstract). In CRYPTO 97, volume 1294, pages 410–424.
Springer, 1997.

[FS86] Fiat, A., Shamir, A.: How to prove yourself: Practical solutions to identification
and signature schemes. In: Advances in Cryptology — Crypto’86. Volume 263
of Lecture Notes in Computer Science., Springer-Verlag (1986) 186–194

[GMR85] Shafi Goldwasser, Silvio Micali and Charles Rackoff. The knowledge
complexity of interactive proof-systems (extended abstract). In 17th ACM
STOC, pages 291–304. ACM Press, May 1985.

[ISO14888] ISO/IEC 14888-3:2018. Techniques de sécurité IT — Signatures numériques

avec appendice. Partie 3: Mécanismes basés sur un logarithme discret.

[ISO18370] ISO/IEC 18370-2:2016. Technologie de l'information — Techniques de

sécurité — Signatures numériques en aveugle. Partie 2: Mécanismes fondés
sur le logarithme discret.

[JSI96] Markus Jakobsson, Kazue Sako, Russell Impagliazzo: Designated Verifier

Proofs and Their Applications. EUROCRYPT 1996: 143-154

[JY09] David Jao and Kayo Yoshida. Boneh-Boyen signatures and the strong Diffie-
Hellman problem. In Hovav Shacham and Brent Waters, editors, PAIRING
2009, volume 5671 of LNCS, pages 1–16. Springer, Heidelberg, August 2009.

[Ped92] Torben P. Pedersen. Non-interactive and information-theoretic secure

verifiable secret sharing. In Joan Feigenbaum, editor, CRYPTO’91, volume
576 of LNCS, pages 129–140. Springer, Heidelberg, August 1992.

[TZ23] Stefano Tessaro, Chenzhi Zhu: Revisiting BBS Signatures. EUROCRYPT (5)
2023: 691-721

34