Self-Sovereign Identity(마스터링 자기주권신원)

이민기·2023년 8월 1일

SSI did

Intro

SSI에 대해 맥락을 알아보기 위해 자기주권신원을 읽으며 정리해 보았다!

VC (Verifiable Credential)

특징

VC는 변조 감지를 제공하는 발급자가 삽입한 암호화 방식의 proof 속성을 가지고 있기 때문에 발급자에서부터 중간 스토리지 지갑을 통해 검증자에게 이르기까지 보호
VC는 전송 중에 TLS와 같은 암호화된 통신 링크를 통해서만 전송하여 기밀로 보호되어야 한다.
VC는 발급자 또는 다른 제 3자와의 통신이 검증자에게 전송될 필요가 없기 때문에 보유자의 장치에 저장되어 있는 경우 고가용성을 갖는다.
VC는 검증자가 서비스 제공에 필수적인 주체 속성만 요청할 수 있도록 하여 최소 권한의 보안 속성을 용이하게 한다.
VC는 영지식 증명(ZKP) VC 또는 원자 VC 집합을 발급하는 밝듭자의 선택적 공개를 통하여 개인정보 보호를 제공하며 이를 통해 보유자는 검증자가 필요로 하는 속성만 공개할 수 있으며, 그 이상은 공개할 필요가 없다.
VC는 신원의 이름이 아닌 가명 ID를 통해 주체를 식별하여 주체의 개인정보를 보호한다. 이러한 가명 ID들이 주체와 검증자 사이에 쌍을 이루어 연결되는 경우에는 전역적으로 고유한 관련성은 생성되지 않는다.
검증자는 서비스에 접근할 수 있는 사용자의 ID가 아니라 서비스에 접근하는 데 필요한 역할이나 속성만 지정하면 되므로 VC는 유연한 역할 기반 및 속성 기반 접근 제어를 지원한다.

VC (Verifiable Credential) 구성 요소

@context : 해당 VC가 구성하는데 사용된 정보의 집합이며 하나 이사으이 URI시퀀스로 구성
type : 어떤 속성의 VC인지 설명하는 URI목록이 포함된다.
id : 발급자가 생성한 VC의 고유한 식별자이며 단일 URI로 구성
issuer : 발급자를 고유하게 식별하는 URI이며 해당 URI는 발급자의 DID 혹은 DNS의 이름을 포함할 수 있다. 검증 가능한 데이터 저장소는 발급자에 대한 X.509 공개 키 인증서와 같은 추가 세부사항을 포함 가능
credentialSubject : 발급자가 주체에 대하여 만든 클레임 항목들이며 주체의 ID와 발급자가 주체에 대해 주장하는 속성들의 집합.
proof : 발급자가 VC를 발급했으며 발급 이후 변조되지 않았음을 암호화 방식으로 증명하는 항목으로, 일반적으로 VC데이터 모델 사항에서 proof로 참조되는 서명이 필요. 해당 항목에 대한 단일 표준은 없으나, 증명의 유형을 나타내는 type항목이 포함되어야 함
issuanceDate : ISO 8601형식으로 조합되었으며 VC의 발급 시점
credentialStatus: VC의 현재 상태에 대한 세부 정보이며 표준 형식은 없지만 모든 상태에는 id, type이 포함되어야 함.
refreshService: 발급자가 현재 VC를 새로 고치거나 업데이트하는 방법에 대한 세부 정보를 제공 및 제어할 수 있으며, 보유자만 알기를 원한다면, VC에 추가하는 방법이 아닌 VC를 캡슐화하는 VP에 추가해야 함.
termsOfUse : VC에 이용 약관을 추가하는 표준 방법
evidence : 발급자는 해당 항목을 VC에 추가하여 검증자가 VC의 클레임에 대해 가질 수 있는 신뢰 수준을 결정하는데 도움을 줄 수 있으며 해당 항목은 type이 포함 되어야 함.ㅌㅌ

