— Dr. Nuttawut Kongsuwan, Finema & QTFT

— Rachata Tosirisuk, Thailand Internet Exchange, Finema & QTFT

- Anonymous Credential Part 1: Brief Overview and History
- Anonymous Credential Part 2: Selective Disclosure and CL Signature
- Anonymous Credential Part 3: BBS+ Signature

As discussed in in Part 1 of this series, selective disclosure and an anonymous credential (Anoncred) relies on an efficient signature scheme that supports multiple messages with a single signature. One such signature scheme is known as **CL signature** that is named after its Jan Camenisch and Anna Lysyanskaya in a series of papers from 2001 to 2004 [CL01, CL02, CL03, CL04]. CL signature popularized Anoncreds, and it also served as a cryptographic building block in Identity Mixer (Idemix) and Hyperledger Indy projects.

Here, we first discuss two important concepts for understanding CL signature—the discrete logarithm problem and cryptographic commitment—and then outline subprotocols of CL signature. Finally, the application of CL signature on selective disclosure is discussed.

Given real numbers y and a, the value of m from an expression y=a^m can be calculated by evaluating a logarithm of y to base a, *i.e.* m=log_a(y). The term m = log_a(y) can be easily calculated when all a,m,y>=0 are Real numbers. However, when y and a are members of **a sufficiently large** **discrete** **group** G, finding m becomes extremely difficult. This is known as the discrete logarithm problem, which serves as the foundation of many modern cryptographic protocols, including CL-signature.

A **commitment scheme** is a cryptographic protocol that allows one to commit to a message while keeping it hidden to other parties, with the ability to reveal the committed value later. A commitment scheme that is considered here is known as the Pedersen commitment. In its *simplified version*, a commitment c of a message m is simply c = a^m where a is a member of **a large discrete group** G. The commitment c can be sent to another person, called the receiver, and the receiver will not be able to calculate m due to the hardness of the discrete logarithm problem.

At a later time, the message m can then be revealed to the receiver. The receiver then verifies that the message m is really the one that was committed by checking that the expression a^m is really equal to c.

A more detailed discussion on Pedersen commitment can be found here.

Originally, CL signature is based on the strong RSA (SRSA) assumption. As a result, its key sizes are very long to provide sufficient security against ever faster prime factorization algorithms and computers. There has been an improvement on this issue by using paring-based cryptography.

Here, for simplicity, we discuss the signing algorithm base on the strong RSA (SRSA) assumption. We consider two parties, namely an **issuer**, a** holder**, and a **verifier**. The **issuer** signs a signature on blocks of messages (or attributes) for the **holder**, and the **holder** then shares the messages together with the signature to the **verifier**. We assume that the holder has L messages m_1, m_2, m_3, …, m_L. The CL signature scheme consists of 3 steps:

- Key generation
- Signature generation
- Signature verification

First, the issuer generates two random numbers {p,q} that form a secret key. From the private key p and q , the issuer calculates

and then generate L+2 random numbers from a **quadratic residue** modulo n

The variables a_1, a_2, a_3, ..., a_L, b, c, n form a public key for the issuer.

First, the issuer generates a random prime e and random number s . Given input L messages m_1, m_2, m_3, …, m_L, the issuer computes the value v such that

The variables(e, s, v) forms the signature of the input L messages m_1, m_2, m_3, …, m_L .

Given the signature (e,s,v) of messages m_1, ..., m_L the holder can use the issuer’s public key a_1, a_2, a_3, ..., a_L, b, c, n to verify that the signature is generated correctly by checking that the LHS and RHS of the following equation are equal.

After the holder is in possession of the signature, the holder can then share the messages m_1, ..., m_L and the signature (e,s,v) with the verifier. The verifier can then use the issuer’s public key and follow the same signature verification algorithm to verify that

- the signature is really signed by the issuer
- the messages m_1, ..., m_L have not been changed or tampered with since the moment the signature is generated.

This process allows the messages to be tamper-proof.

In the signature generation and signature verification algorithms above, the holder has an option to either:

- directly send a message m_i to the signer/verifier, and the signer/verifier can then compute (a_i ^ m_i) mod n; or
- compute (a_i^m_i) mod n, which is the commitment of m_i, and sends it to the signer/verifier.

Given the hardness discrete logarithm problem, the signer/verifier will not be able to compute the holder’s m_i from the commitmenta_i^m_i mod n. Therefore, the holder can selectively disclose which message(s) (or attributes) are revealed to the issuer/verifier. As a result, the issuer is capable of generating a valid signature *without full knowledge of all messages*. Similarly, the verifier is capable of verifying that the holder really possesses the messages even if the verifier does not gain full knowledge of all messages.

For example, the holder possesses 3 messages m_1, m_2, m_3. The holder could reveal m_1, m_2 and send a_3^m_3 mod n to the issuer to sign. Once the holder obtains the signature from the issuer. The holder can reveal m_2 and sends a_1^m_1 mod n, a_3^m_3 mod n together with the signature to the verifier. The verifier can finally verify that the holder possesses valid m_1, m_2, m_3—that have not been tampered with—even without the knowledge of m_1, m_3.

These capabilities laid the foundation for realizing and popularizing Anoncreds. In the final part of this series, we discuss a sophisticated signature scheme for Anoncreds, which is known as the BBS+ signature.

*[CL01] Jan Camenisch and Anna Lysyanskaya. Efficient non-transferable anonymous multi-show credential system with optional anonymity revocation. In Birgit Pfitzmann, editor, Advances in Cryptology — EUROCRYPT 2001, volume 2045 of Lecture Notes in Computer Science, pages 93–118. Springer Verlag, 2001.*

*[CL02] Jan Camenisch and Anna Lysyanskaya. Dynamic accumulators and application to efficient revocation of anonymous credentials. In Moti Yung, editor, CRYPTO, volume 2442 of Lecture Notes in Computer Science, pages 61–76. Springer, 2002.*

*[CL03] Jan Camenisch and Anna Lysyanskaya. A signature scheme with efficient protocols. In Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano, editors, Security in Communication Networks, Third International Conference, SCN 2002, volume 2576 of Lecture Notes in Computer Science, pages 268–289. Springer Verlag, 2003.*

*[CL04] Jan Camenisch and Anna Lysyanskaya. Signature schemes and anonymous credentials from bilinear maps. In Matthew K. Franklin, editor, Advances in Cryptology — CRYPTO 2004, volume 3152 of Lecture Notes in Computer Science, pages 56–72. Springer Verlag, 2004.*

