Binding of Endpoints to Identifiers by On-Chain Proofs
Diego Pennino, Maurizio Pizzonia, Andrea Vitaletti, Marco Zecchini
BBinding of Endpoints to Identifiers by On-ChainProofs
Diego Pennino
Engineering Dept.Roma Tre University
Roma, [email protected]
Maurizio Pizzonia
Engineering Dept.Roma Tre University
Roma, [email protected]
Andrea Vitaletti
Engineering Dept.Sapienza
Roma, [email protected]
Marco Zecchini
Engineering Dept.Sapienza
Roma, [email protected]
Abstract —In many applications, identity management (IdM)is used to associate a subject public key with an endpoint atwhich the subject can be contacted (telephone number, email,etc.). In decentralized applications based on distributed ledgertechnologies (DLTes), it is desirable for the IdM to be decen-tralized as well. Currently, endpoints are either verified by whoneeds it, which is impractical in DLT-based applications, or by acentralized authority, which contrasts with the spirit of DLTes.In this paper, we show two DLT-based protocols to prove theassociation between a subject and an endpoint in a decentralizedmanner, contributing in filling the gap of the current IdMapproaches with respect to decentralization. Our protocols arecompatible with a wide variety of endpoints. We analyze thesecurity of our protocols and evaluate their performance andcost against the common approaches.
I. I
NTRODUCTION
The main purpose of identity management (IdM) is to bindan identifier of a subject (usually a public key) with attributes,claims, entitlements, or properties of that subject [1]. In thispaper, we focus on the process to bind a subject identifier withan endpoint of a communication technology (or channel ). Inpractice, an endpoint identifies a way to contact the subject.Examples of endpoints are web URLs, IP addresses, emailaddresses, telephone numbers, postal mail addresses, etc.Traditionally, IdM has been designed over of centralisedarchitectures and it consequently requires trust in third parties.This might be a problem when an IdM is used in applicationsdesigned for Distributed Ledger Technologies (DLTs) that aresupposed not to rely on any centralized source of trust. Asan example, a subject could store in-chain his/her consent toreceive phone calls for marketing purposes. This can be easilyimplemented storing the consent on-chain in the form of atransaction originating from one of the subject public key(s),but there must be some evidence that the subject’s public keyis bound to his/her phone number.While for some applications the possession of an endpointmay be a value per se, in certain countries, certain endpointsare bound by law to a legal person or a natural person. Forexample, this is the case for telephone numbers in Italy. Inthese cases, the endpoint verification provides a big addedvalue. A subject can prove the binding of one of its identi-fiers with an endpoint by sending or receiving messages onit. This technique is widely used in the context of multi-factor authentication. However, currently, its adoption in adecentralized approach requires endpoint verification to beindependently performed by each verifier that is interestedin this information. This might be a problem, if verifiers aremany, since each verification is time and resource consuming(see Section III).
Contribution of the paper.
In this paper, we present twoDLT-based protocols to perform a decentralized verificationprocess capable to write in-chain the proof (or certification )of the binding between a subject identifier and an endpoint,providing a substantial contribution to a decentralized IdMapproach. That proof, can then be used to certify the bindingwithout the burden of the many single verification processes.We analyze the security of our approach against miscertifica-tion and denial of service attacks. We also analyze the practicalapplicability of the proposed protocols with several kinds ofendpoints.
Structure of the paper.
In Section II, we review the state ofthe art. In Section III we review basic verification processesand introduce notation. In Section IV, we describe the twoprotocols to write in-chain the proof of the binding and, inSection V, we analyze their security. In Section VI, we presenta first evaluation of our approach and, in Section VII, wediscuss applicability aspects with several kinds of endpoints.II. S
TATE OF THE A RT IdM is standardized by ISO [1] and there regulations aboutit (see, for example, eIDAS [2] a regulation of the EuropeanUnion). Protocols and standards related to IdM systems aresurveyed in [3]. Identities can be useful across several or-ganizations. For this reason, single sign-on approaches, suchas Facebook connect, are adopted [4], but usually relays oncentralized architectures. The idea of realizing IdM on top ofDLTes is a further step toward making IdM independent froma specific organization. In private/permissioned DLTes somekind of trust among participants exists, hence implementingIdM over them does not introduce new conceptual problems.The
Self-Sovereign Identity (SSI) approach, surveyed here [5], a r X i v : . [ c s . D C ] M a y nvisions solutions in which subjects should be able to cre-ate and control their own identity, without relying on anycentralized authority. In this context, public/permissionlessDLTes are fundamental tools. W3C has ongoing efforts tostandardize the building blocks of SSI. Decentralized Iden-tifiers (DIDs) [6] are controlled by subjects and possiblysecurely stored in DLTes. DIDs are linked with
DID documents where attributes are listed. Certain attributes are associatedto
Verifiable Claims/Credentials ( VC ) [7] which allow thebinding between the identifier and the attributes. Our approachcan be seen as a tool to implement a verifiable claim to provethe binding between a subject identifier and an endpointA realization of this framework is backed by the Decen-tralised Identity Foundation . The relation between DIDs andeIDAS is analyzed in [8].One of the first attempts to design an IdM system deployedon the blockchain trying to accomplish self-sovereign iden-tities is Namecoin [9]. The uPort system [10] makes use ofEthereum smart contracts and allows subjects to record simplestatements about them. Sovrin [11] is an open source identitynetwork built on a permissioned DLT to manage DIDs inwhich only trusted institutions take part in consensus proto-cols. ShoCard [12] is a digital identity card for mobile devices.It binds an existing trusted credential (e.g., a passport), withadditional identity attributes by means of Bitcoin transactions.The last three systems are also analyzed and compared in [13].Sora [14] and DNS-IdM [15] are two further recent proposals.III. B ACKGROUND AND N OTATION
Each subject S on a blockchain is associated with atleast one pair (cid:104) p, s (cid:105) , where p is a public key and s isthe corresponding secret key. We denote by [ m ] s or [ m ] S the signature of a string m performed by S using s . Eachpublic key of S can be used as a pseudonym for S when S have to be mentioned in any transaction recorded in theblockchain. Subject S can easily prove its association with p by considering a publicly known random string r (a challenge ),never used before, whose generation is not controlled by S ,and providing [ r ] s . In interactive protocols with two parties, r can be generated by the party that needs the proof. In theblockchain context, r is a cryptographic hash of some new piece of data. For example, r can be the cryptographic hashof the last block or a string derived by a new transaction to besubmitted (usually a transaction to be valid should be differentfrom all previous ones).In this paper, we are concerned with a verifier V that intendsto assess that a subject S possesses an endpoint E . The vastmajority of techniques to achieve this result can be traced backto the following two interactive protocols that assumes that V already has an alternative communication mean M with S . Protocol 1: V chooses a challenge code c and sends it to endpoint E .2) S receives c at endpoint E and sends back c to V by M . https://identity.foundation/ Protocol 2: V chooses a challenge code c and sends it to S by M .2) S sends back c to V from endpoint E .These protocols can be adapted to bind the fact that S possesses E with a key pair (cid:104) p, s (cid:105) of S . In the adaptedprotocols, S sends back to V a signed version of c ( [ c ] s ),actually proving that the subject that knows s also possesses E . In this variation, c is essentially a challenge. In the restof this paper, we refer to the adapted versions of Protocols 1and 2 as basic protocols .In a blockchain context, we potentially have a large numberof subjects and verifiers. We recognize that the basic protocolshave the following drawbacks. • Each time a different verifier intends to assess if S possesses E , a new verification should be performed. Thismight be a serious problem if verifiers are many and/orverification has a cost for S . • Each verification requires to set up an interactive protocol.This means that either S should always be on-line or V should be willing to wait for S to reply to the challenge.In the spirit of the blockchain, we look for a decentralizedsolution to this certification problem that does not suffer thesetwo drawbacks.IV. DLT-B ASED P ROOFS FOR B INDINGS E NDPOINTS TO S UBJECTS A subject S intends to obtain a proof that (s)he owns anend-point E , to be shown to any interested verifier . In thissection, we show two blockchain-based protocols to achievethis goal in a decentralized manner.We assume that the communication technology of E cansupport the exchange of a message at least as large as a (pos-sibly signed) challenge, i.e., a large enough random number.In Protocol 3, the proof-of-possession of E is a proof that S can send from E a signed challenge to a number of othersubjects. In Protocol 4, vice-versa, the proof-of-possession isa proof that S can receive at E a challenge from a number ofother subjects.Formally, S intends to obtain a credible proof of a pair (cid:104) p, E (cid:105) meaning that S , with public key p , owns E . We canalso write (cid:104) S, E (cid:105) with the same meaning. When S obtains theproof for (cid:104) S, E (cid:105) , we say that S is certified . For simplicity,in the following, we assume that all subjects that are alreadycertified are always on-line , in the sense that they can1) interact with E by receiving messages at E or sendingmessages from E ,2) access the blocks of the blockchain including the last one,3) monitor the transactions accepted in the blockchain andreact to them.We relax some of these assumptions in Section IV-C. We nowintroduce our two protocols. A. Certifying that a Subject Can Send a Message from anEndpoint
In our frist protocol, subject S with public key p obtains theproof-of-possession of endpoint E by sending signed messages ubject S Blockchain All certified subjectsor all committee members1. Certification Request R = (cid:104) p, E (cid:105) Block containing R Block containing R
2. Each certified subject checks if it belongs to the committee for R .3. All committee members and S compute the random challenge Q ConcurrentlyConcurrently by S and each already certified subjects S sends P = [ Q ] S from endpoint E to all committee members.5. c checks P c publishes acceptance [ P ] c for R ConcurrentlyConcurrently by each committee member c Fig. 1. Sequence diagram for Protocol 3, where S sends signed messagesto committee members from endpoint E (see Step 4). from E to a number of different other subjects. This idea isdeveloped in Protocol 3. The associated diagram is shownin Figure 1. At the end of the protocol, the certificate ofpossession is published in the blockchain. Protocol 3: Certification Request.
Subject S creates certificationrequest R = (cid:104) p, E (cid:105) (where p is a public key of S ) andpublishes [ R ] S in the blockchain. Request R reaches allparticipants as its block is broadcasted.2) Committee Selection.
A committee of k certified sub-jects, is randomly selected, on the basis of R , followingthe procedure detailed below. This is autonomously per-formed by whoever needs to know the committee compo-sition, comprising S and all DLT participants. Dependingon the communication technology, the endpoints of thecommittee members may be needed, they can be obtainedfrom their certificates published in the blockchain.3) Random Challenge . From the block B where R isaccepted all committee members and S computes Q =hash( R | B ) .4) Response from E . S sends from E to all committeemembers the proof P = [ Q ] S that S can send a messagefrom E .5) Committee checks.
Each committee member c that re-ceives P checks its signature and value of Q .6) Acceptance.
If checks are successful, c publishes on theblockchain its acceptance [ P ] c related to R . a) Certificate Verification: A verifier can check the va-lidity of the acceptance transactions related to R and countthem to see if they are k , or above a certain threshold ¯ k ≤ k (see Section IV-C). b) Identifiers and summarization: It is useful to assignto each new certified subject S a sequential identifier , denoted id( S ) . The assignment can be done by a consensus rule toautomatically commit a transaction, in a subsequent block, that states and summarizes the association (cid:104) S, E, id( S ) (cid:105) for each R = (cid:104) S, E (cid:105) . This should be done when enough acceptancetransactions for R are committed. c) Committee selection procedure: We assume the net-work comprises N certified subjects. We assume their iden-tifiers to be from 0 to N − , i.e., there are no holes inthe sequence of the identifiers. For a certification request R ,we select the committee C = { c , . . . , c k } , by selecting theidentifiers id( c i ) of its members. Suppose that b is the hash ofthe block in which the certification request R is committed.We use b as a shared source of randomness.We need a deterministic method that, for each i ∈{ , . . . , k } , randomly selects an id( c i ) ∈ { , . . . , N − } . Thismethod should depend on R and b and the selection probabilityshould be uniformly distributed among all already certifiedsubjects. It is desirable for this association not to select thesame subject twice. However, if N (cid:29) k , the probability ofaccidentally doubly selecting the same subject is negligible.A very simple approach is to select committee membersaccording to the following rule id( c i ) = hash( i | R | b ) mod N. Note that, given any deterministic association method, assoon as a certification request R is published, each certifiedsubject can autonomously understand if (s)he was selected forthe committee to certify R . Further, anyone can easily checkif c i is part of the committee for R as well as enumerate thewhole committee. B. Certifying that a Subject Can Receive a Message at anEndpoint
In our second protocol, a subject S obtains the proof-of-possession of endpoint E by receiving challenges at E froma number of different other subjects. This idea is developedin Protocol 4. The associated diagram is shown in Figure 2.At the end of the protocol, the certificate of possession ispublished in the blockchain. Protocol 4: Certification Request.
Subject S creates certificationrequest R = (cid:104) p, E (cid:105) (where p is its public key) andpublishes [ R ] S in the blockchain. Request R reaches allparticipants as its block is broadcasted.2) Committee Selection.
As in Protocol 3, a committeeof k members is randomly selected, denoted C = { c , . . . , c k } .3) Challenges Generation . Each member c i of C generatesa random partial challenge Q i .4) Challenges to E . Each c i sends Q i to endpoint E , where S is supposed to be able to receive it.5) Proof Publication.
Subject S combines the partialchallenges received to obtain the complete challenge Q | . . . | Q k . S publishes on the blockchain the proof P = [ Q | . . . | Q k | R ] S that S has received all partialchallenges and hence that S can read messages at E . ubject S Blockchain All certified subjectsor all committee members1. Certification Request Block containing R Block containing R c checks if it belongs to the committee for R ConcurrentlyConcurrently by each certified subject c c i sends Q i to endpoint E
3. Generatepartial challenge Q i ConcurrentlyConcurrently by committee subjects c i with i = 1 , . . . , k
5. Publish proof [ Q | . . . | Q n | R ] S
6. Disclosure of Q i ConcurrentlyConcurrently by each committee subject c i Fig. 2. Sequence diagram for Protocol 4 in which committee members sendchallenges to endpoint E (see Step 4). Challenges Disclosure.
After P is published, each c i makes Q i public by a suitable transaction, also specifyingthat it is related to R . a) Certificate Verification: A verifier can check the valid-ity of the proof P and then be sure that the association (cid:104) p, E (cid:105) holds. This verification can be performed by the followingprocedure, which takes as input P = [ Q | . . . | Q k | R ] S .1) Check that R = (cid:104) p, E (cid:105) is in the blockchain.2) Check that P is correctly signed by public key p .3) For each i = 1 , . . . , k • In the blockchain, look for the transaction containingthe challenge disclosure for Q i related to R performedby c i . • Check that the challenge disclosure for Q i appears after P in the history.4) If all the previous checks are successful, the proof P isvalid and the association (cid:104) S, E (cid:105) is certified . b) Identifiers and summarization: As for Protocol 3, asequential identifier id( S ) should be assigned to each newlycertified subject S . The assignment can be done by a consensusrule in which DLT nodes should execute the above verificationprocess and, if successful, commit a transaction that states theassociation (cid:104) S, E, id( S ) (cid:105) . c) Committee selection procedure: For the committeeselection, the same approach of Protocol 3 can be adopted.
C. Correctness Under Non-Ideal Conditions
Correctness of Protocols 3 and 4 depends on the reliabilityof the challenge-response process. In particular, the committeemembers, the endpoint and the communication technologyshould be reliable. To tolerate a margin of committee subjectsthat are not on-line (or problems during communication), wecan slightly change the protocols. Protocol 3 can be easily adapted to tolerate a numberof missing acceptance transactions by just fixing a suitablethreshold ¯ k ≤ k of members that have to accept the proof, forit to be valid.Protocol 4 can also be adapted. In Step 5, S may not waitfor all partial challenges but only for ¯ k ≤ k of them to toleratea fraction of missing ones.A further aspect is that there is no reason for committeemembers to execute the certification protocol. To solve thisproblem, they should be rewarded for their work. This isnot hard to do if the underlying DLT also implements acryptocurrency, which is often the case.V. S ECURITY
In this section, we introduce our threat model and analyzethe security of Protocols 3 and 4 in that model.
A. Threat Model
In analyzing the security of our protocols, we consider thefollowing threats (or malicious objectives).
Miscertification.
Certification of untrue associationof subject S with endpoint E . Denial of service (DoS).
Denial of certification for a legiti-mate (cid:104)
S, E (cid:105) association.We denote by N the number of certified subjects in thenetwork. In our model, any adversary-controlled (certified ornon-certified) subject S may deviate from the protocol in anarbitrary way.We assume the adversary may ask certification for severalpairs (cid:104) S i , E i (cid:105) . This is legitimate and easy to achieve, providedthat the adversary actually controls the E i ’s and owns keysfor subjects S i ’s. These certified subjects may deviate formthe protocol and be leveraged to perform malicious actionsrealizing a Sybil attack in our context. However, we assumethat only a limited number of subjects m , with m ≤ N , canbe certified by the adversary. This can be enforced in practicein several ways. For example, if the blockchain supports acryptocurrency, we may regularly charge each certified subjecta fee to keep old certificates active. Hence, we can assume thatthe cost of controlling m subjects is cm where c is the costfor each subject in a certain period of time.We assume the underlying blockchain technology to besecure. Hence, the adversary1) cannot tamper with the blockchain,2) cannot stop a non-controlled subject from asking to theblockchain to perform a transaction, and3) cannot stop a non-controlled subject from reading fromthe blockchain the committed transactions.This also means that the adversary cannot add certifications,delete or tamper with past certificates, or change subjectidentifiers.We assume the communication technology of E to beimmune from certain specific attacks. For both protocols, weassume no network-level denial of service is possible. ForProtocol 3, we assume that the adversary cannot create spoofedessages that look as if they are sent from E . For Protocol 4,we assume the adversary cannot eavesdrop messages sent to E . B. Security Analysis
To prove the security of our approach against miscertifi-cation , we should prove that it is hard for an adversary A tocertify an association (cid:104) S, E (cid:105) , when E is not actually controlledby A . We show that the adversary is going to spend O ( N ) toperform the attack and hence that the security of our approachincreases for larger N .Since the adversary cannot spoof/eavesdrop messagesfrom/to E , if E is not controlled by A , the only way that A hasto obtain the certificate is to corrupt a committee controllingat least ¯ k committee members. The corrupted committeemembers can assert that they received or sent the messagesthrough E , as stated by our protocols, even if communicationoccurred using another channel. A committee is formed by k randomly extracted members, out of N total certified subjects,of whose only m are corrupted. The probability p ( m ) that, ina committee, at least ¯ k = αk members (with < α < )are controlled by A is given by p ( m ) = (cid:80) ki =¯ k ( mi )( N − mk − i )( Nk ) .Function p ( m ) equals / at m = αN and it is very close tozero for m < / αN This means that when N increases, theadversary have to corrupt at least about αN subjects to havea reasonable probability to get a corrupted committee. Hence,for k and ¯ k fixed, the adversary should spend O ( N ) to performa miscertification attack with reasonable probability.To perform a denial of service, A cannot act at the networklevel or at the blockchain level (by threat model). The onlyway for A to block a certification process is to force honestmembers to be less than ¯ k . To do this, A should corrupt morethan k − ¯ k = k (1 − α ) members. Hence, the same argumentwe showed for miscertification applies where we substitute α with − α . VI. P ERFORMANCE E VALUATION
In this section we provide a comparison analysis betweenthe basic protocols (see Section III) and the decentralizedones (see Section IV) in terms of latency and of messagestransmitted through the endpoint.We start by analyzing the time taken by decentralizedprotocols from when the transaction with the certificationrequest R is broadcasted to when the certification is knownto all nodes. We call this interval of time the latency of theprotocol. We assume the delay for creating and signing achallenge to be negligible with respect to other delays involvedin the protocol.We call b the interval of time between two consecutiveblocks. For simplicity, we assume b to be constant and thenumber of transactions a single block can host is greater thanthe committee size k . We denote by ¯ b < b the time that atransaction waits before acceptance. The expected value of ¯ b is b/ , if the instant in which a new transaction is receivedby the blockchain is independent from previous block committime. We call p , with p (cid:28) b , the time to propagate a block Subject Blockchain CommitteeMember
R Proof A cc e p t a n c e p ¯ b pe kW pp (cid:108) p + e + kWb (cid:109) b Fig. 3. Timings for Protocol 3.
Subject Blockchain CommitteeMember
Challenges kWepp (cid:108) p + e + kWb (cid:109) b P r oo f A cc e p t a n c e p b R p ¯ b pp Fig. 4. Timings for Protocol 4. to all nodes. We assume that the time to propagate a new(still unaccepted) transaction to all nodes is also p . We call W the time that a single message takes to be transmitted tothe endpoint and e the time it takes to arrive to destination,hence, k messages are received after e + kW time.Latency of Protocol 3 is easily derived by observing thediagram in Figure 3 and it turns out to be (cid:108) p + e + kWb (cid:109) b +2 p + ¯ b . Analogously by observing the diagram in Figure 4,we derive the latency of Protocol 4, which is given by (cid:16)(cid:108) p + e + kWb (cid:109) + 1 (cid:17) b +2 p +¯ b . We note that, for both protocols,after certification is recorded in the chain, a verifier takesnegligible time to check it.About the latency of basic protocols, let v be the numberof verifiers. We assume each verifier verifies (cid:104) S, E (cid:105) only onetime. We assume that the alternative communication mean M between the subject and each verifier has negligible latencyand transmission time. The latency of the basic protocols turnsout to be e + vW .Concerning the number of messages that have to be trans-mitted through the endpoint, the basic protocols send v mes-sages overall, while both our protocols send only k messages.Since our protocols use the endpoint only to transmit aconstant number of messages during the certification, they turnout to be advantageous when v > k . We note that k can betuned to obtain a spectrum of tradeoffs between efficiencyand security. We also note that our protocols turns out to beadvantageous also with respect to latency when W is largeand v (cid:29) k . ndpoint Message Cost to sendone message Security (Attack difficulty) SuggestedProtocol spoofing (P3) eavesdropping (P4) Phone number SMS SMS cost High: telecom op.countermeasures
Medium: it requiresphysical or logicalproximity to the endpointto miscertify
P3: to chargecost on subject
Phone number phone call with IVR phone call costPostal mail address letter stamp Low P4: forsecurity reason
Email address email negligible LowIP address IP packet negligible LowWeb page Page change and HTTP response for P3HTTP GET/POST for P4 (technically complex) negligible Medium: proximity required
P3: easier toimplement
DNS name DNS response (P3 only) negligible High: distributed - P3Bank account/IBAN description field of bank transfer transfer cost High High P3 or P4TABLE IS
UMMARY OF ENDPOINT FEATURES . F
OR BREVITY , P
ROTOCOLS AND ARE REFERRED AS P3 AND
P4.
VII. A
PPLICATION C ONTEXTS
Nowadays, users already provide proofs-of-possession re-garding endpoints in a number of situations. Since, they canbe easily turned into use cases for our protocols, we brieflyreview some of them in this section. Table I summarizes themost common cases. The table reports the endpoint, the kindof message used to proof its possession, the cost, a briefremark about the security regarding its use in our protocols,and the suggested protocol choice. Phone numbers can becertified by both SMS or IVR-based phone calls. Regularpostal addresses can be certified by sending letters, even ifthey may be impractical for large committees. A static webpage is easy to use as a broadcast channel in the direction fromserver to browser(s) for Protocol 3. The opposite direction isalso an option, but it requires the web site owner to be able toget details of the GET/POST request. DNS records can alsobe used as broadcast channel for Protocol 3 while the oppositedirection is not available since queries are usually served bythird party servers. For bank transfers, a small amount totransfer might also be needed. Concerning security, in mostcases eavesdropping is easy if the attacker can reach a positionthat is close to the endpoint that (s)he intends to miscertify.This is true also for SMS (which are weekly encrypted),but this risk is usually accepted in two-factor authenticationprocedures. In certain cases, it might be possible to mitigatethis risk by using encryption (e.g, as for SSL/TLS for IP),but this may increase complexity and number of messagessubstantially. For the web, the spoofing attack requires firstto eavesdrop the request, hence proximity to endpoint isrequired. For DNS, responses are generated by third partyservers in a distributed manner, hence, the attacker cannotexploit endpoint proximity. Eavesdropping on the committeeside is hard, as well. Concerning bank transfers, we assumethat confidentiality and integrity are assured by the interbankcommunication network.VIII. D
ISCUSSION AND C ONCLUSIONS
We described two blockchain-based decentralized protocolsto create verifiable claims regarding ownership of a certainendpoint. We believe that our contribution complements theuse of decentralized identifier and is a further step toward afully decentralized IdM process. With respect to currently adopted naive approaches, ourprotocols do not require the subject to be on-line and theendpoint load does not depends on the number of verifications.This makes our approach especially suited in applicationswhere a large number of subjects that are not always on-lineare needed to be verified by a large number of verifiers.R
EFERENCES[1] Iso/iec 24760:2019 it security and privacy — a framework for identitymanagement. Technical report, New York, 1994.[2] European Union. eIDAS – Electronic Identification, Authentication andTrust Services, EU Regulation 910/2014.[3] Teruko Miyata, Yuzo Koga, Paul Madsen, Shin-Ichi Adachi, YoshitsuguTsuchiya, Yasuhisa Sakamoto, and Kenji Takahashi. A survey on identitymanagement protocols and standards.
IEICE - Trans. Inf. Syst. , E89-D(1):112–123, January 2006.[4] Andreas Pashalidis and Chris J. Mitchell. A taxonomy of single sign-onsystems. In Rei Safavi-Naini and Jennifer Seberry, editors,
InformationSecurity and Privacy , pages 249–264, Berlin, Heidelberg, 2003. SpringerBerlin Heidelberg.[5] Alexander M¨uhle, Andreas Gr¨uner, Tatiana Gayvoronskaya, andChristoph Meinel. A survey on essential components of a self-sovereignidentity.
Computer Science Review , 30:80 – 86, 2018.[6] D Reed and M Sporny. W3C Decentralized Identifiers (DIDs) v1.0,2017.[7] M Sporny, D Longley, and Chadwick D. W3C Verifiable CredentialsData Model 1.0: Expressing verifiable information on the web, 2018.[8] EU. eIDAS supported self-sovereign identity. https://ec.europa.eu/futurium/en/system/files/ged/eidas supported ssi may 2019 0.pdf,Last accessed April 2020.[9] Harry A. Kalodner, Miles Carlsten, Paul Ellenbogen, Joseph Bonneau,and Arvind Narayanan. An empirical study of namecoin and lessonsfor decentralized namespace design. In , 2015.[10] uPort: a self-sovereign identity and user-centric data platform. https://github.com/uport-project/specs, Last accessed April 2020.[11] sovrin. sovrin: Control your digital identity. Last accessed April 2020.[12] ShoCard. Shocard whitepaper. Last accessed April 2020.[13] P. Dunphy and F. P. Petitcolas. A first look at identity managementschemes on the blockchain.
IEEE Security & Privacy , 16(04):20–29,jul 2018.[14] M. Takemiya and B. Vanieiev. Sora identity: Secure, digital identityon the blockchain. In , volume 02, pages 582–587,2018.[15] Jamila Kassem, Sarwar Sayeed, Hector Marco-Gisbert, Zeeshan Pervez,and Keshav Dahal. Dns-idm: A blockchain identity management systemto secure personal data sharing in a network.