//JSON-LD로 인코딩된 VC
{
	"@context": [
		"https://www.w.org/2018/credentials/Vl",
		"https://example.org/examples/vI"
		],
	 "id": "http://example.edu/credentials/3732",
	"type": ['VerifiableCredential", "UniversityDegreeCredential"],
	"issuer": "https: //example.edu/issuers/14",
	"issuanceDate": "2010-01-01719:23:24Z",
	"credentialSubject": {
		"id": "did: example: ebfeb1f712ebc6f1c276e12ec21",
		"degree": {
			"type": "BachelorDegree",
			"name": "Bachelor of Science in Mechanical Engineering"
		}, 
		"credentialSchema": {
			"id": "https://example.org/examples/degree.json",
			"type": "JsonSchemaValidator2018"
		},
		"termsOfUse": {
			"type": "IssuerPolicy",
			"id": "http: //example.com/policies/credential/4",
			"profile": "http://example.com/profiles/credential",
			"prohibition": [{
				"assigner": "https: //example.edu/issuers/14",
				"assignee": "AllVerifiers",
				"target": "http://example.edu/credentials/3732",
				"action": ["Archival"]
			}]
		},
		"evidence": [{
			"id": "Ittps://example.edu/evidence/f2aeec97-fcod-42bf-8ca7-0548192d4231",
			"type": ['DocumentVerification"],
			"verifier": "https: / /example.edu/issuers/14",
			"evidenceDocument": "DriversLicense",
			"subjectPresence": "Physical",
			"documentPresence": "Physical"
			}, {
			"id": "https: //example.edu/evidence/faeec97-fcod-42bf-8ca7-0548192dxyzab",
			"type": ["SupportingActivity"],
			"verifier": "https: //example.edu/issuers/14"
			"evidenceDocument": "Fluid Dynamics Focus"
			"subjectPresence": "Digital"
			"documentPresence": "Digital"
			}], 
		"refreshService": {
			"id": "https: //example.edu/refresh/3732",
			"type": "ManualRefreshService2018"
			}, 
		"proof": {
			"type": "RsaSignature2018",
			"created": "2018-06-1821:19:10Z",
			"verificationMethod": "https: //example.com/jdoe/keys/1",
			"nonce": "cOaelc8e-c7e7-469f-b252-86e6a0e7387e",
			"signatureValue": "BavEll0/IlzpYw8XNilbgVg/s...WJT24 = "
	}
}

DID (Decentralized Identifiers)

개념적 수준: DID

리소스를 식별하는 문자열인 글로벌 고유 식별자

URL 또는 URN중 어느 하나가 될 수 있으며 DID로 식별되는 리소스에 대한 표준화된 정보인 메타데이터의 집합을 얻기 위해 리졸브할 수 있는 URI

URL (Uniform Resource Locator) :인터넷 상의 리소스를 식별하는 데 사용되는 문자열, 일반적으로 웹 페이지, 이미지, 동영상 등의 파일의 위치를 식별하는 데 사용
URN (Uniform Resource Name) : 인터넷 상의 리소스를 고유하게 식별하는 데 사용되는 문자열이며 URN은 일반적으로 파일의 위치를 식별하지 않고, 파일 자체에 대한 식별자로 사용
URI (Uniform Resource Identifier) : 인터넷 상의 리소스를 식별하는 데 사용되는 모든 문자열이며 URI는 URL과 URN을 모두 포함

핵심 속성

영구 식별자 : 변경할 필요가 없음
리졸브 가능한 식별자 : 메타데이터를 찾기 위해 검색 가능
암호로 검증 가능한 식별자 : 암호화를 사용하여 제어를 증명할 수 있음
분산 식별자 : 중앙형 등록 권한이 필요하지 않음

기능적 수준 : DID 작동 방식

DID Document

DID를 기본 구성 요소로 사용하는 디지털 지갑, 에이전트 또는 암호화된 데이터 저장소와 같은 디지털 ID 응용 프로그램 또는 서비스에서 사용하도록 설계된 기계 판독 가능 문서

#인증을 위한 하나의 공개 키와 하나의 서비스가 있는 DID Document예시
{
	"@context": "https: //www.w.org/ns/did/vl",
	"id": "did: example: 123456789abcdefghi",
	"authentication": [{
		"id": "did: example: 123456789abcdefghi#keys-1",
		"type": "Ed25519VerificationKey2018"
		"controller": "did: example: 123456789abcdefghi",
		"publicKeyBase58" : "H3C2AVVLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}], 
	"service": [{
		"id": "did: example: 123456789abcdefghi#vcs",
		"type": "VerifiableCredentialService",
		"serviceEndpoint": "https://example.com/vc/"
	}]
}

DID 메서드

DID를 생성하는 데 사용되는 식별자이며 ,DID 생성될 때 사용되는 식별자 및 프로토콜을 정의

#5가지 다른 DID 메서드를 사용하여 생성된 DID
# Sorvin
did:sov:WRfXPg8dantKVubE3HX8pw
# BitCoin
did:btcr:xz35-jzv2-qqs2-9wjt
# VerseOne
did:v1:test:nym: 3AEJTDMSXDDQpyUftjuoeZ2Bazp4Bswjice7FJGybcUu 
# Ethereum
did:ethr:OXE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
# Jolocom
did:J010:11b3523535124865104b4079c04c3666627fcf5a167d69309fc84b75964e2

DID 레졸루션

DID와 관련된 DID Document를 얻는 과정이며 이 과정을 통해 DID지원 응용 프로그램 및 서비스는 DID Document에 표현된 DID 서브젝트에 대한 메타데이터를 검색 가능하며 메타데이터는 다음과 같은 DID서브젝트와의 추가 상호작용에 사용

검증 가능한 자격증명 발급자의 디지털 서명을 검증하기 위한 공개 키 조회
컨트롤러가 웹사이트나 앱에 로그인해야할 때 DID 컨트롤러와 관련된 잘 알려진 서비스 검색 및 접근
DID 컨트롤러와 DID간 연결 요청

DID URL

DID와 관련된 추가 리소스에 대한 식별자 공간을 활성화

did:example:1234#keys-1
// 프레그먼트가 있는 DID URL이며 DID의 관련 DID Document 내에서 특정 공개키를 식별한다.
// 프레그먼트가 있는 http: 또는 https:URL이 HTML 웹페이지 내 특정 책갈피를 가리킬수 있는 방법과 유사

did:example:1234?version-id=4
// DID 매개변수가 있는 DID URL이며 최신 버전이 아닌 DID관련 DID Documnet의 이전 버전을 식별
// DID 문서의 내용이 업데이트 되었지만 특정 버전에 대한 안정적인 참조가 필요한 경우에 유용

did:example:1234?version-id=4#key-1
// 위에 두개의 DID URL을 조합한 것이며 DID관련 DID Document의 특정 이전 버전에내에서 특정 공개키 식별

did:example:1234/my/path?query#fragment
// 경로, 질의 문자열 및 프래그먼트가 있는 DID URL이며, 이 DID URL의 의미 및 처리 규칙은 핵심 DID
// 표준에 의해 정의되지 않고 DID 메서드 및 DID URL을 사용하는 애플리케이션에 따라 정의

did:example:1234?service=hub/my/path?query#fragment
// DID 매개변수가 있는 DID URL이며 DID의 관련 DID Document내에서 특정 서비스를 식별
// 나머지 구문 구성요소의 의미 및 처리 규칙은 핵심 DID 표준에 의해 정의되지 않고 서비스에 한정

DNS와 DID 비교

DID	DNS
글로벌 유니크	글로벌 유니크

아키텍쳐 수준: DID가 작동하는 이유

공개 키 기반구조의 핵심 문제

공개 키 / 비밀 키는 위조될 수 없도록 서로 연결되어 있으나, 공개 키를 신뢰하는 당사자들이 실제 컨트롤러와 상호작용하고 있는지 확인할 수 있도록 공개 키를 컨트롤러에 어떻게 강력하게 바인딩 할 것인가

실제로는 컨트롤러에 식별자를 추가하여 공개 키를 컨트롤러에 바인딩을 하는 방법으로 PKI는 사용되고 있다. 그러나 아래와 같은 그림에서 보이듯 문제 지점은 여전히 남아 있다

문제점은 다음과 같다

식별자를 컨트롤러에 어떻게 강력하게 바인딩할 것인가? ⇒ 식별자-컨트롤러 바인딩 문제
공개 키를 식별자에 어떻게 강력하게 바인딩할 것인가? ⇒ 공개 키-식별자 바인딩 문제

솔루션1: 기존 PKI

식별자-컨트롤러 바인딩 문제

→ 가장 적합한 기존 식별자 중 하나를 사용하여 식별자를 컨트롤러에 강력하게 바인딩하는 것
- 문제점
  - homographic attack(동형 문자 공격, 유사한 이름 또는 다른 구겢 알파벳의 유사 문자 사용)
  - DNS 포이즈닝 (DNS서비스에 조작된 쿼리를 전송하여 주소 정보를 변조)
공개키-식별자 바인딩 문제

→ 공개 키와 식별자를 모두 포함하는 문서에 대지털 서명을 하는 암호화를 사용
- 문제점
  - 인증서에 서명을 하는 주체에 대한 중앙화된 인증기관

솔루션2: 신뢰의 웹 모델

기존 PKI의 단점중 하나인 중앙 기관(CA)에 의존하지 않는 P2P 디지털 인증서를 효과적으로 만들 수 있는 솔루션이나, 신뢰할 수 있는 경로를 어떻게 찾을 것인가에 대한 문제에 대해 합리적으로 안전하고 확장 가능하며 채택 가능한 솔루션은 아직 없다.

솔루션3: 공개 키 기반 식별자

컨트롤러에 대한 기존 식별자를 재사용한 후 공개키에 바인딩하는 대신 프로세스를 역순으로 수행하여 분산원장 또는 유사한 시스템을 이용해 공개 키를 기반으로 컨트롤러에 대한 식별자를 생성하는 방법으로 컨트롤러가 실제 PKI 신뢰 삼각형의 세 지점을 모두 제어할 수 있도록 하는 방법이지만, 컨트롤러의 식별자가 공개 키가 순환될 때마다 변경되는 점으로 인하여 키순환을 지원할 수 없기 때문에 PKI의 대안으로 채택되지 못했다.

솔루션4: DID, DID Document

공개 키 기반의 솔루션 기반으로, 키순환을 해야할 때 컨트롤러는 업데이트 된 DID Document를 생성하고 이전 개인 키를 이용해 서명한다 이를 통해 키순환 지원 및 중앙기관(CA)에 대한 단점을 개선한다.

PKI를 능가하는 DID 장점

후견 및 통제권
서비스 엔드포인트 검색

DID간의 연결 : Diffe-hellman Key Exchange기반 프로토콜을 이용하여 P2P로 직접 교환

Property	Description
영구적	한 쪽 또는 양쪽 당사자가 원하지 않는 한 연결이 끊어지지 않는다.
비공개적	연결을 통한 모든 통신은 자동으로 암호화 되고 DID의 개인 키로 디지털 서명 가능
종단간(End-to-End)	연결에 중개자가 없다
신뢰성	연결은 검증 가능한 자격증명 교환을 지원하여 모든 관련 보증 수준에서 더 높은 신뢰를 구축한다.
확장성	연결은 DID Comm 프로토콜 또는 두 에이전트가 모두 지원하는 기타 프로토콜을 통해 안전하고 비공개적이며 안정적인 디지털 통신이 필요한 모든 프로그램에서 사용

적합한 개인정보보호 중심 설계

의미 수준: DID가 의미하는 것

주소의 의미

주소는 자체적으로 존재하지 않으며 그것들을 사용하는 네트워크의 컨텍스트 안에서만 존재한다.

DID 네트워크와 디지털 신뢰 생태계

DID는 각 레이어에 다음과 같은 스택이 필수적

Layer1: 퍼블릭 DID 유틸리티 : 퍼블릭 블록체인 과 같은 분산 원장 또는 분산파일 시스템에 게시된 DID는 모든 상위 계층의 참가자에 대해 공개적으로 검증 가능한 신뢰 루트역할을 할 수 있기 때문에 신뢰 계층의 기반을 형성
Layer2: DID Comm : DID Comm은 DID로 식별되는 에이전트 간의 P2P 프로토콜이며 Layer2에 존재한다. 그러나 Layer1의 퍼블릭 DID도 사용 가능
Layer3: 자격증명 교환 : DID는 디지털 서명된 검증 가능한 자격증명을 발급 및 검증하는 프로세스와 자격증명 교환 프로토콜에 대한 서비스 엔드포인트 URL 검색에 필수적
Layer4: 디지털 신뢰 생태계 : DID는 모든 규모와 형태 또한 그들이 지정한 참가자들의 디지털 신뢰 생태계를 위한 거버넌스 기관 및 거버넌스 프레임워크의 발견과 검증을 위한 기준점으로 검증 가능한 자격증명이 발급된 거버넌스 프레임워크를 지속적으로 참조하고 거버넌스 프레임워크가 상호 운용성을 위해 서로를 참조할 수 있도록 한다.

DID Wallet & Agent

디지털 지갑

디지털 지갑은 지갑의 컨트롤러가 암호화 key, 기밀 정보 및 기타 민감한 개인 데이터를 생성. 저장, 관리 및 보호할 수 있도록 하는 소프트웨어로 구성

디지털 에이전트

디지털 에이전트는 디지털 지갑에 있어 컴퓨터나 스마트폰의 운영 체제에 해당한다 개인이 행동을 하고, 통신하며, 정보를 저장하고, 디지털 지갑의 사용을 추적할 수 있게 해주는 소프트웨어

DPKI (Decentralized Public Key Infrastructure)

KERI (Key Event Receipt Infrastructure)

거래의 유효성을 검증하고 거래가 일어날 때마다 거래 내용을 기록하여 거래 내용의 무결성과 불변성을 보장하기 위한 기술

키 관리 아키텍처의 출발점: 신뢰 루트

키 관리 아키텍처가 중앙형, 연합형, 분산형이든 상관없이 모두 신뢰 루트에서 시작

👉🏻 **신뢰 루트(신뢰 앵커)** : 신뢰가 파생될 필요가 없는 체인의 유일한 지점이기 때문에 신뢰체인의 시작점이며 신뢰 루트의 신뢰는 가정된다.

관리 기반 신뢰 루트(administrative roots of trust) : 기존 PKI에서 사용되는 신뢰 루트이며 발급하는 디지털 인증서의 무결성을 보장하기 위해 엄격한 절차를 따르는 사람으로 구성된 인증기관(CA)를 의미
알고리즘 기반 신뢰 루트(algorithmic root trust) : 트랜잭션 기반 신뢰 루트(transactional roots of trust)라고도 하며 단일 당사자가 제어할 수 없지만 모든 당사자가 공유된 신뢰의 근원에 동의할 수 있는 보안시스템을 생성하도록 설계된 컴퓨터 알고리즘을 기반 신뢰 루트를 의미
자체 인증 신뢰 루트 : 지율 신뢰 루트라고도 하며, 보안 난수 생성 및 암호화에 기반한 신뢰 루트를 의미. SSI의 경우 디지털 지갑만으로 생성할 수 있는 DID를 의미한다.

	관리 기반 신뢰 루트	알고리즘 기반 신뢰 루트	자체 인증 신뢰 루트
중앙화 / 단일 장애 지점	O	X	X
검증에 사람의 개입 필요	O	X	X
외부 당사자의 참여 필요	O	O	X

DKMS (Decentralized Key Management System)

DKMS란 분산 키 관리 시스템을 의미. 중앙형 권한이 없는 블록체인 및 DLT(분산원장기술)과 함께사용하기 위한 암호화 키 관리 시스템이며 기존 PKI(Public Key Infrasturcture)아키텍처의 핵심가정인 공개 키 인증서가 중앙형 또는 연합형 인증 기관인 CA에서 발급될 것이라는 가정을 없앤다.

DKMS의 장점

단일 실패 지점 없음 : 알고리즘 또는 자체 인증 신뢰루트를 사용하므로 중앙CA 혹은 기타 등록 기관에 의존하지 않는다
상호 운용성 : 두 명의 ID 소유자와 해당 애플리케이션이 독점 소프트웨어, 서비스 제공업체 또는 연합에 의존하지 않고 키 교환을 수행 및 암호화된 P2P연결을 생성 가능하다.
이식성 : 사용자는 DKMS호환 지갑, 에이전트 또는 에이전시의 특정 구현에 종속되는 것을 피할 수 있다.
키 복구 : DKMS를 이용하면 에이전트 자동 암호화 백업, DKMS 키 에스크로 서비스 및 키의 소셜 복구를 포함한 강력한 기 복구가 인프라에 직접 구축되어야 한다.

DKMS가 해결해야할 문제

키를 교체할 수 있는 외부 기관이 있는 경우 해당 기관에사 항상 사용자의 키를 빼앗거나 해당 시스템이 손상되어 키에 침입할 수 있다. 그래서 DKMS에는 “비밀번호 재설정” 옵션이란 없으며 DKMS는 처음부터 키 보유자를 위해 안전장치로 설계되어야 한다.
DKMS는 SSI의 기초가 된 W3C 검증 가능한 자격증명 및 분산 식별자 표준과 같이 모든 오픈 소스 프로젝트 또는 상용 공급업체가 구현할 수 있는 공개 표준을 기반으로 해야한다 이는 Apple iMessage등과 같이 인기 있는 보안 메신저의 접근 방식을 제거한다.
DKMS는 암호화 알고리즘 및 프로토콜의 진화적 발전을 수용할 수 있어야 한다.
DKMS는 최종 사용자를 대신하여 전문 지식이나 기술을 가정할 수 없다. 최신 브라우저 및 이메일 클라이언트만큼 사용하기 쉬어야 하며, 무엇보다도 최종 사용자에게 암호화, 블록체인, SSI 또는 공개키/개인키에 개념과 이해를 요구할 수 없다.

❓ **BlockChain과 DLT 차이**

블록체인은 신뢰가 없거나 비허가형 시스템으로 중앙화된 기관의 허가 없이 새로운 참여자에게 더 개방적
DLT는 신뢰 기반 또는 허가형 시스템으로, 미래의 불특정 참여자가 가입하기 위해서는 일반적으로 허가를 받아야 한다.

자기 주권 신원의 10가지 원칙

존재: 사용자들은 독립적인 존재여야 한다.

어떤 자기주권신원은 궁극적으로 신원의 중심에 있으면서 형언할 수 없는 ‘나’를 기초로한다. 그것은 결코 완전한 디지털 형태로 존재할 수 없으며 이 것은 유지되고 지원되는 자체 커널이어야 한다. 자기주권신원은 단순하게 이미 존재하는 ‘나’의 제한된 일부의 측면을 공개하고 접근 가능하게 한다.
통제: 사용자들은 자신의 신원을 통제해야 한다.

신원과 신원의 클레임의 지속적인 유효성을 보장하는 잘 이해되고 안전한 알고리즘에 따라 사용자는 자신의 신원에 대하여 기본적으로 권한이 있다. 사용자는 항상 참조하거나 업데이트하거나 숨길 수 있어야한다. 사용자는 자신이 원하는 대로 가시적이고, 명성이 있으며 개인정보보호 수준을 선택할 수 있어야하며 사용자가 자신의 신원에 대한 모든 클레임을 제어할 수 있다는 것을 의미하지는 않는다. 다른 사용자가 사용자에 대해 클레임을 제기할 수는 있지만 신원 자체에 중심을 두어서는 안 된다.
접근: 사용자는 자신의 데이터에 접근할 수 있어야 한다.

사용자는 항상 자신의 신원에 있는 모든 클레임 및 데이터를 쉽게 검색할 수 있어야 하며, 자신의 데이터가 가려지거나 숨기는 주체가 없어야 한다. 이것이 사용자가 신원과 돤련된 모든 클레임을 수정할 수 있다는 것을 뜻하지는 않지만, 사용자가 클레임을 알고 있어야 한다는 것을 의미한다. 또한 사용자가 다른 사용자의 데이터에 접근할 수 있는 것이 아니라 자신의 데이터에만 접근할 수 있다는 것을 의미한다.
투명성: 시스템과 알고리즘은 투명해야 한다.

신원 네트워크를 관리하고 운영하는 데 사용되는 시스템은 신원의 작동 방식, 관리 및 업데이트 방식 모두에서 공개되어야 한다. 알고리즘은 자유롭고 오픈소스이며, 널리 알려져 있으면서, 특정 아키텍처에서 가능한 독립적이여야 하며, 누구나 작동 방식을 검사할 수 있어야 한다.
지속성: 신원은 오래 지속되어야 한다.

가급적 신원은 영구적 또는 사용자가 원하는 만큼 지속되어야 한다. 개인키를 순환하고 데이터를 변경해야 할 수 있지만 신원은 그대로 유지된다. 빠르게 변화하는 인터넷 세상에서, 이러한 목표는 완전히 합리적이지 않을 수 있으므로, 최소한 신원은 새로운 시원 시스템에 의해 시대에 뒤떨어지기 전까지 지속되어야 한다. 이는 ‘잊혀질 권리’에 위배 되는 것이 아니라, 사용자가 원할 경우 사용자가 신원을 처리할 수 있어야 하며, 클레임은 시간이 지남에 따라 적절히 수정되거나 삭제되어야 한다. 이를 위해서 신원과 신원의 클레임 사이에 확실한 분리가 필요하며 영구적으로 묶여 있을 수 없다.
이식성: 신원에 대한 정보와 서비스는 전송할 수 있어야 한다

사용자에게 가장 이익이 될 것으로 예상되는 신뢰 가능한 개체인 경우에도 단일한 제 3자가 신원을 보유해서는 안된다. 문제는 그 개체가 사라질 수 있고, 인터넷에서는 대부분 그럴 수 있다는 것이다. 제도는 바뀔 수 있고 사용자는 다른 관할권으로 이동할 수 있기 때문. 전송가능한 신원은 사용자가 어떤 일이 있어도 자신의 신원을 제어할 수 있도록 보장하며 시간이 지남에 따라 신원의 지속성을 향상시킬 수 있다.
상호 운용성: 신원은 가능한 널리 사용할 수 있어야 한다.

제한된 곳에서만 작동하는 신원은 가치가 거의 없다. 21세기 디지털 신원 시스템의 목표는 신원 정보를 널리 사용 가능하게 하여 사용자의 통제력을 잃지 않고 국제적 신원을 만드는 것이며 지속성과 자율성 덕분에, 이러한 널리 이용 가능한 신원들은 지속적으로 이용할 수 있다.
동의: 신원을 사용함에 동의해야 한다.

모든 신원 시스템은 신원과 신원의 클레임을 고유하기 위해 구축되며 상호 운용 가능한 시스템은 공유를 확대한다. 그러나 데이터 공유는 사용자의 동의가 있어야만 가능하다. 고용주, 신용정보 기관 또는 친구와 같은 다른 사용자가 클레임을 요청할 수 있지만, 사용자는 클레임이 유효하도록 동의를 해야 한다. 이 동의는 상호작용방식의 동의가 아닐 수 있지만, 신중하고 잘 이해되는 방식이어야 한다.
최소화: 클레임의 공개를 최소화해야 한다.

데이터가 공개될 때 해당 공개에는 당연한 작업을 수행하는데 필요한 최소한의 데이터가 포함되어야 한다. 예를 들어, 최소한의 연령만 요구하는 경우 정확한 나이를 공개하지 않으면서 연령대만 공개하고 생년월일은 공개하지 않아야 한다. 이 원칙은 선택적 공개, 범위 증명 및 기타 영지식 기술로 뒷받침할 수 있지만, 비상관성은 여전히 매우 어려운 작업이다. 우리가 할 수 있는 최선은 최소화를 사용하여 개인정보보호를 최대한으로 지원하는 것.
보호: 사용자의 권리는 보호되어야 한다.

신원 네트워크의 요구와 개별 사용자의 권리 사이에 충돌이 있을 때 네트워크는 네트워크의 요구보다 개인의 자유와 권리를 보호하는 측면에서 오류를 범해야 한다. 이를 보장하기 위해 신원 인증은 검열 저항성이 있고, 강제 복원력이 있으며 분산 방식으로 실행되는 독립적인 알고리즘을 통해 수행되어야 한다.

SSI의 원칙

표현 : SSI 생태계는 어떠한 개체(인간적, 법적, 자연적, 물리적 또는 디지털적 실체)라도 디지털 신원을 통해 표현될 수 있도록 수단을 제공해야 한다.
상호 운용성: SSI 생태계는 로열티가 없는 공개 표준을 사용함으로써 각각의 개체를 위한 디지털 신원 데이터가 상호운용적으로 표현, 교환, 보호되도록 해야 한다
분산화: SSI 생태계는 개체의 디지털 신원 데이터를 표현, 통제, 검증하는데 있어 중앙형 시스템이 요구되지 않도록 해야 한다.
통제 및 대리: SSI생태계는 자신의 신원과 관련된 자연적, 인간적, 법적 권리를 가진 개체(신원권리 보유자)가 자신의 디지털 신원을 사용할 수 있는 통제권을 제공하고, 또한 자신이 선택한 대리자 혹은 보호자에게 그 권한을 위임함으로써 이러한 통제권을 행사할 수 있는 권리 역시 제공해야 한다. 이러한 위임의 대상은 개인, 조직, 기기 그리고 소프트웨어를 포함한다.
참여: SSI생태계는 신원 권리 보유자의 참여가 요구되지 않도록 해야 한다.
형평성과 포용: SSI생태계는 신원 권리 보유자가 그 거버넌스 구조 내에서 배제되거나 소외되지 않도록 해야 한다.
사용성, 접근성 및 일관성 : SSI 생태계는 신원 권리 보유자가 에이전트 및 기타 SSI 구성요소에 대한 사용성, 접근성 그리고 사용자 경험의 일관성 측면이 극대화될 수 있도록 해야 한다.
이식성: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터 사본을 에이전트나 자신이 선택한 시스템으로 이동 또는 전송할 수 있는 가능성을 제한하지 않아야 한다.
보안: SSI 생태계는 신원 권리 보유자가 안전하게 자신의 디지털 신원 데이터를 보호하고, 자신의 식별자와 암호화 키를 관리할 수 있으며, 모든 상호작용에 대해 종단 간 암호화가 적용될 수 있는 환경을 제공해야 한다.
검증 가능성 및 진위성: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터에 대한 진위성을 검증할 수 있는 증거를 제공할 수 있도록 해야 한다.
프라이버시 및 최소한의 공개: SSI 생태계는 신원 권리 보유자가 자신의 디지털 신원 데이터에 대한 프라이버시를 보호할 수 있도록 하고, 특정 상호작용에 대해 요구되는 최소한의 디지털 신원 데이터를 공유할 수 있도록 해야 한다.
투명성: SSI 생태계는 신원 권리 보유자 및 다른 이해 관계자들이 SSI 생태계의 에이전트 및 기타 구성요소가 작동하는 인센티브, 규칙, 정책 및 알고리즘을 이해하는 데 필요한 정보에 쉽게 접근하고 검증할 수 있어야 한다.

이더리움 블록체인 생태계에서의 신원

ERC 725와 ERC 1056은 서로 다른 기능을 하는 자기주권신원에 대한 두 가지 접근 방식이다. ERC 725는 이더리움 계정을 공개된 온체인 신원으로 만드는 데 중점을 두고 있으며, 여기에는 정보를 얼마든지 추가할 수 있다. 이것은 주로 블록체인에 활성화 되고 다른 블록체인의 첨여자들과 성호 작용하기 위한 것이다. 이와 대조적으로 ERC 1056은 모든 신원 정보를 오프체인으로 유지한다. 온체인 스마트 컨트랙트는 해당 신원에 대한 공개 키 레지스트리 역할을 한다. 이더리움에서 작업을 수행하는 다른 방법은 항상 존재하기 때문에 더 많은 방법이 있을 수 있다