Anonymous Credential Part 2: Selective Disclosure and CL Signature was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>— Dr Nuttawut Kongsuwan, Finema & QTFT

— Rachata Tosirisuk, Thailand Internet Exchange, Finema & QTFT

- Anonymous Credential Part 1: Brief Overview and History
- Anonymous Credential Part 2: Selective Disclosure and CL Signature
- Anonymous Credential Part 3: BBS+ Signature

Despite its huge successes as core building blocks for anonymous credential (Anoncred) systems, the CL signature relies on the strong RSA assumption of which security is based on the practical difficulty of factoring the product of two large prime numbers. To achieve sufficient security, CL signature-based Anoncred systems require long keys and signatures, resulting in slow cryptographic operations.

On the other hand, the BBS+ signature relies on the q-Strong Diffie Hellman (q-SDH) assumption with pairing-based elliptic-curve cryptography that requires much shorter keys and signatures than the CL signature to achieve the same level of security. This article explains *simplified* mathematics for understanding BBS+ signature, as described in [CDL16], where all formal proofs are neglected.

Here, we assume the knowledge of the following topics:

- Abstract algebra, including group theory and finite fields
- Elliptic-curve cryptography over finite fields
- Discrete logarithm problem
- Diffie–Hellman assumption (DH), including Computational Diffie–Hellman assumption (CDH) and Decisional Diffie–Hellman assumption (DDH)

First, we describe bilinear pairing, which is an underlying mathematical operation for generating and verifying the BBS+ signature. This is followed by a brief explanation for q-SDH assumption. Three operations of the BBS+ signature are explained: namely (i) key generation, (ii) signature generation, and (iii) signature verification. Finally, we discuss the signature proof of knowledge as an essential privacy-preserving mechanism for the BBS+ signature.

Unlike the CL signature that generates keys and signatures from two large prime numbers, the BBS+ signature uses pairing-friendly elliptic-curves.

First, we define cyclic groups G_1 and G_2 of the same prime order p. Given g_1 as a generator of G_1 and g_2 as a generator of G_2, we can generate another third group G_T of also the prime order pusing a bilinear map e as follows:

The bilinear map e is a **polynomial-time computable map **that generates an element in G_T such that:

, where g1, g2 and g_T are generators of groups G_1, G_2 and G_T. The bilinear map e also satisfies the following properties

- Bilinearity:

- Non-degeneracy:

In the BBS+ signature, G_1 and G_2 are defined as groups of points on elliptic curves over finite fields. Therefore, they are written as **additive **groups. On the other hand, G_T is a finite field, and we can write G_T as a **multiplicative **group. Given P_1and P_2 as points on G_1 and G_2, we could rewrite the map e as follows:

As a result, we can write the e pairing as:

The security of the BBS+ signature is based on the q-Strong Diffie-Hellman (q-SDH) assumption [TS10]. This assumption was first defined by Boneh and Boyen in [BB04]. It is based on the Diffie-Hellman assumption over two cyclic groups G_1 and G_2 of prime order p where there **might be** an efficiently computable homomorphism ψ (in polynomial time) from G_2 to G_1.

Following the previous sections that explain bilinear pairing and the q-SDH assumptions as building blocks, this section discusses the BBS+ signature. This signature scheme consists of three operations: (i) key generation, (ii) signature generation, and (iii) signature verification.

Given L messages (m_1, m_2, ..., m_L):

the BBS+ signature produces a public key that consists of L+2 variables(w, h_0, h_1, h_2, ..., h_L):

