Understanding Distributed Identity Management Systems
In the last post, we classified the blockchains and investigated each type’s characteristics. In this post, we will discuss the applications of blockchain in real life. There are many real-life examples of blockchains, such as remittance, loans, and currency exchange. However, in this post, we want to discuss blockchain’s identity management process in detail. Blockchain can have more strengths in identity management systems than other applications. The integrity and decentralization of blockchain enable Self-Sovereign Identity Management, where users have sovereignty over their identities. Therefore, in this post, we will discuss how blockchain can be used in identity management systems and the advantages of using blockchain.
1. Centralized identity management
The most traditional identity management method is Centralized Identity Management. Centralized identity management is a system in which a service provider (SP: Service Provider) that provides services has and manages all user identity information. For example, when registering as a member of a specific site, the user transmits personal information such as social security number, address, and mobile phone number. The above information is stored in the service provider’s server. The user must retrieve their identity information from the service provider’s server to use a specific service provider. It is far from self-sovereign identity management in that the user’s identity information is exposed to the service provider, and the storage and management of the identity information are subordinated to the service provider. Also, it is inefficient because the same identity information must be stored separately for each service provider. Assume that a user registers as a member of portal site A. To use service A, the user provides identity information to company A. The above identity information is stored in the server of A. When the user uses service A, the identity information obtained from the server is used for authentication. The above structure has the disadvantage of providing identity information again when the user uses a service other than A because the user information is ultimately stored in the service A server. That is, service B cannot be used through the identity information provided to service A. In addition, the identity information for using the service A is ultimately stored in the server of A. If there is an error in the server of A, the user may not be able to use the service despite providing the identity information. For example, a fire broke out in a data center of a company called Kakao in Korea recently. As a result, users could not use Kakao’s services for several days. Therefore, Federated Identity Management was proposed to alleviate the above shortcomings.
2. Federated identity management
The federated identity management system does not guarantee a fully self-sovereign identity for users, but it is meaningful in that it separates the service provider and the identity provider. In the federated identity management system, the service provider does not store and manage the identity after it is provided but requests identifying information from the identity-providing service with a specific trust relationship whenever the user accesses the service. Of course, complete self-sovereign identity is not guaranteed in that the user entrusts their identity to the identity-providing service. However, it is more efficient than the centralized model that stores identity information for each service provider. The Social media login system is the most representative example of a federated identity management system. Using other services that have a trust relationship with Google through identity information stored in Google is an example of a federated identity management system.
3. Self-sovereign identity management
As mentioned earlier, the federated identity management system cannot guarantee complete self-identity sovereignty. However, with the recent rise of blockchain, various research and development on self-sovereign identity management are in progress. Because blockchain is a decentralized, verifiable data store, it can be used as an identity provider or a tool for identity verification. Expressly, because one’s identity is not entrusted to a central authority (decentralization), the reliability of data recorded on the blockchain can be guaranteed (data integrity), and the data recorded on the blockchain cannot be lost. Self-sovereign identity management was made possible. A standard for a distributed identity management system has recently been established using these characteristics of the blockchain. As a representative, let us deal with the distributed identity management system proposed by the World Wide Web Consortium (W3C).
Identity information has the following form. ‘A (Subject) satisfies the attribute a.’ The above information unit is called a claim. Looking at the example in Fig 3., the information “Pat is a graduate of Example University” can be said to be an example of a claim. However, since a claim is a kind of claim, the above information cannot be used as it is for the service provider. For example, when Pat is in high school, the above information should not be used. Therefore, it is necessary to give credibility to the claim. A set of credible claims is called a verifiable credential. Specifically, when the signature of the trusted authority is added to the claim, it can be seen as authenticated information, not just a claim. A verifiable credential consists of the following:
As shown in Fig. 5, verifiable credentials are credential metadata that summarizes what information the credential is revealing, claims that are identity information to be asserted, and proofs that prove the authenticity of the claims (Proof).
The credential information reveals that “Pat is a graduate of Example University” and has been certified by Example University. However, the above credentials cannot guarantee that one has used the above information. Someone can use Pat’s information after being authenticated by a trusted authority. A verifiable presentation has been proposed to prevent this.
A verifiable presentation is a collection of multiple verifiable credentials and the user’s signature. Since the user’s signature has been added, the above information may be proved to be used by the user himself. Accordingly, by providing a verifiable presentation to the service provider, the service provider may check the identity information.
A public verification key is required to verify the proof (signature) of the verifiable presentation. A blockchain may be used to store this public verification key. The verification key that can verify the above information is stored for each subject in the blockchain. Since the blockchain is a public database, anyone can verify the identity information provided by the user/trust agency with the public verification key of each subject.
Fig 7. can be seen as a figure showing the above process. A user can receive a credential from a trusted authority (Issuer) and compose their presentation by combining the credentials issued from multiple trusted organizations. The service provider can verify the representation provided by using the public verification key of the trusted authority/user recorded in the blockchain. Decentralized ID (DID) has been proposed to manage the above public verification key more efficiently. DID allows each subject to store the public verification key and public information required for data verification in the blockchain. The specific structure is as follows.
Each subject has its own DID, which is used as an index to check the actual public key information. DID document, a set of actual public verification values, can be accessed through DID, and DID document can be accessed in the form of a URL through the DID URL. Through these DID structures and verifiable credential data models, one can manage self-sovereign identity in which one can have sovereignty over one’s identity, and various services can also be constructed.
For example, Metadium provides APIs for using the above verifiable credentials, verifiable presentation, DID, and built services using the above APIs. Mykeepin service, an integrated authentication service using DID, is provided, and a wallet for using it is also offered.
Before the advent of the blockchain, all data was managed by a central administrator, a server. Therefore, in managing identity information, it was inevitably subordinated by the central manager. However, with the emergence of a blockchain that can collect data in a decentralized environment and ensures data integrity (without data modification and risk of loss), users can manage identity information without entrusting their identity information to a specific company’s server. In other words, the blockchain can be seen as meaningful in realizing self-identity sovereignty because it can return the individual’s identity sovereignty to the individual.
References
지난 포스트에서는 블록체인의 유형을 분류하고 각 유형에 대한 특징을 알아보았다. 이번 포스트에서는 블록체인이 실제 생활에 적용될 수 있는 응용에 대해 다룬다.
블록체인을 사용하는 실생활 예는 송금, 대출, 환전 등의 여러 사례가 있지만 본 포스트에서는 블록체인을 활용한 신원 관리 프로세스에 대해 자세히 다뤄보고자 한다. 다른 응용보다도 신원관리 시스템에서 블록체인은 더욱 강점을 가질 수 있는데, 블록체인의 무결성 및 탈중앙성이 사용자가 자신의 신원에 대한 주권을 갖는 자기주권 신원관리(Self-Sovereign Identity Management)를 가능하게 하기 때문이다. 따라서, 본 포스트에서는 신원관리 시스템에 블록체인이 어떻게 이용될 수 있는지, 블록체인을 사용함으로써 얻을 수 있는 장점에 대해 다룬다.
1. 중앙집중형 신원관리
Fig 1. Centralized identity management system
가장 전통적인 방식의 신원관리 방식은 중앙집중형 신원관리(Centralized Identity Management)라고 볼 수 있다. 중앙집중형 신원관리는 서비스를 제공하는 서비스 공급자(SP: Service Provider)가 사용자의 모든 신원정보를 갖고 관리하는 시스템이다.
예를 들어, 특정 사이트에 회원가입을 할 때 사용자는 사이트에 주민번호, 주소, 핸드폰 번호 등의 개인정보를 전달하고 위의 정보는 서비스 공급자의 서버에 저장되게 된다. 서비스 공급자의 특정 서비스를 사용하기 위해서 사용자는 서비스 공급자의 서버에서 자신의 신원정보를 불러올 필요가 있다. 이는 사용자의 신원정보가 서비스 공급자에게 그대로 노출되고, 신원정보의 보관 및 관리가 서비스 공급자에게 종속된다는 점에서 자기주권 신원관리와 거리가 멀다. 또한, 같은 신원정보가 각 서비스 공급자에게 각각 저장될 필요가 있다는 점에서 비효율적이다.
사용자가 A라는 포털사이트에 회원가입한다고 가정해 보자. A 서비스를 이용하기 위해 사용자는 신원정보를 A 기업에 제공하는데, 위의 신원정보는 A의 서버에 저장되고 사용자가 A 서비스를 사용할 시 서버에서 가져온 신원정보가 인증에 사용된다.
위와 같은 구조는 온전히 사용자 정보가 A 서비스의 서버에 저장되고 있기 때문에 사용자가 A 이외의 다른 서비스를 이용할 때 또다시 신원정보를 제공해야 하는 단점을 지닌다. 즉, A 서비스에 제공한 신원정보를 통해 B 서비스를 이용할 수 없는 것이다. 또한, A 서비스를 이용하기 위한 신원정보가 온전히 A의 서버에 저장되고 있기 때문에 A의 서버에 이상이 생길 시 사용자는 신원정보를 제공했음에도 불구하고 서비스를 이용할 수 없는 상황이 발생할 수 있다.
일례로 근래 한국에서 카카오라는 기업의 데이터 센터에 화재가 발생했는데, 이로 인해 수 일간 카카오 산하 서비스를 사용자가 이용할 수 없었던 사례가 발생했다. 따라서 위의 단점을 완화하고자 연합형 신원관리 시스템(Federated Identity Management)가 제안되었다.
2. 연합형 신원관리
Fig 2. Federated identity management system
연합형 신원관리는 사용자에게 완전한 자기주권 신원을 보장하지는 않지만, 서비스 공급자와 신원 제공자를 분리하였다는 것에 의미가 있다. 연합형 신원관리에서는 서비스 제공자가 신원을 제공받은 후 보관 및 관리하는 것이 아니라, 사용자가 서비스에 접근할 때마다 특정 신뢰관계를 갖고 있는 신원 제공 서비스에 신원정보를 요청하는 형태를 취한다. 물론 사용자가 자기 신원을 신원 제공 서비스에 위탁하여 보관/관리한다는 점에서 완전한 자기주권 신원을 보장하고 있지 않지만, 서비스 제공자마다 신원정보를 보관하는 중앙집중형 모델보다는 효율적이라고 볼 수 있다.
연합형 신원관리 시스템의 가장 대표적인 예로는 SNS 로그인 시스템이 있을 것이다. Google에 저장된 신원정보를 통해 Google과 신뢰관계를 맺고 있는 다른 서비스를 이용하는 것이 연합형 신원관리 시스템의 예라고 볼 수 있다.
3. 자기주권형 신원관리
앞서 언급했듯 연합형 신원관리 시스템 역시 완전한 자기 신원 주권을 보장할 수는 없다. 이를 보완하기 위해 최근 블록체인이 대두되면서 자기주권 신원관리에 대한 다양한 연구 및 개발이 진행되고 있다.
블록체인은 탈중앙성을 지닌 검증 가능한 데이터 저장소이기 때문에 신원 제공자 또는 신원 검증을 위한 도구로서 사용될 수 있다. 구체적으로 자기 신원을 특정 중앙기관에 위탁하지 않는다는 점(탈중앙성), 블록체인에 기록된 데이터의 신뢰성을 보장할 수 있다는 점(데이터 무결성), 블록체인에 기록된 데이터는 유실될 수 없다는 점이 자기 주권 신원관리(Self-sovereign idendity management)를 가능할 수 있도록 하였다.
이러한 블록체인의 특성을 사용하여 최근 분산 신원관리 시스템에 대한 표준이 확립되고 있는데, 대표적으로 W3C(World Wide Web Consortium)에서 제안한 분산 신원관리 시스템에 대해 다뤄보고자 한다.
Fig 3. Claim example
신원정보는 기본적으로 ‘A (Subject)는 a 속성(attribute)을 만족한다’와 같은 형태를 갖는다. 이와 같은 정보 단위를 클레임(Claim)이라고 한다. Fig 3.의 예를 보면, “Pat은 Example University의 졸업생이다”라는 정보가 클레임의 예라고 할 수 있다. 그러나 클레임은 일종의 주장이기 때문에 위의 정보가 그대로 서비스 제공자에게 사용될 수 없다. 예를 들어 Pat이 고등학생일 때 위의 정보가 그대로 사용되면 안 되는 것이다. 따라서 Claim에 신뢰성이 부여될 필요가 있는데, 신뢰성이 있는 클레임의 집합을 검증 가능한 크리덴셜(Verifiable Credential)이라고 한다. 구체적으로 클레임에 신뢰기관의 서명이 추가되게 되면, 그것은 단순한 주장이 아니라 인증받은 정보라고 볼 수 있다.
검증 가능 크리덴셜은 다음과 같이 구성된다.
Fig 4. Verifiable credential
Fig 5. Verifiable credential structure
Fig 5.를 보면, 검증 가능 크리덴셜은 크리덴셜이 어떤 정보를 드러내고 있는지 요약해 주는 크리덴셜 메타데이터(Credential metadata), 실제 주장하고자 하는 신원정보인 클레임(Claims), 클레임의 진위를 증명해 주는 증명(Proof)로 구성된다.
위의 크리덴셜 정보는 “Pat이 Example University의 졸업생이다”라는 정보가 Example University에 의해 인증되었음을 드러낸다. 그러나 위의 크리덴셜에서는 바로 본인이 위의 정보를 사용한 것임을 보장할 수 없다. 누군가 Pat의 정보를 신뢰 기관에서 인증받아 사용할 수 있는 것이다. 위와 같은 것을 방지하고자 검증 가능 프레젠테이션(Verifiable Presentation)이 제안되었다.
Fig 6. Verifiable presentation
검증 가능한 프레젠테이션은 여러 인증 가능 크리덴셜을 모아서 사용자 본인의 서명을 덧붙인 것을 의미한다. 사용자의 서명이 추가되었기 때문에, 위의 정보는 사용자 본인이 사용하는 것임을 증명할 수 있다. 따라서, 서비스 제공자에게 검증 가능한 프레젠테이션을 제공함으로써 서비스 제공자는 신원정보를 확인할 수 있다.
검증 가능 프레젠테이션이 갖고 있는 증명(서명)을 검증하기 위해서는 공개 검증키가 필요하다. 이 공개 검증키를 보관하는 것에 블록체인이 사용될 수 있다. 블록체인에 위의 정보를 검증할 수 있는 검증키를 각 주체별로 저장하고, 블록체인은 일종의 공개 데이터베이스이기 때문에 누구나 각 주체의 공개 검증키를 가지고 사용자/신뢰 기관이 제공한 신원정보를 검증할 수 있다.
Fig 7. Verifiable credential data model
Fig 7.은 위의 프로세스를 보여주는 그림이라 볼 수 있다. 사용자는 신뢰 기관(Issuer)으로부터 크리덴셜을 발급받고 여러 신뢰 기관으로부터 발급받은 크리덴셜을 조합하여 본인만의 프레젠테이션으로 구성할 수 있다. 서비스 제공자는 블록체인에 기록된 신뢰 기관/사용자의 공개검증키를 사용하여 제공받은 프레젠테이션을 검증할 수 있다. 위의 공개검증키를 보다 효율적으로 관리하기 위해 DID(Decentralized ID)가 제안되었다. DID는 각 주체별로 데이터 검증에 필요한 공개검증키 및 공개정보를 블록체인에 저장할 수 있도록 하는데, 구체적인 구조는 다음과 같다.
Fig 8. DID structure
각 주체(Subject)는 각각 자신만의 DID를 가지고 이는 실제 공개키 정보를 확인하기 위한 인덱스로서 사용된다. DID를 통해 실제 공개 검증 값의 집합인 DID document에 접근할 수 있으며, 또한 DID URL을 통해 URL의 형태로 DID document에 접근할 수 있다. 이러한 DID 구조 및 Verifiable credential data model을 통해 자기 자신이 자기 신원에 대해 주권을 가질 수 있는 자기주권 신원관리가 가능해질 수 있으며, 이를 통해 다양한 서비스 역시 구축될 수 있다.
일례로 메타디움에서는 위의 검증 가능 크리덴셜, 검증 가능 프레젠테이션 및 DID 사용을 위한 API를 제공하고 있으며 위 API를 사용한 서비스 역시 구축하고 있다. DID를 사용한 통합인증 서비스인 MYKEEPiN 서비스를 제공하고 있으며 이를 사용하기 위한 지갑 역시 서비스되고 있다.
블록체인 등장 이전 모든 데이터는 중앙관리자, 즉 서버에 의해 관리되었다. 따라서 신원정보를 관리함에 있어 불가피하게 중앙관리자에 의해 종속될 수 밖에 없었다. 하지만 탈중앙화된 환경에서 데이터를 관리할 수 있고, 데이터 무결성을 보장하는(데이터가 수정되지 않고 유실 위험이 없는) 블록체인이 등장함으로써 사용자는 자신의 신원정보를 특정 기업의 서버에 위탁하지 않고도 신원정보를 관리할 수 있게 되었다. 즉, 제 3자가 갖고 있는 개인의 신원 주권을 개인에게 돌려줄 수 있다는 점에서 블록체인은 자기신원 주권을 실현함에 있어 큰 의미가 있다고 볼 수 있을 것이다.
참고문헌
[1] https://www.w3.org/TR/vc-data-model/
작성자 Ljh
