이 명세는 하나 이상의 개인 및/또는 조직과 같은 하나 이상의 인식된
엔터티가 검증
가능한 자격 증명의 발급 또는 검증과 같은 특정 작업을
수행하는 것으로 알려져 있음을 설명할 수 있는 데이터 모델을 기술한다. 이
데이터 모델은 이러한 정보의 공개 또는 직접 공유를 가능하게 하며,
보유자가 자신이 사용하는
자격 증명의 엔터티가 특정 생태계 내에서 인식되고 있음을 입증할 수 있는
암호학적으로 검증 가능하고 개인정보 보호적인 메커니즘을 제공한다. 이
명세는 X.509 인증 기관 목록 및 ETSI 신뢰 서비스 목록과 같은 기존
"신뢰 인프라"와 상호 운용되도록 설계되었으며,
검증 가능한 자격
증명을 사용하여 새로운 탈중앙화 생태계를 구축할 수 있도록 한다.
이 문서의 상태
이 절은 이 문서가 공개된 시점의
상태를 설명한다. 현재 W3C
공개 문서 목록과 이 기술 보고서의 최신 개정판은
W3C 표준 및 초안
색인에서 확인할 수 있다.
최초 공개 작업 초안으로 공개되었다고 해서
W3C와 그 회원들의 승인을 의미하지는 않는다.
이것은 초안 문서이며 언제든지 다른 문서로 업데이트되거나 대체되거나
폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은
부적절하다.
이 문서는
W3C
특허
정책에 따라 운영되는 그룹이 작성했다.
W3C는
해당 그룹의 산출물과 관련하여 이루어진
모든 특허 공개의 공개 목록을
유지하며, 해당 페이지에는
특허 공개를 위한 지침도 포함되어 있다. 어떤 개인이
필수 청구항을
포함한다고 믿는 특허에 대해 실제 지식을 가지고 있는 경우, 그 개인은
W3C 특허 정책 제6절에 따라 그 정보를 공개해야 한다.
검증 가능한 자격
증명
생태계는 검증자가
특정 발급자가 특정 작업,
예를 들어 특정 유형의 발급이나 검증 가능한 자격 증명과
같은 작업을 수행하도록 인식되어 있는지 판단할 수 있는 능력에 의존한다.
역사적으로 이러한 판단은 자동화된 방식으로 발견, 질의 또는 추론하기 어려운
대역 외 프로세스, 양자 간 합의 또는 독점 레지스트리를 통해 이루어지는 경우가 많았다.
검증 가능한 자격
증명이
교육, 의료, 금융 서비스, 정부와 같은 여러 부문에 점점 더 배포됨에 따라,
알려진 작업을 수행하는 엔터티에 대한 인식을 표현하고 전달하기 위한
표준화되고 상호 운용 가능한 메커니즘의 필요성이 중요해졌다. 이러한 메커니즘이
없으면 생태계 참여자는 맞춤형 "신뢰 인프라"를 구축해야 하며, 이는 파편화,
통합 비용 증가, 국경 간 및 부문 간 상호 운용성의 장벽으로 이어진다.
이 명세는 사람과 조직 같은 인식된 엔터티와 그들이 수행하는 작업,
예를 들어 발급 및 검증을 탈중앙화된 방식으로 표현하는 과제를 다룬다.
이를 위해 모든 엔터티가 인식 정보를 검증 가능한 자격 증명으로
공개하거나 공유하는 데 사용할 수 있는 데이터 모델을 정의한다.
단일 중앙 레지스트리를 의무화하는 대신, 이 모델은 정부 기관, 산업 컨소시엄,
표준화 기구 또는 단일 개인까지도 하나 이상의 엔터티가 특정 작업을 수행하도록
인식되어 있음을 자신들이 알고 있다고 주장하는
VerifiableRecognitionCredential을 발급할 수 있게 한다. 이 설계는
서로 겹치고, 경쟁하며, 보완하는 "신뢰 레지스트리"의 웹이 공존할 수 있게 하며,
생태계 참여자가 자신이 신뢰하는 엔터티를 선택하고 여러 레지스트리에 걸쳐
추론할 수 있게 한다. 또한 이 명세는 X.509 인증 기관 목록 및 ETSI 신뢰 서비스 목록과
같은 기존 "신뢰 인프라"와의 상호 운용성을 지원하여, 기존의 인식된 엔터티 정보를
새로운 탈중앙화 생태계에 참조하고 결합할 수 있게 한다.
.
이 문서의 나머지 부분은 다음 절들로 구성된다:
Section 2. 데이터 모델은
RecognizedEntity, RecognizedAction,
VerifiableRecognitionCredential
유형과 그 속성 및 실제 예제를 포함하여 핵심 데이터 모델을 정의한다.
비규범으로 표시된 절뿐만 아니라, 이 명세의 모든 작성 지침, 도표, 예제 및 참고는
비규범적이다. 이 명세의 그 밖의 모든 내용은 규범적이다.
이 문서에서 핵심 단어 MAY, MUST, OPTIONAL, SHOULD는
여기에 표시된 것처럼 모두 대문자로 나타날 때에만
BCP 14
[RFC2119] [RFC8174]에
설명된 대로 해석되어야 한다.
적합 문서는
이 명세의 규범적 진술을 준수하는 데이터 모델의 구체적 표현이다. 구체적으로,
이 문서의 Section
2. 데이터 모델에 있는 모든 관련
규범적 진술은 MUST 준수되어야 한다.
적합 처리기는
적합 문서를 생성하거나 소비하는 소프트웨어 및/또는 하드웨어로
구현된 모든 알고리즘이다. 적합 처리기는
부적합 문서가 소비될 때 오류를 MUST 생성해야 한다.
이 문서에는 JSON 및 JSON-LD 콘텐츠를 포함하는 예제도 포함되어 있다. 이러한
예제 중 일부에는 인라인 주석(//) 및 예제에 큰 가치를 더하지 않는
정보를 나타내기 위한 생략 기호(...) 사용과 같이 유효하지 않은 JSON 문자가
포함되어 있다. 구현자는 해당 정보를 유효한 JSON 또는 JSON-LD로 사용하려는 경우
이러한 콘텐츠를 제거해야 한다는 점에 유의해야 한다.
2. 데이터 모델
다음 절들은 이 명세가 검증 가능한 발급자 및 검증자 목록에 사용하는
데이터 모델을 개략적으로 설명한다.
이 절에 설명된 데이터 모델은 EBSI Trusted Issuer Registry,
ETSI TS 119 612, eSSIF-Lab TRAIN, Trust over IP Foundation Trust Registry Protocol,
Rebooting the Web of Trust 입력 문서를 포함하여, 이 문서를 위해 평가된 다양한 선행 기술의
입력을 바탕으로 구축되었다. 이 절에 설명된 데이터 모델은 다른 명세에 설명된
많은 개념을 표현할 수 있지만, 전부를 표현할 수 있는 것은 아니다.
이 작업을 위한 통합 데이터 모델은 자격 증명 발급 또는 검증과 같은 서비스를
제공하는 엔터티 또는 조직을 나타내는 서비스 제공자의 목록으로 표현할 수 있다.
이 데이터 모델에는 목록 운영자 설명의 세부 정보도 포함된다.
2.1 일반 속성
이 절의 속성은 Section
2.4 VerifiableRecognitionCredential에서 정의된
VerifiableRecognitionCredential에서 발견되는 객체에 추가될 수 있다. 이 절에 나열된 각 일반
속성은 OPTIONAL이며, 어떤 값도
발급자가
제공할 필요는 없다.
이 특정 인식된 엔터티와
그것이 수행하는 것으로 알려진 작업을 포함하는 인식된 엔터티 문서에 대한
참조를 포함하는 객체. 객체의 id 값은 MUSTURL이어야 한다.
객체의 type 값은
Verifiable Credentials Data Model
v2.0 명세에 정의된
type 값 공간 을
MUST 준수해야 하며,
EtsiTrustServiceList,
x509CertificateAuthorityList, 또는
VerifiableRecognitionCredential이어야
SHOULD 한다.
인식 작업을 수행한 엔터티의
URL 또는
Section
2.1 일반 속성의 속성을 포함하는 객체.
outputValidation
outputValidation
속성의 값은 검증자에게
제공된 데이터가 제공된 스키마에 부합하는지 판단하기에 충분한 정보를 제공하는
하나 이상의 데이터 스키마여야 MUST 한다.
각 검증기는 자신의 type(예: JsonSchema)과
스키마 파일을 식별하는 URL이어야 하는
id 속성을 MUST 지정해야 한다.
구체적인 유형 정의는 각 데이터 스키마의 정확한 내용을 결정한다.
여러 스키마가 존재하는 경우, 유효성은 관련된 각 type
속성이 개괄하는 처리 규칙에 따라 결정된다.
인식된 엔터티는 검증 가능한 자격 증명
내부에 표현되어, 보유자가
이를
검증자에게
직접 제공할 수 있게 한다. 때때로 "인증서 스테이플링"이라고 불리는 이 메커니즘은
검증자가
인식 자격 증명을 가져오기 위해
발급자에게
연락할 필요가 없도록 하여
보유자의
개인정보 보호를 향상시킨다. 다만,
검증자는 예를 들어
더 최신 버전의 인식 자격 증명을 원한다면,
그 진정성이 검증 가능하더라도 보유자가 제공한
인식 자격 증명을 무시할 수도 있다.
속성
설명
id
인식된 엔터티 집합을 포함하는 검증 가능한
자격 증명은 다른 시스템이 더 쉽게 검색할 수 있도록 id 속성을
표현할 MAY 있다.
type
인식된 엔터티 집합을 포함하는 검증 가능한
자격 증명은
VerifiableRecognitionCredential
값을 포함하는 type 속성을 MUST
표현해야 한다.
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":{"id":"did:web:learning-commission.example","type":"RecognizedIssuer"},"validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:university.example","type":"RecognizedEntity","name":"Example Tech","legalName":"Example Polytechnic University","image":"https://university.example/logo.png","url":"https://www.university.example/","description":"A university providing a great education in Utopia Valley.",},{"id":"did:web:college.example","type":"RecognizedEntity","name":"Exemplar Community College","legalName":"Community College of Examples and ","image":"https://college.example/graphics/ecc.png","url":"https://college.example/","description":"The backbone of learning in the Utopia community.",}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:accreditor.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}}
다음 예제는 특정 유형의 검증 가능한 자격 증명에
대한 알려진 발급자 집합에 관한 정보를 공개하는 데 사용된다.
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":{"id":"did:web:learning-commission.example","type":"RecognizedIssuer"},"validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:university.example","type":"RecognizedEntity","name":"Example Tech","legalName":"Example Polytechnic University","image":"https://university.example/logo.png","url":"https://www.university.example/","description":"A university providing a great education in Utopia Valley.","recognizedTo":{"type":"RecognizedAction","action":"issue","recognizedBy":"did:web:learning-commission.example","outputValidation":{"id":"https://learning-commission.example/credentials/bachelors.json","type":"JsonSchema","digestMultibase":"uEiBZl963sknNAHgPyslVv6VztZpfWQoRvW1htfx-UwirFo",}}},{"id":"did:web:college.example","type":"RecognizedEntity","name":"Exemplar Community College","legalName":"Community College of Examples and ","image":"https://college.example/graphics/ecc.png","url":"https://college.example/","description":"The backbone of learning in the Utopia community.","recognizedTo":{"type":"RecognizedAction","action":"issue","recognizedBy":"did:web:learning-commission.example","outputValidation":{"id":"https://learning-commission.example/credentials/associates.json","type":"JsonSchema","digestMultibase":"uEiWQoRvpfWW1htfsknNAHgPyslVv6VztZpfwirFoBZl963",}}}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:accreditor.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}}
아래의 마지막 예제는 유럽 연합 ETSI 신뢰 서비스 목록 [ETSI-TRUST-LISTS]을
공개하는 엔터티에 대한 정보를 공개하는 데 사용된다.
{"@context":["https://www.w3.org/ns/credentials/v2","https://www.w3.org/ns/credentials/examples/v2"],"type":["VerifiableCredential","VerifiableRecognitionCredential"],"issuer":"did:web:ec.europa.example","validFrom":"2025-01-01T00:00:00Z","validUntil":"2030-01-01T00:00:00Z","credentialSubject":[{"id":"did:web:ec.europa.example","type":"RecognizedEntity","name":"Utopian Commission","legalName":"The Utopian Commission","image":"https://ec.europa.example/logo.png","url":"https://ec.europa.example/","recognizedIn":{"id":"https://ec.europa.example/tsl/lotl.xml","type":"EtsiTrustServiceList","name":"Utopian Commission List of the Lists"}}],"proof":{"type":"DataIntegrityProof","created":"2026-04-10T20:08:22Z","verificationMethod":"did:web:ec.europa.example#issuance-key-1","cryptosuite":"ecdsa-rdfc-2019","proofPurpose":"assertionMethod","proofValue":"z36XPGByaH3rvtKfwoEQXsnUXUAjwd2Ceiqke1GPfjAPAFYoXKo5ftPdwE7QZ8Mw22SC5LSRQg1d8bhe3252hYJoH"}}
3. 개인정보 보호 고려사항
이 절은 이 명세를 프로덕션 환경에 배포할 때의 일반적인 개인정보 보호 고려사항과
구체적인 개인정보 보호 영향을 자세히 설명한다.
VerifiableRecognitionCredential은 이름이 지정된 조직과 사람을
그 식별자, 법적 이름, URL 및 이미지와 함께 공개적으로 나열한다. 이러한 정보를
여러 목록에 걸쳐 집계하면 인식된 엔터티에 대한 프로파일링과 감시가 가능해진다.
이 절은 특히 개인에 대해 풍부하게 설명된 엔터티 정보를 공개할 때의 위험과,
공개를 최소화하기 위한 발급자 지침을 논의해야 한다. 예를 들어, 비공개 그룹에
공개된 인식된 엔터티 목록은 그룹 구성원 중 누구라도 그 정보를 비공개 그룹
밖에 공개하기로 결정하면 해당 그룹을 벗어날 수 있다.
여기서는 선택적 공개가 정직한 행위자를 필요로 하므로 큰 보호를 제공하지 못한다는
점을 제안한다.
3.2 보유자가 제공한
인식 자격 증명
이슈 2
보유자가 인식 자격 증명을 제공하게 하는 것은 검증자가 인식 자격 증명을
가져오기 위해 발급자에게 연락하는 것보다 개인정보 보호를 더 잘 보존한다.
3.3 연관에 의한 피해
이슈 3
VerifiableRecognitionCredential은 의료 자격 증명 발급자나
금융 서비스 제공자와 같은 비공개 또는 민감한 생태계의 구성 구조를 드러낼 수 있다.
이러한 자격 증명을 공개하거나 널리 공유하면 어떤 엔터티가 그 생태계에
참여하는지 노출될 수 있으며, 이는 상업적으로 민감하거나 표적화 위험을
만들 수 있다. 이 절은 민감한 생태계를 설명하는 인식 자격 증명의 배포를
언제 그리고 어떻게 제한할지 논의해야 하며, 인식 자격 증명의 배포를 제한하는
것이 불가능할 수 있으므로 민감한 생태계를 위해 이를 생성하는 것이
안티패턴일 수 있음을 제안할 수도 있다. 일반적으로 특정 구성원을 가진
특정 목록을 만들면 의도했든 아니든 개인에게 부정적 영향(연관에 의한 피해)을
미칠 수 있다.
4. 보안 고려사항
이 명세가 설명하는 데이터를 처리할 때 구현자가 알아야 할 여러 보안 고려사항이 있다.
이 절의 함의를 무시하거나 이해하지 못하면 보안 취약점이 발생할 수 있다.
이 절은 광범위한 보안 고려사항을 강조하려고 하지만, 완전한 목록은 아니다.
구현자는 이 명세에서 개괄한 기술을 사용하여 임무상 중요한 시스템을 구현할 때
보안 및 암호학 전문가의 조언을 구할 것을 권장한다.
4.1 공유하기 전에 검증
보유자가
VerifiableRecognitionCredential을 받아 다른 사람과 공유할 때,
그 자격 증명이 제대로 검토되지 않았을 위험이 있다. 악의적이거나 부주의한 행위자는
사기성 또는 손상된 엔터티를 인식된 발급자 또는 검증자로 나열하는
VerifiableRecognitionCredential을 만들고, 이를 생태계 전반에
P2P 방식으로 전파할 수 있다. 독립적인 검증 없이 이러한 자격 증명을 수락하고
그에 따라 행동하는 수신자는 자신도 모르게 신뢰할 수 없는 출처의
검증 가능한
자격 증명을
받아들일 수 있으며, 자신과 타인을 사기, 데이터 유출 또는 자격 증명 위조에
노출시킬 수 있다. 이 명세의 탈중앙화된 특성은 장점이지만, 동시에 이 위험을
증폭시킨다. 널리 공유된 단 하나의 검토되지 않은 자격 증명만으로도 생태계 내 많은
당사자의 신뢰 가정이 빠르게 손상될 수 있다.
이러한 위험을 완화하기 위해, 배포 환경은 VerifiableRecognitionCredential에
따라 행동하거나 이를 더 공유하기 전에 그 암호학적 무결성과 출처를 독립적으로
검증해야 한다. 여기에는 자격 증명의
발급자가
해당 인식 도메인에 대해 구현자가 신뢰할 확립된 이유가 있는 당사자인지,
그리고 자격 증명이 만료되거나 폐기되지 않았는지 확인하는 것이 포함된다.
구현자는 동료가 이미 자격 증명을 수락했다는 사실만을 그 유효성의 증거로
의존할 수 없다. 대신
검증자는
VerifiableRecognitionCredential을 받는 것과 독립적으로 인식 자격 증명의
발급자와 인식된 작업을 검토해야 하며,
발급 엔터티에 대한 신뢰가 확립된 뒤에야 자격 증명의 정보에 의존할 수 있다.
4.2 발급자 사칭
이슈 4
악의적 행위자는 유사한 issuer 식별자나 이름을 사용하여
잘 알려진 인식 기관을 모방하는 VerifiableRecognitionCredential을
만들 수 있다. VRC를 소프트웨어에 수동으로 추가하지만 알려진 신뢰 루트에 대해
발급자의 식별자를 독립적으로 검증하지 않는 검증자는 사기성 인식 주장을
받아들이도록 속을 수 있다. 이 절은 발급자 사칭을 감지하고 방지하는 방법과,
권위 있는 대역 외 수단을 통해 발급자 식별자를 검증하는 것의 중요성을
논의해야 한다.
프로토콜 및 사용자 상호작용에 대한 적절한 바인딩(예: 개인이 origin에서 요청을
받는 경우)에 유의한다. 지갑이 "이 origin/issuer에 대해 당신이 신뢰하는
누군가로부터 받은 인식 자격 증명을 가지고 있습니다"라고 전달하면 좋을 것이다
(요청을 origin에 바인딩하는 확인이 이루어지는 경우, 예를 들어 TLS 사용)
그리고 그것이 VRC의 issuer와 연결된다. 이 절은 개인이 사기에 빠지지 않도록 돕기 위해
프로토콜이 이러한 종류의 정보를 어떻게 함께 바인딩할 수 있는지에 대해
논의하는 것이 좋다.
4.3 적절한
유효 기간 선택
이슈 5
지나치게 긴 validUntil 기간을 가진 인식 자격 증명은 인식된 엔터티가
정지, 폐기 또는 손상된 뒤에도 오랫동안 유통될 수 있다. 반대로 지나치게 짧은
유효 기간은 운영 부담을 만든다. 이 절은 적절한 유효 기간 선택과
유효 기간을 강력한 폐기 메커니즘과 함께 사용하는 것의 중요성을 논의해야 한다.
이 절은 조직/개인의 수명 종료에 대해서도 다루어야 한다. 기간이 얼마나 길어야
하는지는 목록 크기와 다양성에 따라 달라진다. 목록이 클수록 기간은 더 짧아야
하며(24-48시간?), 목록이 작을수록 기간은 더 길 수 있다(몇 주에서 몇 달).
합리적인 시간 프레임 내에 엔터티를 추가할 수 있어야 한다. 생태계는 목록
집계자를 원할 수 있으며, 인증 기관은 더 긴 기간을 가질 수 있다. 이 절은
더 긴 기간을 가지는 것의 정당화, 즉 왜 24-48시간보다 더 길게 가야 하는지를
설명해야 한다.
4.4 외부 리소스 변조
이슈 6
outputValidation 속성은 URL을 통해 외부 스키마 파일을 참조한다.
이러한 URL이 digestMultibase 또는 다른 무결성 검사를 통해 보호되지 않는 경우,
스키마 호스트를 손상시킨 공격자가 인식 자격 증명을 무효화하지 않고도 검증 규칙을
변경하여, 검증자가 더 이상 의도된 스키마를 준수하지 않는 자격 증명을
받아들이게 만들 수 있다. 이 절은 외부에서 참조되는 모든 리소스에 대해
콘텐츠 무결성 보호를 사용하는 것의 중요성을 논의해야 한다.
4.5 인식 체인 검증
이슈 7
recognizedIn 속성은 인식 자격 증명이 ETSI 신뢰 서비스 목록,
X.509 인증 기관 목록 또는 다른 VerifiableRecognitionCredential과 같은
다른 레지스트리로 체인될 수 있게 한다. 검증자가 깊이 제한을 적용하지 않거나
체인의 각 링크를 독립적으로 검증하지 않는 경우, 하위 수준 레지스트리의
손상되었거나 악의적인 항목이 전이적으로 신뢰될 수 있다. 이 절은 체인된
인식 구조를 탐색할 때의 안전한 관행과 무제한 전이 신뢰의 위험을
논의해야 한다.
4.6 인식된 작업의 남용
이슈 8
action 속성은 자유 형식 문자열이다(예: issue,
verify). 생태계 내에서 허용 가능한 작업 값에 대한 엄격한 거버넌스가
없으면, 인식된 엔터티가 광범위하거나 정의되지 않은 작업을 주장하는 자격 증명을
제시할 수 있고, 검증자가 이를 의도보다 더 관대하게 해석하여 발급자의 의도를
넘어서는 무단 사용으로 이어질 수 있다. 이 절은 작업 어휘에 대한 생태계 수준
거버넌스의 중요성과 검증자가 인식되지 않은 작업 값을 어떻게 처리해야 하는지를
논의해야 한다.
A. 다른 기술과의 관계
이 절은 비규범적이다.
이 명세는 기존 "신뢰 인프라" 기술을 인식하여 설계되었으며,
그중 세 가지가 아래에 설명되어 있다. 이 명세에 정의된 데이터 모델은
이러한 기술에서 발견되는 많은 개념을 표현할 수 있으며,
recognizedIn 속성을 통해 이들과 상호 운용되도록 설계되었다.
A.1 ETSI 신뢰 서비스 목록
이 절은 비규범적이다.
European Telecommunications Standards Institute (ETSI)는
[ETSI-TRUST-LISTS]에서
Trust Service Lists (TSLs)의 형식을 정의한다. 이는 유럽 연합 전역에서
eIDAS 규정에 따라 전자 서명, 전자 인장, 타임스탬프 및 기타 신뢰 서비스를
발급할 권한이 있는 엔터티인 신뢰 서비스 제공자 목록을 공개하는 데 사용된다.
각 EU 회원국은 국가 TSL을 공개하고, 유럽 위원회는 각 국가 TSL을 참조하는
List of the Lists (LoTL)를 공개하여 잘 정의된 계층적 신뢰 연합을 형성한다.
ETSI 신뢰 서비스 목록은 이 명세와 몇 가지 개념적 목표를 공유한다. 둘 다
특정 작업을 수행하도록 인식된 엔터티를 설명하고, 해당 엔터티를 식별 메타데이터와
연결하며, 검증 중에 의존 당사자가 소비하도록 의도되어 있다. 그러나 이 명세는
ETSI 신뢰 서비스 목록과 몇 가지 중요한 방식에서 다르다:
형식: ETSI 신뢰 서비스 목록은 서명된 XML 문서로 표현된다.
이 명세는 JSON-LD와 Verifiable Credentials Data Model을 사용하여,
더 넓은 탈중앙화 신원 생태계와의 통합을 가능하게 한다.
거버넌스: ETSI 신뢰 서비스 목록은 EU 회원국 기관에 뿌리를 둔
중앙화되고 계층적인 구조에 의해 관리된다. 이 명세는 중앙화 및 탈중앙화
거버넌스 모델을 모두 지원하여, 어떤 엔터티든 자신의 생태계 내에서
인식 기관으로 행동할 수 있게 한다.
범위: ETSI 신뢰 서비스 목록은 eIDAS에 따라 규제되는
전자 신뢰 서비스로 범위가 한정된다. 이 명세는 도메인에 구애받지 않으며
교육, 의료, 금융 서비스를 포함한 모든 부문에서 인식을 표현할 수 있다.
보유자 중심 공유: ETSI 신뢰 서비스 목록은 잘 알려진 URL에
공개되고 의존 당사자가 가져온다. 이 명세는 보유자가 검증자에게 인식 자격 증명을
직접 제시하는 "인증서 스테이플링"도 추가로 지원하여, 검증자가 각 상호작용마다
중앙 레지스트리에 연락할 필요를 줄인다.
A.2 X.509 인증 기관
목록
이 절은 비규범적이다.
X.509 [RFC5280]는
공개 키 인프라(PKI)를 위한 표준으로, 인증서와 인증서 체인의 형식을 정의한다.
Certificate Authorities (CAs)는 공개 키를 신원에 바인딩하는 X.509 인증서를 발급하도록
신뢰되는 엔터티이다. CA에 대한 신뢰는 일반적으로 브라우저 또는 운영 체제 신뢰 저장소,
즉 루트 CA의 선별된 목록에 포함되거나, 그러한 루트로 거슬러 올라가는 인증서 체인을
통해 확립된다.
X.509 CA 인프라와 이 명세는 모두 주어진 엔터티가 주어진 맥락에서 특정 작업을
수행하도록 의존할 수 있는지를 확립하는 문제를 다룬다. 그러나 이 명세는
X.509 CA 목록과 몇 가지 중요한 방식에서 다르다:
데이터 모델: X.509 인증서는 식별자와 공개 키의 연결을
고정 스키마를 가진 바이너리 ASN.1 형식으로 인코딩한다. 이 명세는 인식된
식별자와 그 식별자가 나타내는 엔터티가 수행하도록 허가된 작업에 대한
임의의 메타데이터를 표현할 수 있는 유연하고 확장 가능한 JSON-LD 데이터 모델을
사용한다.
신뢰 계층: X.509 PKI는 소수의 전 세계적으로 신뢰되는 루트 CA에
뿌리를 둔 엄격한 계층적 신뢰 체인에 의존한다. 이 명세는 여러 개의 겹치고,
경쟁하며, 공존하는 인식 레지스트리가 존재할 수 있고, 생태계 참여자가
어떤 인식 기관을 신뢰할지 선택할 수 있는 신뢰 웹 모델을 지원한다.
작업 의미론: X.509 인증서는 인증서가 무엇에 사용될 수 있는지를
제한하기 위해 key usage 및 extended key usage 플래그를 표현하지만, 이는 고정된
암호학적 작업 집합으로 제한된다. 이 명세는 특정 유형의 자격 증명을 발급하는 것과
같은 임의의 도메인별 작업에 대한 인식을 표현하여, 더 풍부하고 맥락에 특화된
인식 주장을 가능하게 한다.
탈중앙화된 발급: 기존 신뢰 저장소에 새로운 CA를 추가하려면
브라우저 공급업체 및/또는 OS 유지관리자의 승인이 필요하며, 이는 중앙화되고
종종 느린 과정이다. 이에 비해 이 명세는 어떤 엔터티든 중앙 게이트키퍼의 승인을
요구하지 않고 VerifiableRecognitionCredential을 발급하고 자신의 생태계 내에서
공유할 수 있게 한다.
A.3 ISO/IEC 18013-5 mDL VICAL
이 절은 비규범적이다.
ISO/IEC 18013-5는 운전면허증을 모바일 문서(mDocs)로 표현하기 위한 표준인
mobile Driving License (mDL)을 정의한다. 그 생태계의 일부로, 이 표준은 mDL을
발급할 권한이 있는 인증 기관으로 인식된 엔터티 목록을 포함하는 서명된 데이터 구조인
Verified Issuer Certificate Authority List (VICAL)를 정의한다. 의존 당사자는 제시된
mDL의 발급자가 자신의 관할권 내에서 신뢰되는지 판단하기 위해 VICAL을 사용한다.
VICAL 개념과 이 명세는 의존 당사자가 특정 생태계 내에서 자격 증명 발급자가
인식되어 있는지 판단할 수 있게 한다는 목표를 공유한다. 그러나 이 명세는
mDL VICAL과 몇 가지 중요한 방식에서 다르다:
형식: VICAL은 mDL 생태계에 긴밀하게 결합된 CBOR 인코딩,
COSE 서명 데이터 구조이다. 이 명세는 JSON-LD와 Verifiable Credentials Data Model을
사용하여, 더 넓은 범위의 자격 증명 유형과 배포 환경에 적합하다.
범위: VICAL은 mDL 사용 사례와 ISO/IEC 18013-5 신뢰 모델에
특화되어 있다. 이 명세는 모든 유형의 자격 증명을 사용하여 모든 유형의
검증 가능한 자격 증명과 모든 종류의 작업에 대한 인식을 표현할 수 있으며,
운전면허증 발급에만 제한되지 않는다.
작업 표현력: VICAL은 mDL 인증서를 발급하도록 신뢰되는 CA를
기록하지만, CA가 수행하도록 인식된 범위나 다른 유형의 작업을 표현하기 위한
일반적 메커니즘은 가지고 있지 않다. 이 명세의 RecognizedAction 구조는
인식된 엔터티가 수행하도록 허가된 작업과 그 작업이 적용되는 자격 증명 스키마를
명시적으로 포착하여, 더 세밀한 권한 부여를 가능하게 한다.
탈중앙화: VICAL은 각 mDL 생태계 내의 지정된 VICAL 제공자가 관리하며
중앙화된 채널을 통해 배포된다. 이 명세는 어떤 엔터티든 지정된 중앙 제공자에
의존하지 않고 인식 자격 증명을 공개할 수 있게 하여, 더 개방적이고 조합 가능한
신뢰 생태계를 지원한다.
B. 감사의 말
이 절은 비규범적이다.
워킹 그룹은 커뮤니티에 상당한 기여를 한 다음 개인들에게 감사한다: TBD
이 명세 작업은 Christopher Allen, Joe Andrieu 및 Erica Connell이 촉진한
Rebooting the Web of Trust 커뮤니티의 지원을 받았다. Phil Windley, Kaliya Young,
Doc Searls 및 Heidi Nobantu Saul이 촉진한 Internet Identity Workshop의 참가자들도
이 명세에 대해 교육하고, 토론하며, 개선하도록 설계된 수많은 작업 세션을 통해
이 작업의 정교화를 지원했다.
워킹 그룹은 명세를 검토하고 피드백을 제공한 다음 개인들에게 감사하고자 한다
(알파벳순):