The signature σ of the messages can then be defined by 3 variables(A, e, s:

The BBS+ keys can be generated as follows:

- Generate L+1 random elements (h_0, h_1, h_2, ..., h_L) from group G_1:

- Generate a random number x as a secret key:

- Compute w:

(w, h_0, h_1, h_2, ..., h_L) are used as a public key:

Given the secret key x, a BBS+ signature of the messages (m_1, m_2, ..., m_L) can be generated as follows:

- Generate random numbers e and s:

- Compute A:

The signature σ is defined as(A, e, s):

Given

- The messages (m_1, m_2, ..., m_L)
- The public key (w, h_0, h_1, h_2, ..., h_L)
- The signature σ

We can verify the signature by computing and comparing the LHS and RHS following equation:

This equation works because of the property of the bilinear pairing:

The prover can prove the knowledge of the signature **without revealing the signature itself **by using non-interactive zero-knowledge proof of knowledge. The prover can also choose to only disclose some of the messages to the verifier, hiding the rest of the messages.

We define the revealed messages as:

where D be the set of messages that the prover chooses to reveal to the verifier. Similarly, we define the hidden messages as:

The prover computes a signature proof of knowledge, denoted as SPK, which can be made non-interactive with the Fiat-Shamir heuristic [FS87] in the random oracle model [BR93] [CDL16].

The signature proof of knowledge consists of two operations: proof generation and proof verification

Given the secret key x and the signature σ, the prover can generate the signature proof of knowledge (SPK) by:

- Generate random numbers r_1, r_2:

- Set r_3, A', \bar{A}, d and s' as follows:

From the variables above, the prover can create the signature proof of knowledge (SPK) π [CDL16]

The SPK π consists of two subproofs, concatenated with a logical AND operator ^. The first subproof proves the validity of the signature σ whereas the second subproof proves the validity of the hidden attributes.

Finally, the proof of knowledge corresponds to (A', \bar{A}, d, \pi), which can then be sent to a verifier.

It is important to emphasize that the proof reveals neither the signature σ nor any of its variables (A, e, s). Hence, a verifier who receives the proof will be unable to obtain or derive the signature σ from the proof.

The verifier can verify the proof as follows:

- Verify that:

where 1_{G_1} is the identity of the group G_1. Note that the probability that the above equation does not hold is negligible for an honest signer.

- Compute and compare the LHS and RHS of the following equation:

- Verify the SPK π, as shown above.

Compared to the CL signature, the BBS+ signature has much shorter keys and signatures for a comparable level of security. As a result, the BBS+ signature enables fast implementation for anonymous credentials. It can be used in combination with signature proof of knowledge to hide some of credential attributes/messages in a zero-knowledge fashion.

Recently, the open-source code for implementing BBS+ signature is available in Hyperledger Ursa. This is known as Anonymous Credential 2.0 and is documented extensively here.

The BBS+ signature will also soon be available in Finema’s Identity Wallet! We are excited to see how this technology will make an impact to the society in the coming years.

[FS87] Amos Fiat and Adi Shamir. How to prove yourself: Practical solutions to identification and signature problems. In Andrew M. Odlyzko, editor, CRYPTO’86, volume 263 of LNCS, pages 186{194. Springer, Heidelberg, August 1987.

[BR93] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In V. Ashby, editor, ACM CCS 93, pages 62{73. ACM Press, November 1993.

[BB04] Dan Boneh and Xavier Boyen. Short signatures without random oracles. In Christian Cachin and Jan Camenisch, editors, EUROCRYPT 2004, volume 3027 of LNCS, pages 56–73. Springer, Heidelberg, May 2004.

[BBS04] Dan Boneh, Xavier Boyen, and Hovav Shacham. Short group signatures. In Matthew Franklin, editor, CRYPTO 2004, volume 3152 of LNCS, pages 41–55. Springer, Heidelberg, August 2004.

[GPS08] Steven D. Galbraith, Kenneth G. Paterson, and Nigel P. Smart. Pairings for cryptographers. Discrete Applied Mathematics, 156(16):3113–3121, 2008.

[TS10] Naoki Tanaka & Taiichi Saito. (2010). On the q-Strong Diffie-Hellman Problem. IACR Cryptology ePrint Archive. 2010. 215.

[CDL16] Jan Camenisch, Manu Drijvers, and Anja Lehmann. Anonymous attestation using the strong Diffie Hellman assumption revisited. In TRUST, volume 9824 of Lecture Notes in Computer Science, pages 1–20. Springer, 2016.

Anonymous Credential Part 3: BBS+ Signature was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>— Dr. Nuttawut Kongsuwan, Finema & QTFT

— Rachata Tosirisuk, Thailand Internet Exchange, Finema & QTFT

- Anonymous Credential Part 1: Brief Overview and History
- Anonymous Credential Part 2: Selective Disclosure and CL Signature
- Anonymous Credential Part 3: BBS+ Signature

An** anonymous credential** (Anoncred), which is also known as an **attribute-based credential** (ABC), is a concept for a digital credential that provides a credential holder maximal privacy and an ability to selectively disclose their personal information.

“the user can later prove to a third party that she possesses a credential containing a given attribute or role without revealing any other information stored in the credential.”

— IBM Research

For example, a credential contains five attributes: name, nickname, address, date of birth and ID number. Using an Anoncred, the credential holder can choose to reveal and hide any of their attributes to a third party. A zero-knowledge proof could also be used with the Anoncred to, e.g., prove that their age is above 20 years old.

In recent years, an Anoncred is also considered as a verifiable credential containing a set of credential attributes, called claims. An Anoncred has the following properties.

**Selective Disclosure**: the credential holder is capable of minimally disclosing credential attributes (claims) while proving the validity of all hidden attributes.**Verifiable Authorship**: credential verifiers can validate who the credential issuer and holder are.**Tamper-evident**: credential verifiers can detect whether the credential has been altered.**Anonymity**: the credential holder is capable of maintaining thier anonymity while verifiably presenting the credential.**Un-likability**: the credential issuer is incapable of tracking how and where the credential is presented.**Non-correlating**: a credential cannot be correlated by values other than the credential’s attributes (claims). As a result, credential verifiers are incapable of tracking whether a specific credential has been presented multiple times to the same or different verifiers.

Given the frequency of data breaches and the increasingly tightening data privacy regulations such as GDPR, the concept of Anoncreds is becoming more relevant than ever. In recent years, several big companies and startups have also started adopting Anoncreds, especially members of Decentralized Identity Foundation (DIF).

Here, we give a brief overview of theories for Anoncred and its application, of which we divide into four eras:

- 1985–2004: Theoretical Development
- 2005–2009: U-Prove vs Idemix
- 2010–2015: ABC4Trust Consortium
- 2016–2019: The Rise of Hyperledger
- 2020 and Beyond: The Age of Self-Sovereign Identity

To some extent, these eras are arbitrary since there are in fact significant overlaps. We also note that this article does not aim nor even attempt to provide an exhaustive review of this evolving field. This article wishes to give a friendly starting point for developers and cryptographers who want to apply Anoncreds in their work.

To the best of the authors’ knowledge, the original idea of Anoncreds was first invented and studied by David Chaum in 1985[Cha85], which defined general concepts based on information theoretic arguments. This idea was further developed by Ivan Bjerre Damgard in 1990 [Dam90] and Stefan Brands in 1995 [Bra95a, Bra95b]. Brands also compiled his work in his book [*Bra00*] which laid the foundation for **U-Prove**.

In a series of publications from 2001 to 2004 [CL01, CL02, CL03, CL04], Jan Camenisch and Anna Lysyanskaya developed an efficient signature scheme, known as **CL signature**, based on the strong RSA (SRSA) assumption. This scheme supports blocks of messages with a single signature and served as a building block for **Identity Mixer** (Idemix). However, since CL signature is a RSA-based signature scheme, its keys must be very long to provide sufficient security against ever faster prime factorization algorithms and computers.

This problem was addressed in 2004 where Dan Boneh, Xavier Boyen and Hovav Shacham developed a short group signature scheme, known as **BBS signature **[BBS04], which is based on the Strong Diffie-Hellman assumption.** **This signature scheme is built on pairing-based elliptic-curve cryptography and consequently requires much shorter keys, compared to RSA-based signature scheme. The BBS signature scheme was later improved in [ASM06, CDL16] and is now known as the **BBS+ signature scheme**.

It is also important to note a recent scheme for Anoncreds by a team at Microsoft Research. In 2020, they published a white paper that discusses implementation of Anoncreds using a transparent Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK), called Spartan [S20, CGSB20].

After early theoretical development, two competing realizations of Anoncreds emerged, namely U-Prove and Idemix.

Based on cryptographic protocols designed by Stefan Brands, U-Prove was developed a user-centric identity management software that allows for digital identity to be efficiently tied to tamper-resistant devices such as smart cards [MV11]. Brands also founded Credentica in 2004 that further developed U-Prove. U-Prove was later acquired by Microsoft in 2008. U-Prove SDK is available in C#, Java and JavaScript whereas its specification can be found here [PZ13, Paq13].

In 2002, Jan Camenisch and Els Van Herreweghen from IBM presented Identity Mixer (Idemix), an anonymous credential system based on the CL signature scheme that allows anonymous yet authenticated and accountable transactions [CH02]. Idemix source code in Java and specifications are available here [IBM09, IBM13].

Idemix have been integrated into several projects, including IRMA and Hyperledger Fabric. The design and implementation of Idemix also laid the groundwork for Anonymous Credential 1.0 in Hyperledger Indy and Hyperledger Ursa.

The goal of ABC4Trust is to address the federation and interchangeability of technologies that support trustworthy yet privacy-preserving Attribute-based Credentials (ABC).

Attribute-based Credentials for Trust (ABC4Trust) was an EU-funded project from 2010–2015 that defined a common, unified architecture and delivered open reference implementations of ABC (Anoncred) systems. Its consortium includes both Microsoft and IBM, and ABC4Trust integrates both U-Prove and Idemix into its architecture [SR14, RCS15]. It also included the two pilot projects in Patras, Greece and Söderhamn, Sweden. ABC4Trust promoted collaborations between the big players and accelerated advances in the field of Anoncreds. Its deliverables can be found here, and its Java source code is available in this repository.

With the rise (and hype) of the blockchain technology, the Linux Foundation founded Hyperledger, which is a collection of open-source blockchain projects. Hyperledger projects with Anoncreds are Hyperledger Fabric, Indy and Ursa.

Hyperledger Fabric is the modular, permissioned blockchain framework designed for enterprise blockchain platforms. IBM cofounded Hyperledger Fabric in 2016 and has been its main contributors. Idemix was imported to the project and has been used to provide strong authentication as well as privacy-preserving features such as transactor anonymity and transaction unlinkability.

An independent project that utilizes Anoncred was also developed by Evernym and Sovrin Foundation for building a Self-sovereign Identity (SSI) platform. In 2017, their code was later donated to Hyperledger, which became the Hyperledger Indy project. Cryptographic modules in Hyperledger Indy was then imported to Hyperledger Ursa, a project for managing shared cryptographic libraries.

The first version of the Anoncred system in Hyperledger Indy and Ursa is based on CL signature and is called Anonymous Credentials 1.0, of which cryptographic foundations are very similar to Idemix. We note that Jan Camenisch — one of the authors of CL signature and Idemix’s lead cryptographer—also helped with this project.

Identity Mixer is not directly re-implemented by Sovrin, but its cryptographic foundations are very similar. Sovrin’s implementation includes most of its extended features such as predicates, multi-credential, revocation and advanced issuance. One of the researchers who helped to create Identity Mixer is on Sovrin’s Technical Governance Board and has offered insight to keep the implementations aligned on goals and methods.

— Daniel Hardman, Secretary of Sovrin Technical Governance Board (September, 2018)

In 2019, Sovrin published the second version of their Anoncred system, called Anonymous Credentials 2.0, which was led by Michael Lodder, Brent Zundel, Dmitry Khovratovich. This version is based on BBS+ signature on BLS12–381 curve that allows for much smaller keys and signatures without sacrificing security.

As of October 2020, Anoncreds have become a hot topic in Self-Sovereign Identity (SSI) community as Anoncreds enable crucial privacy-respecting mechanism for an SSI platform. CL signature has been recommended as one of the standard cryptographic proofs for Verifiable Credentials. Recently, Tobias Looker (Mattr) and Orie Steele (Transmute) also contributed to a draft for the W3C Recommendation on BBS+ signature for the Linked Data Proof specification.

Several startups have adopted Anoncreds for their products. These include Trinsic, MATTR, Transmute and Finema, to name a few. Anoncreds are now an exciting field that could make a real difference to the soon self-sovereign world.

In Part 2, we will explore mathematics of selective disclosure and CL signature. This is followed by mathematics of BBS+ signature in Part 3.

*[Cha85] David Chaum. Security without identification: Transaction systems to make big brother obsolete. Communications of the ACM, 28(10):1030–1044, October 1985.*

*[Dam90] Ivan Bjerre Damgard. Payment systems and credential mechanism with provable security against abuse by individuals. In Shafi Goldwasser, editor, Advances in Cryptology — CRYPTO ’88, volume 403 of Lecture Notes in Computer Science, pages 328–335. Springer Verlag, 1990.*

*[Bra95a] Stefan Brands. Restrictive Binding of Secret-Key Certificates. In Guillou L.C., Quisquater JJ., editor, Advances in Cryptology— EUROCRYPT ’95, volume 921 of Lecture Notes in Computer Science, pages 231–247. Springer Verlag, 1995.*

*[Bra95b] Stefan Brands. Secret-key certificates. Technical Report CS-R9510, CWI, September 1995.*

*[Bra00] Stefan Brands. Rethinking public key infrastructures and digital certificates: building in privacy. MIT Press, 2000.*

*[CL01] Jan Camenisch and Anna Lysyanskaya. Efficient non-transferable anonymous multi-show credential system with optional anonymity revocation. In Birgit Pfitzmann, editor, Advances in Cryptology — EUROCRYPT 2001, volume 2045 of Lecture Notes in Computer Science, pages 93–118. Springer Verlag, 2001.*

*[CH02] Jan Camenisch and Els Van Herreweghen. Design and implementation of the idemix anonymous credential system. Proceedings of the 9th ACM conference on Computer and communications security, 2002.*

*[CL02] Jan Camenisch and Anna Lysyanskaya. Dynamic accumulators and application to efficient revocation of anonymous credentials. In Moti Yung, editor, CRYPTO, volume 2442 of Lecture Notes in Computer Science, pages 61–76. Springer, 2002.*

*[CL03] Jan Camenisch and Anna Lysyanskaya. A signature scheme with efficient protocols. In Stelvio Cimato, Clemente Galdi, and Giuseppe Persiano, editors, Security in Communication Net- works, Third International Conference, SCN 2002, volume 2576 of Lecture Notes in Computer Science, pages 268–289. Springer Verlag, 2003.*

*[BBS04] Dan Boneh, Xavier Boyen and Hovav Shacham. Short Group Signatures. In M. Franklin, editor, Advances in Cryptology — CRYPTO 2004, volume 3152 of Lecture Notes in Computer Science, pages 41–55. Springer Verlag, 2004.*

*[CL04] Jan Camenisch and Anna Lysyanskaya. Signature schemes and anonymous credentials from bilinear maps. In Matthew K. Franklin, editor, Advances in Cryptology — CRYPTO 2004, volume 3152 of Lecture Notes in Computer Science, pages 56–72. Springer Verlag, 2004.*

*[ASM06] Man Ho Au, Willy Susilo, and Yi Mu. Constant-size dynamic k-TAA. International conference on security and cryptography for networks. Springer, Berlin, Heidelberg, 2006.*

*[IBM09] Bichsel, Patrik, Carl Binding, Jan Camenisch, Thomas Groß, Tom Heydt-Benjamin, Dieter Sommer, and Greg Zaverucha. Cryptographic protocols of the identity mixer library. IBM Research,* *Tech. Rep. RZ 3730, Tech. Rep., 2009.*

*[MV11] Wojciech Mostowski and Pim Vullers. Efficient U-Prove implementation for anonymous credentials on smart cards. International Conference on Security and Privacy in Communication Systems. Springer, Berlin, Heidelberg, 2011.*

*[Paq13] Christian Paquin. U-Prove Technology Overview V1.1 (Revision 2). Microsoft Corporation, 2013.*

*[PZ13] Christian Paquin and Greg Zaverucha. U-Prove Cryptographic Specification V1.1 (Revision 3). Technical Report, Microsoft Corporation, 2013.*

*[IBM13] Specification of the Identity Mixer Cryptographic Library Version 2.3.4. IBM Research — Zurich, 2013.*

*[SR14] Ahmad Sabouri and Kai Rannenberg. ABC4Trust: protecting privacy in identity management by bringing privacy-ABCs into real-life. IFIP International Summer School on Privacy and Identity Management. Springer, Cham, 2014.*

*[RCS15] Kai Rannenberg, Jan Camenisch and Ahmad Sabouri. Attribute-based credentials for trust. Identity in the Information Society, Springer, 2015.*

*[CDL16] Jan Camenisch, Manu Drijvers, and Anja Lehmann. Anonymous attestation using the strong diffie hellman assumption revisited. International Conference on Trust and Trustworthy Computing. Springer, Cham, 2016.*

*[S20] Srinath Setty. Spartan: Efficient and general-purpose zkSNARKs without trusted setup. Microsoft Research, 2020.*

*[CGSB20] Melissa Chase, Esha Ghosh, Srinath Setty, and Daniel Buchner. Zero-knowledge credentials with deferred revocation checks. Microsoft Research & Microsoft Identity, 2020.*

Anonymous Credential Part 1: Brief Overview and History was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>As exemplified at the end of the previous part of this article series, credentials are devised to attest to a variety of affairs. Some are to attest to competence. Some are to attest to qualifications. Some are to attest to entitlements. However, here we concern ourselves with only those that serve to attest to identity.

Identities are akin to possessions. Each has its rightful owner. By claiming that their attributes are of such and such values, an entity claims to own the identity those attributes constitute. Such identity claim must be **corroborated **adequately, so that the verifier to whom it is presented knows without doubt, or within a tolerable level of doubt, that the identity genuinely belongs to the entity. The process of backing up identity claims is referred to as **identity corroboration**. Credentials play a major role in this process.

An issuer who provides credentials for identity corroboration is also referred to as an **identity provider**, commonly abbreviated as **IdP**. To be pedantic, such issuer does not provide an entity with an identity; it provides a credential that substantiates the entity’s ownership of an identity, within an applicable context. The verifier in that context, who relies on identity corroboration before conducting any business with the entity, is referred to as a **relying party**, or **RP** for short.

There are two ways in which identity corroboration is proven, depending on where an identity in question resides. To talk about the first, it is helpful to be reminded that it is possible for an identity to be a representation of a fictitious entity. When you encounter an entity along with their identity claim for the very first time, you must make sure that such fabrication is not the case. The process of proving that an identity whose ownership is being claimed corresponds to a real-world entity, and indeed the claimant, is called **identity proofing**. The identity in question is external or unknown to you at the time of identity claim.

If, however, the identity in question is internal or already known to you, identity corroboration is proven by comparing identity information presented by the claimant against existing records at your disposal. The process of proving that an identity corresponds to one previously established within the context is called **authentication**.

This might sound like a convoluted way of defining authentication, which is commonly understood as just what happens when one successfully logs into some computer system with a valid pair of username and password. In fact, authentication is broader than that. A less obvious example is when you check in at your regular dentist’s; when the receptionist asks for your patient card, you are being authenticated. Another familiar example is when you unlock your smartphone with your fingerprint; that act of unlocking is authentication.

A pair of username and password is one example of **authentication factors**. It is of the type that is usually referred to as “something you know”. A patient card is also an authentication factor, of the type called “something you have”. Another type is “something you are”, of which an example is a fingerprint.

At this point, you may ask how an external identity becomes internal. When you encounter a claimant and their identity claim for the first time, you perform identity proofing. Once that gives a positive result, you **onboard** them into the domain of known entities. An unknown identity becomes known, associated with existing attributes that you may record (such as the fingerprints), and new attributes that you may assign (such as an identifier of some kind, or a pair of username and password) for various purposes, such as internal reference and subsequent authentication.

Authentication factors are therefore inherent or assigned attributes whereby known identities are anchored to real-world entities.

Identity corroboration in the digital age leverages digital credentials. As they are basically electronic documents, their IdPs have to lay out their data in some structure that prospective RPs are able to parse, and the holders have to be able to store them in repositories of some kind on electronic devices. The context must provide some infrastructure that dictates, for example, appropriate communication protocols between the parties.

Variation in the specifics of how that is implemented gives rise to a vast landscape of digital identity systems. We shall find out more about them in Part 4.

Identity 101: Basic Terminology Part 3 was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>Our core products rely on public-key cryptography based on elliptic curves. In general, its implementation varies by a number of aspects that those in charge of software architecture would have to specify, usually by choosing from a variety of established standards. Our choice involves the so-called secp256k1 domain parameters. The question of what domain parameters are is beyond the scope of this article, but it suffices to say that one of what they dictate is the specific equation that public-key values must satisfy.

That equation is

This seemingly simple-looking equation comes with immense power. Public-key values are integers *x* and *y* that satisfy the equation. If you try a few numbers, you may have the impression that the existence of such pairs of integers does not seem likely. In practice, the equation is used with a condition that some numbers are treated as* *equivalent (similar to when you treat 1.00 p.m. and 13.00 hrs. as denoting the same time). Its detail is however not relevant. What is is that the above equation is the starting point of our new logo.

Plotting it yields the following elliptic curve:

If we also draw two more of the same curve quadrupled in size and shift them around, we obtain an area that looks like the letter F:

With the aspect ratio of 1, that area is too slender for our taste, so we fatten it by stipulating that its width to height ratio is 4²:5². In other words, its width is made 4²*a* units for some number *a*, and its height is 5²*a* units:

We would like to stylize this further by dividing the area into three parts. How should we specify the borders? Below is a sketch.

At this stage, it would be useful to label some notable parts. Point *A *and point* B* are the saddle points of the initial elliptic curve we started with. Also part of it is segment *BC*. Point *D* is where two of the elliptic curves intersect.

There is only one way we can scale our original elliptic curve uniformly and shift it around in such a way that the resulting curve passes through point *D* while maintaining its upper saddle point at point *A*. This can be computed.

Looking at the labeled sketch again, you might feel tempted to draw the lower border as an arc of some vertical ellipse whose upper vertex lies at point *B*. That is exactly what we are going to do. But first, we note that segment *BC* is not an elliptic arc. For the change of curvature at point *B* to look as smooth as possible, the vertical ellipse we are going to construct must deviate from segment *BC* as little as possible. We, therefore, compute the ellipse by minimizing such deviation, while also demanding that it passes through point *D*.

Combining all the segments together, we obtain the logomark, filled with three blue shades of our liking. Our logo has always been blue, and it remains so.

As to the wordmark, we want it to be unassuming and not visually competing with the logomark. A grotesque sans-serif typeface is most appealing to us. We end up settling on Helvetica Now by Monotype, the latest modernized version of Helvetica. The letter E is made xi-like for a futuristic touch. The placement and other attributes, such as the height and tracking, of the wordmark are as defined below.

We share with you the thinking behind the logo because we feel that it reflects many of our core values, namely creativity, precision, and attention to detail, which underlie all of our products. Our technical team consists of not only software engineers but also physicists and mathematicians. Their ideas contributed to the logo design process, hence all the geometrical considerations.

You can find out more about our decentralized identity and identity proofing solutions on our website: finema.co.

The new logo is the beginning of so much else to come. In the upcoming weeks, we will be rolling out new material on the website, including technical documentations, demos, and whitepapers that incorporate the new visual language. You can expect to hear about our exciting products and projects in the near future.

Stay tuned!

Finema’s Logo: A Geometric Story was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>In 1993, Peter Steiner, a cartoonist and a novelist, submitted his doodle of two dogs sitting in front of a computer to The New Yorker. Little did he know that this cartoon was far ahead of its time and would later become the most reproduced New Yorker cartoon in the magazine’s history. Almost 30 years after its publication, we now live in the digital age where one can connect to the other side of the world in less than a second. **“On the Internet, Nobody Knows You’re a Dog”** remains just as relevant or perhaps becomes even more relevant than ever.

According to Javelin report, that identity fraud hits new victim every two seconds. In the United States, for example, 1 in 3 adults reported that they have experienced identity theft. More than 160,000 people also reported that fraudulent credit card accounts were opened with their information.

Identity theft has become commonplace due to the prevalence of large-scale data breaches and the massive amount of digital footprint that we regularly leave on the internet. To combat the rise of identity theft and cybercrime, organizations and corporates must determine “Is the customer actually the customer?” and require the means to verify the identity of their legitimate customers. Such means are called *Identity Proofing*.

Is the customer actually the customer?

Identity proofing ensures that users attempting to access services are actually authorized to do so. It also prevents fraudsters from gaining an access to sensitive data of legitimate customers. Some businesses, such as those in the financial sector, are required by law to verify the identities of their customers. This is known as a know-your-customer (KYC) process that aims to counter money laundering and other illegal financial activities.

The most primitive form of identity proofing requires a face-to-face verification. This is inapplicable for most of online transactions and communications that could take place at the opposite side of the world. A remote alternative is the German model that replaces in-person meetings with two-way video calls. However, video call verification is still time-consuming and expensive.

In recent years, many modern approaches for remote identity proofing have been developed. These approaches provide fast and inexpensive identity verification. Below, we review different methods for remote identity proofing.

**Document-centric****methods**involve uploading pictures of physical documents, such as national ID cards and passports. Taking selfie is often required for comparison with a photo ID to ensure that a genuine holder of the ID is present. Anti-spoofing mechanisms such as liveness detection are also crucial although they could erode customer experience. In most organizations, uploaded documents are reviewed manually by humans whereas automation with machine learning can be utilized at the cost of lowered security.**Data-centric****methods**use data from public records and trusted entities such as the credit bureaus. Alternatively, publicly available data can be used, such as those from social media. Recorded data of existing customers can also be used. However, this method could be fooled by identity theft and synthetic identity.**Digital-attribute****methods**use device data such as time zone setting or device ID numbers such as MAC addresses and IMEI numbers. Mobile phone numbers and email addresses also are used as persistent evidence of identity. Near-field communication (NFC) could also be used for identity proofing.**Behavioral biometrics methods**track how users use their device, including mouse movement, screen swipe, typing cadence and device orientation. Several behaviors of users can be combined to form their behavioral signature, which is recognized by a machine learning program.

An individual proofing method is unlikely to serve as a reliable and definite evidence of identity. Orchestration of several identity proofing techniques can be used to provide more secure services to customers. Data from different methods above could also be combined, linked and analyzed by a machine learning program.

In identity proofing, there is always a tradeoff between security and customer experience. An identity proofing process that is too elaborate could drive customers away. Hence, modern organization must not only meet the compliance regulations but also provide user-friendly services and great customer experience.

Our previous blog posts discuss decentralized digital identity and how this emerging technology could drastically change our society. With verifiable credentials, digital documents can be made tamper-evident since they can be verified by using digital signature. However, such a verifiable process assumes that credentials are issued to legitimate users from the beginning. If an issuer is deceived by a fraudulent user, valid digital credential could be issued with invalid information inside. Hence, it is essential for credential issuers to perform identity proofing and verify the identity of their users.

For example, a user may be required to provide a document-centric evidence of their identity to gain an access to a service for the first time. Once the evidence is provided to the service provider, the user can then use his/her private key to authenticate. Another use case is when the private key is lost or stolen. Automated identity proofing could then be used to identify the real owner of the key, preventing hackers from revoking the old key and obtaining the new key themselves.

In summary, identity proofing will be increasingly important in the current technology landscape where every aspect of our lives is becoming digitized. In the near future, people, organizations, electronic devices and even pets will be given identities in digital forms. To stay competitive in this every changing world, modern organizations must decide the right tradoff between achieving an appropriate level of security and providing smooth customer experience.

Karen Lewison and Francisco Corella, Rich Credentials for Remote Identity Proofing, Pomcor (2017).

Paul A. Grassi *et al*., Digital Identity Guidelines: Enrollment and Identity Proofing*, *NIST Special Publication 800–63A (2017).

Jonathan Care and Akif Khan, Market Guide for Identity Proofing and Corroboration, Gartner (2019).

Remote Identity Proofing for Digital Identity was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>The coronavirus pandemic continues in an international public health emergency and has caused severe social and economic disruption around the world, including one of the largest recessions in history. It leads to a postponement or cancellation of sports, religion, politics, culture, and the widespread supply shortage causing panic buying. Schools, universities, and colleges are closed in many countries, misinformation about the virus spreads online and there are incidents of foreign terror and discrimination.

The New Normal — After COVID-19, to live a normal life will require a new tool or new scheme that helps people getting close to each other without increasing another pandemic wave risk. When the economy reopens, this is an essential tool that will serve as preventive and facilitation measures for an inevitable social problem and self-verification required.

The system is designed to meet the highest level of protection of personal data, in accordance with the GDPR, PDPA, or any privacy regulation, thus assuring both the protection of populations and the respect of the right to privacy. Finema delivers identity, credential, and trust technologies in close collaboration with regional governments and enterprises.

Download full paper (PDF)

Let’s get involved! we are ready to work and collaborate with any organizations, either medical services, tools & technologies, or government authorities. Come join us and make this ecosystem happened.

Contact us: hi@finema.co

COVID-19 Control System (CCS) was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>In the offline world, our identity can be officially defined by some authorities in the form of **paper credentials. **We can then present these credentials to other parties for their products and services. For example, your identity can be defined by your government in the form of a national ID card, and you can then present your ID card to a bank to open a new savings account. Similarly, a university could issue a graduation certificate to you, and the certificate can be presented in job applications. Once you are given a credential, you are the one in control.

This is not the case in the online world. Currently, your online identity is often in the form of multiple usernames and passwords across different websites. This means your online identity has been largely controlled and siloed by big corporates such as Google, Facebook and Twitter. As a result, individuals have very little control of their own digital identity and are perpetually at risk of losing their sensitive information to cyberattacks. However, this practice too shall pass due to the emergence of the blockchain technology.

A blockchain enables immutable and decentralized storage of tamper-evident logs, such as a ledger in the case of Bitcoin. Similarly, a blockchain can be used to immutably store** proofs of identity**, giving rise to a new paradigm of **decentralized digital identity**. Such an identity blockchain could provide a common trust domain for digital identity and reduce the roles of the big corporates in managing their clients’ personal information.

In the same manner as paper credentials, decentralized digital identity allows** **individuals to keep digital credentials in **identity wallets **on their devices. To make sure the credentials can neither be forged nor modified, the **proofs** of the credentials are stored in the blockchain. Once a credential is presented to another party, the credential can be easily verified by checking its proof in the blockchain. This process makes credentials and their presentations **tamper-evident, **and as a result they are called** verifiable credentials** and **verifiable presentations**, respectively.

It is important to repeat that blockchain simply stores the proofs of the credentials, not the credentials themselves. This is to ensure that the credentials are kept secure and no one can steal personal information by simply gaining an access to the blockchain.

The figure below demonstrates how a verifiable credential and its presentation can be implemented. For example, the government (**issuer**) could issue a digital ID card (**verifiable** **credential**) to you (**user**) and then publish its cryptographic hash (**proof**) to the blockchain. You then present your ID card (**verifiable presentation**) to a bank (**verifier**) to open a new savings account. The bank then verifies that the digital ID card is indeed valid by checking that the cryptographic hash of the presented credential is identical to the hash published in the blockchain.

In paper-based credentials, the verifier must contact the issuer in order to verify if the presented credential is valid. With a decentralized digital identity platform, this is unnecessary as long as the verifier has access to the identity blockchain.

Decentralized digital identity with verifiable credentials and presentations will revolutionize how we handle, present and think about our own identity, allowing for a faster and more secure digital world.

Verifiable Credential and Verifiable Presentation for Decentralized Digital Identity was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>Now imagine that you have a super power to prove to the bartender that you are indeed older than 20 years old without revealing anything else about yourself — not even your birth year. This super power can, in fact, be achieved using zero-knowledge proof and CL-signature protocols. These protocols could give everyone the ability to **minimally** **disclose** their personal information and take full control of their own identity.

Zero-knowledge proof cryptography is a family of cryptographic protocols which allows one party (**user **or **prover**) to prove to another party (**verifier**) that something is true without revealing its underlying information. For example, one zero-knowledge proof protocol, called Sigma protocol, proves that a prover knows a number without revealing what that number is, i.e. a proof of knowledge. Another protocol, called hash chains, can be used to prove that a prover is older than the legal drinking age without revealing how old the prover actually is.

Here, we give a simple demonstration of how a zero-knowledge proof works using a Rubik’s cube. Suppose that a prover, named Alice, would like to prove to a verifier, named Bob, that she knows how to solve a Rubik’s cube. However, she doesn’t want to show him how she solves it. Bob then gives Alice an unsolved Rubik’s cube. Alice then turns around and solves the Rubik’s cube without letting Bob see how she solves it. Finally, Alice turns back and returns the solved Rubik’s cube to Bob. Assume that Bob remembers his Rubik’s cube so well it is impossible for Alice to cheat by preparing another solved Rubik’s cube in advance. Bob can be (almost) 100% certain that Alice knows how to solve the Rubik’s cube even though Bob learns nothing (i.e. zero-knowledge*)* about how she solves it. Note that he can never be 100% certain since there is always a small chance that Alice twists the Rubik’s cube randomly and accidentally solves it. However, such a random incident is highly unlikely. If Bob still doesn’t trust Alice, he could repeat the process several times until he is satisfied.

A zero-knowledge proof protocol constructs a mathematical proof that is similar to solving a Rubik’s cube. In the modern blockchain ecosystems, zero-knowledge proofs have been growing in popularity. Examples include Zcash which implements zero-knowledge proofs on cryptocurrency transactions and Ernst & Young’s Nightfall on Ethereum start contracts.

CL-signature is an efficient signature scheme, which is invented by Jan **C**amenisch and Anna **L**ysyanskaya in a series of papers [1, 2, 3]. This protocol enables an **attribute-based credential system** where users can control how each piece (**attribute**) of their personal information is presented digitally. Given a credential schema (or template), a user can flexibly choose to reveal or hide the credential attributes in any combination. CL-signature can also be used together with zero-knowledge proofs to enhance privacy.

For example, a **user** called John applies for a digital national ID card from the government (**issuer**). The government defines the ID cards’ schema with attributes: **Name**, **Nickname**, **Address**, **Date of Birth** and **ID Number**. The attribute Nickname is, in fact, optional and does not need to be presented during the application. With CL-signature, John has the choice to bind his nickname to his ID card without revealing it to his government. Although the government does not know his nickname, the nickname is digitally signed together with the whole credential. John could then apply for a membership at an age-restricted board game cafe (**verifier**) that asks for new members’ nicknames. John uses CL-signature to hide all his information in his ID card except for his nickname and creates a zero-knowledge proof showing that he is indeed above 20 years old.

In the case of decentralized digital identity, for example, the ID card’s cryptographic hash could be immutably stored in the identity blockchain, which prevents any modification on the issued ID card. As a result, John cannot change any attribute in his ID card, including his nickname, unless he applies for a new card. The ID card can also be presented multiple times to different verifiers with any combination of revealed and hidden attributes.

Here, we present a few example use cases:

**Health records:** a hospital could issue a user a digital health record. The user could then use the health record to apply for a VISA to the UK. Using CL-signature, the user could show the UK embassy that she is negative for a tuberculosis test without revealing other information in the health record. The user can then use the same health record to show to an airline that she is allergic to peanuts, again without revealing anything else.

**Streaming media: **In the near future, streaming services like Netflix and Disney+ would be able to accurately check their customers’ age for their age-restricted contents. Their users do not need to compromise their personal information by using a zero-knowledge proof showing that they are above the restricted age.

**Job applications**: Suppose that you have recently graduated from your country’s top university and are applying for a backend developer position in a blockchain startup. Of course, your prospective employer wants to know how well you did in computing-related courses. However, they do not need to know whether you have an *F* in your classic literature exam. With CL-signature, you could hide the grades of some subjects and construct a zero-knowledge proof showing that your total GPA is above the threshold that the company requires.

Applying zero-knowledge proof and CL-signature on decentralized digital identity allows for an efficient attribute-based digital identity system where users have the ability to **minimally disclose** their personal information. Such an ability is essential in the current digital world where identity thefts are commonplace.

We are striving towards a better world. The world where privacy not a privilege but a basic human right that belongs to all individuals.

Minimal Disclosure of Identity with Zero-Knowledge Proof and CL-Signature was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>When you meet your neighbor Mrs. Lovelace by chance at a shopping mall, you know the person is her because the person looks like her and acts like her. Not so? Yes, because some of the person’s attributes are visible to you, some are audible whereas others may even be olfactible. Because of these familiar attributes, you are quite sure to a large extent that the entity interacting with you is of Mrs. Lovelace’s identity, and therefore it is actually Mrs. Lovelace, not somebody else. Well, there is of course the off chance that the person is an impersonator, but for the purpose of saying hello, you do not need to ascertain more attributes. She might think you are weird if you ask her to produce her ID card. Even if you do, that small chance does not completely disappear, as you have no means of checking on the spot if the ID card is counterfeit, unless of course you are so weird as to carry around the equipment capable of doing that, but I digress.

Imagine how Mrs. Lovelace’s identity must have been conveyed to you when you met her for the very first time. Assuming you were not blind, you could see some of her inherent attributes, such as her hair, eyes, and skin color. Some other attributes, on the other hand, were not readily apparent and had to be told, like her name or age.

In identity parlance, when someone tells you of certain attributes of an entity (such as themselves), it is said that they **claim **or **assert** that those attributes are of such and such values. For example, your sweet neighbor might happen to be introducing herself to you one morning while claiming or asserting that her last name is Lovelace, and her age is 64.

Those **claims** or **assertions** may or may not be true, but in the social context, their veracity may not be consequential. In some other context, however, it may be important for Mrs. Lovelace to assure the other party — say, Veronica — that she is telling the truth about herself. How could she do that?

One way to do it is for Mrs. Lovelace to get a third party involved whom Veronica trusts. Suppose that Veronica trusts that Isaac would never lie to her, and Mrs. Lovelace happens to know Isaac too. Mrs. Lovelace could then ask Isaac to write a letter that makes assertions about her on her behalf. She then presents that letter to Veronica. Veronica checks if the letter indeed comes from Isaac, by maybe ringing him or inspecting his handwriting and signature. Once the authenticity of the letter is proven, Veronica believes those written claims.

That letter is an example of a **credential**, which is a set of claims about one entity made on their behalf by a third party. Mrs. Lovelace is the **subject** of the credential. Isaac is the **issuer** of the credential, whereby the identity of Mrs. Lovelace is **attested**.

There is still one problem. Since Veronica has not known Mrs. Lovelace before, how could she know that the entity bearing the letter — the **holder** of the credential — is the same as the subject?

The letter has to contain some attributes that Veronica can **verify**. For example, the letter could contain a realistic drawing of Mrs. Lovelace’s face, so that Veronica can check if the holder has the same face; or the letter could contain Mrs. Lovelace’s signature, so that Veronica can check if the holder can reproduce it. Because of this verification process, Veronica is called the **verifier** of the credential.

Note that Mrs. Lovelace has many options for presenting the letter to Veronica. She could present the original letter directly. Alternatively, she could make a photocopy of it, leave the original copy at home, and present the photocopy instead. She could also redact some parts of the photocopy if she deems them unnecessary. (For example, she may have second thoughts about disclosing her age.)Generally, a credential has many **presentations.**

At this point, I am sure you can think of many other examples of credentials. A **driving permit **is a credential issued by a government agency attesting to an entity’s competence to drive, in the form of a plastic card. A **passport** is a credential issued by a government agency attesting to an entity’s identity for international travel, in the form of a booklet. A** diploma **is a credential issued by an educational institution attesting to an entity’s qualifications, in the form of a piece of paper. A **movie ticket **is a credential issued by a cinema attesting to an entity’s entitlement to admission to one of the auditoria, in the form of a voucher. These are physical realizations of credentials.

Credentials may exist in the digital form too. How can **digital credentials** be issued, held and verified? Stay Tuned for Part 3.

Identity 101: Basic Terminology Part 2 was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>