이 문서는 W3C Verifiable Credentials Data Model v1.0의 한국어 번역본입니다.
이 문서에 오역 및 오타를 포함할 수 있습니다. 영어 원문만이 공식적이고 규범적인 효력을 가지고 있습니다.
문의나 개선사항은 깃헙 링크나 [email protected]으로 연락주시기 바랍니다.
원문작성일: 2019-11-19
최초번역일: 2020-01-11
최종수정일: 2020-06-01
크리덴셜(자격)은 우리 일상 생활의 일부이다. 운전면허증은 우리가 자동차를 운전할 수 있음을 주장하는데 사용하고, 대학 학위는 교육 수준을 주장하는데 사용하며, 정부가 발급한 여권은 국가 간 여행을 가능하게 한다. 본 사양에서는 웹 상에서 이러한 종류의 크리덴셜을 암호학적으로 안전하고, 프라이버시를 존중하며, 기계가 읽을 수 있는 방식으로 표현하는 메커니즘을 제공한다.
크리덴셜(자격)은 우리 일상 생활의 일부이다. 운전면허증은 우리가 자동차를 운전할 수 있음을 주장하는데 사용하고, 대학 학위는 교육 수준을 주장하는데 사용하며, 정부가 발급한 여권은 국가 간 여행을 가능하게 한다. 이러한 크리덴셜은 물리적 환경에서 사용할 때는 우리에게 이점을 제공하지만, 웹에서 사용하기는 어렵다.
현재 웹에서 교육 자격, 의료 데이터, 금융 계정 정보 및 기타 제 3 자의 기계적 검증(판독)이 가능한 개인 정보를 표현하기는 어렵다. 웹에서 디지털 크리덴셜을 표현하는 것이 어렵기 때문에 실제 세계에서 물리적 크리덴셜이 제공하는 것과 동일한 인정을 받기가 어렵다.
본 사양에서는 웹 상에서 이러한 종류의 크리덴셜을 암호학적으로 안전하고, 프라이버시를 존중하며, 기계가 읽을 수 있는 방식으로 표현하는 메커니즘을 제공한다.
검증가능한 크리덴셜과 관련된 개념에 익숙치 않은 분들을 위해, 다음 섹션에서는 다음과 같은 개요를 제공한다.
물리적 환경에서 크리덴셜은 다음과 같은 정보로 구성될 수 있다.
검증가능한 크리덴셜은 물리적 크리덴셜이 나타내는 것과 동일한 모든 정보를 나타낼 수 있다. 검증가능한 크리덴셜은 디지털 서명과 같은 기술을 추가하여 물리적 크리덴셜보다 신뢰할 수 있고 변조확인이 가능하도록(Tamper-evident) 만들 수 있다.
검증가능한 크리덴셜의 보유자는 검증가능한 프레젠테이션을 생성한 다음 검증가능한 프레젠테이션을 검증자와 공유하여 특정 특성을 가진 검증가능한 크리덴셜을 보유하고 있음을 증명할 수 있다.
검증가능한 크리덴셜과 검증가능한 프레젠테이션은 신속하게 전송 가능하므로, 먼 거리에서 신뢰를 구축하려고 할 때 물리적 크리덴셜보다 더 편리하다.
본 사양의 목표는 디지털 크리덴셜 표현의 용이성을 향상시키려는 것이지만, 그와 더불어 개인 정보 보호 목표와의 균형을 맞추고자 한다. 디지털 정보의 지속성과 이질적인 디지털 데이터 소스를 수집하고 상호 연관시킬 수 있다는 용이성은, 검증가능하면서도 쉽게 기계가 읽을 수 있는 크리덴셜의 사용이 개인 정보 보호를 악화시킬 수 있다는 우려를 야기한다. 본 문서의 섹션 에서 이러한 여러 문제를 간략하게 다룬다. 또한 문서 전체적으로 영지식증명(Zero-knowledge Proof)과 같은 프라이버시 향상 기술을 사용하여 어떻게 이 데이터 모델을 활용할 수 있는지에 대한 예제도 제공한다.
본 섹션에서는 검증가능한 크리덴셜이 유용할 것으로 예상되는 생태계에서 핵심 행위자들의 역할과 그들 간의 관계에 대해 설명한다. 역할은 여러 가지 방법으로 구현할 수 있는 추상화된 개념이다. 역할의 분리는 표준화를 위한 인터페이스와 프로토콜을 시사한다. 이 사양에서는 다음과 같은 역할이 등장한다:
위의 그림 은 본 명세서에서 설명하는 개념의 기반을 형성하는 생태계의 예제이다. 보호된 환경이나 독점 시스템과 같은 다른 생태계도 존재하며, 다른 생태계에서도 검증가능한 크리덴셜은 이점을 제공한다.
검증가능한 크리덴셜 유스케이스 문서[[VC-USECASES]]는 독자가 유용하게 사용할 수 있는 여러 가지 주요 주제를 간략하게 설명한다:
유스케이스를 문서화하고 분석한 결과, 본 사양에 대해 다음과 같은 바람직한 생태계 특성이 확인되었다:
본 규격서는 발급자, 보유자, 검증자와 같은 생태계에서 역할의 준수와 관련하여 규범적인 진술을 하지 않으며, 그 이유는 생태계의 준수는 적용, 유즈케이스 및 시장의 수직적 특성이 높기 때문이다.
검증가능한 크리덴셜의 보호를 보장하기 위하여 부분집합인 전자서명인 전자 증명 메커니즘이 필요하다. 증명의 구문에 의존할 수 있는 증명을 소유하고 검증하는 것은 (예를 들어, 키 소유자를 증명하기 위해 JSON 웹 토큰의 JSON 웹 서명 사용) 검증가능한 크리덴셜을 처리하는 데 필수적이다. 출판 당시 워킹 그룹 구성원은 최소한 세 가지 증명 메커니즘을 사용하여 검증가능한 크리덴셜을 구현했다:
구현자는 다음 사항에 유의해야 한다. 모든 증명 메커니즘이 본 규격서의 게재 날짜를 기준으로 표준화된 것이 아니다. 본 그룹은 새로운 메커니즘뿐만 아니라 메커니즘 중 일부가 독립적으로 성숙되고 시간이 지나면 표준화될 것으로 기대한다. 다양하며 유효한 증명 메커니즘이 있기 때문에 본 규격서는 단일 전자서명 메커니즘을 표준화 하지 않는다. 본 규격서의 목표 중 하나는 다양한 현재 및 미래의 전자 증명 메커니즘으로 보호할 수 있는 데이터 모델을 제공하는 것이다. 본 사양에 대한 적합성은 특정 증명 메커니즘의 세부 사항에 의존하지 않는다. 검증가능한 크리덴셜이 사용하는 메커니즘을 명확하게 식별해야 한다.
본 문서에는 JSON 및 JSON-LD 컨텐츠가 포함된 예제도 포함되어 있다.
예제 중 일부에는 인라인 주석 (//
) 및
줄임표 (...
)를 사용하여 예제에 중요하지
않은 정보를 나타내는 유효하지 않은 JSON 문자가 포함되어 있다.
구현자는 정보를 유효한 JSON 또는 JSON-LD로 사용하려는 경우
이 컨텐츠를 삭제해야 한다.
다음 장에서는 본 사양의 기초를 구성하는 클레임, 크리덴셜 및 프레젠테이션과 같은 핵심 데이터 모델 개념에 대해 개략적으로 설명한다.
클레임은 주체에 대한 진술이다. 주체는 클레임을 할 수 있으며, 주체-속성-값 관계를 사용하여 표현한다.
위 에 설명된 클레임의 데이터 모델은 강력하며 다양한 구문을 표현하는 데 사용될 수 있다. 예를 들어, 특정 대학을 졸업한 사람은 아래 과 같이 표현될 수 있다.
독립된 클레임을 합쳐서 주체에 대한 정보를 나타내는 그래프를 표현할 수 있다. 아래 의 예시는 Pat이 Sam을 알고 있으며 Sam이 교수로 채용되었다는 클레임을 추가하여 이전 클레임을 확장한다.
이 시점에서, 클레임의 개념과 정보 그래프를 소개한다. 클레임을 신뢰하기 위하여 더 많은 정보가 그래프에 추가될 것으로 예상한다.
크리덴셜은 동일한 엔터티가 만든 하나 이상의 클레임 집합이다. 크리덴셜에는 발급자, 유효기한, 대표 이미지, 검증 목적으로 사용할 공개키, 해지 메커니즘 등과 같은 크리덴셜의 속성을 설명하는 식별자 및 메타데이터도 포함될 수 있다. 메타데이터는 발급자가 서명한 것일 수 있다. 검증가능한 크리덴셜은 누가 이를 발급했는지 암호학적으로 증명하는 위변조 방지 클레임 및 메타데이터 집합이다.
검증가능한 크리덴셜의 예로는 전자 직원 신분증, 전자 출생 증명서, 전자 교육 증명서가 있다.
크리덴셜 식별자는 종종 크리덴셜의 특정 인스턴스를 식별하는 데 사용된다. 이러한 식별자는 상관 관계에 사용될 수도 있다. 상관 관계를 최소화하려는 보유자는 크리덴셜 식별자를 밝히지 않는 선택적 공개 체계를 사용하는 것이 좋다.
위 는 검증가능한 크리덴셜의 기본 구성 요소를 보여 주지만, 클레임이 정보 그래프로 구성되고 검증가능한 크리덴셜로 구성되는 방식에 대한 세부 정보를 추상화 한다. 하단의 은 검증가능한 크리덴셜을 더 완벽하게 묘사한 것으로 일반적으로 두 개 이상의 정보 그래프로 구성된다. 첫 번째 그래프는 크리덴셜 메타데이터와 클레임을 포함하는 검증가능한 크리덴셜을 표시한다. 두 번째 그래프는 일반적으로 전자 서명인 디지털 프루프를 표현한다.
결혼 증명서와 같은 크리덴셜을 소유할 수 있으며, 포함되지 않아도 되는 다른 주체에 대한 여러 가지 클레임을 포함할 수 있다.
크리덴셜이 발급된 엔터티에 대한 어떠한 클레임도 포함하지 않는 크리덴셜을 가질 수 있다. 예를 들어, 특정 강아지에 대한 클레임을 포함하는 소유자에게 발급되는 크리덴셜이다.
프라이버시 향상은 본 규격서의 핵심 디자인 기능이다. 따라서, 본 기술을 사용하는 엔터티는 주어진 상황에 적절한 자신의 페르소나 부분만 표현할 수 있어야 한다. 페르소나의 부분 집합 표현을 검증가능한 프레젠테이션이라고 한다. 다른 페르소나의 예시는 개인의 전문 페르소나, 온라인 게임 페르소나, 가족 페르소나, 시크릿 페르소나가 있다.
검증가능한 프레젠테이션은 하나 이상의 검증가능한 크리덴셜의 데이터를 표현하며, 데이터의 소유권을 검증할 수 있는 방식으로 포장된다. 검증가능한 크리덴셜이 직접 제공되면 검증가능한 프레젠테이션이 된다. 암호학적 방식으로 검증할 수 있지만 검증가능한 크리덴셜를 포함하지 않는 검증가능한 크리덴셜에서 파생된 데이터 형식도 검증가능한 프레젠테이션일 수 있다.
프레젠테이션의 데이터는 종종 같은 주체에 관한 것 이지만 여러 발급자가 발급했을 수 있다. 이 정보의 집합은 일반적으로 개인, 조직, 엔터티의 관점을 표현한다.
위 은 검증가능한 프레젠테이션의 구성 요소를
보여주지만, 간략하게 검증가능한 크리덴셜이 정보 그래프로
구성되어 검증가능한 프레젠테이션으로 구성되는 방법에 대한
세부 사항을 요약한다. 하단의 은
검증가능한 프레젠테이션을 더 완벽하게 묘사한 것으로,
일반적으로 최소 4 개의 정보 그래프로 구성된다.
첫 번째 그래프는
프레젠테이션 메타데이터가 포함된
검증가능한 프레젠테이션을 표현한다.
그래프의 verifiablePresentation
속성은
크리덴셜 메타데이터
및 클레임을
포함하는 하나 이상의 검증가능한 크리덴셜 (각각 독립 그래프)을
표현한다.
세 번째 그래프는 일반적으로 전자서명인
크리덴셜 그래프 프루프
를 표현한다.
네 번째 그래프는 일반적으로 전자서명인
프레젠테이션 그래프 프루프
를 표현한다.
비즈니스 페르소나와 같은 프레젠테이션을 가질 수 있다. 비즈니스 페르소나는 종종 연관되어 있지만 필요하지 않은 다른 주체에 대한 여러 크리덴셜을 사용한다.
이전 섹션에서는 그래픽 개념을 사용하여 클레임, 검증가능한 크리덴셜 및 검증가능한 프레젠테이션 등의 개념을 소개했다. 이 섹션에서는 이 사양에서 지원하는 구체적인 구문 중 하나로 표현 된 데이터 모델의 단순하지만 완전한 수명주기 예제를 제공한다. 에서 크리덴셜 및 프레젠테이션의 수명주기는 종종 다음과 같은 공통 경로를 취한다:
이 수명주기를 설명하기 위해 대학에서 동문 할인을 사용하는 예를 사용한다. 아래 예에서 Pat은 대학교로부터 동문 검증가능한 크리덴셜을 받고, 검증가능한 크리덴셜을 디지털 지갑에 저장한다.
{ // set the context, which establishes the special terms we will be using // such as 'issuer' and 'alumniOf'. "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], // specify the identifier for the credential "id": "http://example.edu/credentials/1872", // the credential types, which declare what data to expect in the credential "type": ["VerifiableCredential", "AlumniCredential"], // the entity that issued the credential "issuer": "https://example.edu/issuers/565049", // when the credential was issued "issuanceDate": "2010-01-01T19:73:24Z", // claims about the subjects of the credential "credentialSubject": { // identifier for the only subject of the credential "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", // assertion about the only subject of the credential "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }, { "value": "Exemple d'Université", "lang": "fr" }] } }, // digital proof that makes the credential tamper-evident // see the NOTE at end of this section for more detail "proof": { // the cryptographic signature suite that was used to generate the signature "type": "RsaSignature2018", // the date the signature was created "created": "2017-06-18T21:19:10Z", // purpose of this proof "proofPurpose": "assertionMethod", // the identifier of the public key that can verify the signature "verificationMethod": "https://example.edu/issuers/keys/1", // the digital signature value "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj PAYuNzVBAh4vGHSrQyHUdBBPM" } }
Pat은 동문 할인을 받으려 한다. 티켓 판매 시스템인 검증자는 "Example University"의 모든 동창생이 스포츠 행사에 대한 시즌 티켓 할인을 받는다. Pat은 모바일 장치를 사용하여 시즌 티켓 구매 프로세스를 시작한다. 이 프로세스의 단계는 동문 검증가능한 크리덴셜을 요청하며 이 요청은 Pat의 디지털 지갑으로 라우팅된다. 전자 지갑은 Pat에게 이전에 발급 된 검증가능한 크리덴셜을 제공 할 것인지 묻는다. Pat은 동문 검증가능한 크리덴셜을 선택하여 검증가능한 프레젠테이션으로 구성한다. 검증가능한 프레젠테이션이 검증자에게 전송되고 검증된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": "VerifiablePresentation", // the verifiable credential issued in the previous example "verifiableCredential": [{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/1872", "type": ["VerifiableCredential", "AlumniCredential"], "issuer": "https://example.edu/issuers/565049", "issuanceDate": "2010-01-01T19:73:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }, { "value": "Exemple d'Université", "lang": "fr" }] } }, "proof": { "type": "RsaSignature2018", "created": "2017-06-18T21:19:10Z", "proofPurpose": "assertionMethod", "verificationMethod": "https://example.edu/issuers/keys/1", "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj PAYuNzVBAh4vGHSrQyHUdBBPM" } }], // digital signature by Pat on the presentation // protects against replay attacks "proof": { "type": "RsaSignature2018", "created": "2018-09-14T21:19:10Z", "proofPurpose": "authentication", "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1", // 'challenge' and 'domain' protect against replay attacks "challenge": "1f44d55f-f161-4938-a659-f8026467f126", "domain": "4jt78h47fh47", "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5 XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh 4vGHSrQyHUGlcTwLtjPAnKb78" } }
위에서 사용한 proof
메커니즘에 대해 더 자세히 알고 싶은 구현자는 섹션
에서 다음 사양을 자세히 알아볼 수 있다. 링크 된 데이터 증명 [[LD-PROOFS]], 링크 된
데이터 서명 [[LD-SIGNATURES]], 2018 RSA 서명 제품군 [[LDS-RSA2018]] 및 JSON 웹 서명 (JWS) 인코딩되지
않은 페이로드 옵션 [[RFC7797]]. 증명 메커니즘 목록은 검증 가능한 신임 정보 확장 레지스트리 [[VC-EXTENSION-REGISTRY]]에 있다.
이 섹션에서는 섹션 을 준비하기 위해 사양에 대한 몇 가지 기본 개념을 소개한다.
두 소프트웨어 시스템이 데이터를 교환해야하는 경우 두 시스템이 이해하는 용어를 사용해야 한다. 비유하자면 두 사람이 어떻게 의사소통을 하는지 고려해 보라. 두 사람 모두 같은 언어를 사용해야하며 그들이 사용하는 단어는 서로 같은 것을 의미해야 한다. 이것을 대화의 맥락이라고 할 수 있다.
검증가능한 크리덴셜 및 검증가능한 프레젠테이션에는 URIs로 식별되는 많은 속성과 값이 있다.
그러나 이러한 URIs는 길고 사람에게 친숙하지 않을 수 있다. 이러한 경우, 짧은 형태의 인간 친화적
별칭이 더 도움이 될 수 있다. 이 사양에서는 @context
속성을 사용하여 이러한 짧은 별칭을 특정
검증가능한 크리덴셜 및 검증가능한 프레젠테이션에 필요한 URI에 매핑한다.
JSON-LD에서 @context
속성을 사용하여 데이터 유형 정보, 언어 정보, 변환 규칙
등과 같은 다른 세부 정보를 전달할 수도 있다.
이것은 이 사양의 요구 사항을 넘어서지만 향후에나 관련 작업에서는 유용 할 수 있다.
자세한 정보는 [[JSON-LD]] 스펙의
섹션 3.1 : 컨텍스트를 참조.
검증가능한 크리덴셜 및 검증가능한 프레젠테이션에는 반드시 @context
속성이 포함되어야 한다.
@context
의 속성 값은 첫 번째 항목이
https://www.w3.org/2018/credentials/v1
값을 갖는 URI 인 순서
집합이어야 한다. 참고로, 기본 컨텍스트의 사본은 부록 에 제공된다. 배열의 후속
항목은 반드시 컨텍스트 정보를 표현해야하며 URIs 또는 객체의 조합으로 구성되어야 한다. @context
의
각 URI는 역 참조되는 경우 @context
에 대한 기계 판독 가능 정보를 포함하는 문서를 생성하는 URI 여야한다.
이 사양에서는 @context
속성이 있어야 하지만
@context
속성의 값을 JSON-LD를 사용하여 처리 할 필요는 없다.
이는 검증가능한 크리덴셜이 JWT로 인코딩 될 때 사용되는 것처럼 일반 JSON 라이브러리를 사용한 처리를
지원하기 위한 것이다. 모든 라이브러리 또는 프로세서는 @context
속성의 값 순서가 특정 응용 프로그램에 예상되는
순서여야한다. JSON-LD를 지원하는 라이브러리 또는 프로세서는 예상대로 전체 JSON-LD 처리를 사용하여 @context
속성을 처리 할 수 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/58473", "type": ["VerifiableCredential", "AlumniCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }, { "value": "Exemple d'Université", "lang": "fr" }] } }, "proof": { ... } }
위의 예는 기본 컨텍스트 URI (https://www.w3.org/2018/credentials/v1
)를 사용하여
대화가 검증가능한 크리덴셜에
관한 것임을 설정한다. 두 번째 URI (https://www.w3.org/2018/credentials/examples/v1
)는
대화가 예제에 관한 것임을 설정한다.
이 문서는 예제를 보여주기 위해 예제 컨텍스트 URI
(https://www.w3.org/2018/credentials/examples/v1
)를 사용한다.
실제 구현에서는 파일럿 또는 프로덕션
시스템을 포함하여 어떤 다른 목적으로도 이 URI를 사용하면 안된다.
https://www.w3.org/2018/credentials/v1
에 있는 데이터는 절대 업데이트되지 않으며 다운로드 및
캐시되어야하는 정적 문서이다. 검증 가능한 자격 증명 데이터 모델에 대한 사람이 읽을 수 있는 관련 어휘
문서는 https://www.w3.org/2018/credentials에서 제공된다. 이 개념은
섹션 에서 더욱 심도있게 다룬다.
사람, 제품, 또는 조직과 같은 특정한 것에 대해 표현할때,
다른 사람들이 동일한 것을 표현할 수 있도록 식별자를 사용하는 것이 유용하다.
이 규격에서는 이러한 식별자들에 대한 선택적 id
속성을 정의한다.
id
속성은 사람, 제품 또는 조직과 같은 객체를 명확하게 참조하기 위한 것이다.
id
속성을 사용하면
검증가능한 크리덴셜을 통해 특정한 사물을 표현할 수 있게 된다.
만약 id
속성이 존재한다면:
id
속성을 표현할 때 반드시 다른 사용자들이 특정 사물을 표현할 때 사용할 것으로 예상되는 식별자로 표현해야 한다.
id
속성은 반드시 하나의 값만 가져야 한다.
id
속성의 값은 반드시 URI 이어야 한다
개발자들은 익명성이 요구되는 시나리오에서 식별자가 유해할 수 있다는 것을 기억해야 한다.
그러한 시나리오를 고려할 때 부분을 주의깊게 읽을 것을 권장한다.
프라이버시 문제를 만들어 내는 다른 유형의 연관메커니즘문서도
에서 다룬다.
프라이버시가 중요한 고려사항인 경우 id
속성은 생략 될 수 있다.
id
속성 값은 반드시 단일 URI여야 한다.
역참조되는 경우 URI는 id
에 대한
기계판독가능정보를 포함한 문서를 생성하는 것이 권장된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
위의 예는 두 가지 유형의 식별자를 사용한다. 첫 번째는 검증가능한 크리덴셜을 위한 것이며 HTTP 기반 URL을 사용한다. 두 번째는 검증가능한 크리덴셜의 주체(클레임이 관련된 것)를 위한 것이며 DID라고도하는 탈중앙 식별자를 사용한다.
본 간행물에 의하면, DIDs는 새로운 유형의 식별자이지만 검증가능한 크리덴셜의 유용성에 필수는 아니다. 구체적으로 검증가능한 크리덴셜은 DIDs에 의존하지 않으며, DIDs는 검증가능한 크리덴셜에 의존하지 않는다. 그렇지만 많은 검증가능한 크리덴셜이 DIDs를 사용할 것으로 예상되고, 이 규격을 구현하는 소프트웨어 라이브러리는 DIDs를 구현할 필요가 있을 것이다. DID 기반 URL은 주체, 발급자, 보유자, 크리덴셜 상태 목록, 암호화 키 그리고 검증가능한 크리덴셜과 관련된 기계 판독 가능 정보를 관련된 식별자로 표현하는 데 사용된다.
이 문서에 지정된 객체들을 처리하는 소프트웨어 시스템은 제공된
검증가능한 크리덴셜 또는 검증가능한 프레젠테이션이 적절한지 여부를 결정하기 위해
type
정보를 사용한다.
이 규격은 타입 정보 표현에 대한 type
속성을 정의한다.
검증가능한 크리덴셜과 검증가능한 프레젠테이션에는
반드시 type
속성이 있어야 한다.
따라서 type
속성이 없는 크리덴셜, 또는 프레젠테이션은
검증을 할수 없으므로 검증가능한 크리덴셜이나 검증가능한 프레젠테이션이 아니다.
type
속성의 값은 반드시 맵핑된(@context
속성의 해석을 통해),
하나 또는 이상의 URIs다.
만약 복수의 URI들이 제공되었다면, URIs는 순서가 없는 집합으로 해석해야 한다.
개발편의를 위해 문법적 편의성을 반드시 사용해야 한다.
이러한 편의성에는 JSON-LD 용어가 포함될 수 있다.
type
의 각 URI가 역참조되는 경우
type
에 대한 기계판독가능정보가 포함된 문서를 생성하는 것이 권장된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
규격준수와 관련하여, 다음 표에는 객체들이 반드시 가져야 하는 타입이 명시되어 있다
Object | Type |
---|---|
Verifiable credential object (a subclass of a credential object) |
VerifiableCredential and, optionally, a more specific
verifiable credential type. For example,"type": ["VerifiableCredential", "UniversityDegreeCredential"]
|
Credential object |
VerifiableCredential and, optionally, a more specific
verifiable credential type. For example,"type": ["VerifiableCredential", "UniversityDegreeCredential"]
|
Verifiable presentation object (a subclass of a presentation object) |
VerifiablePresentation and, optionally, a more specific
verifiable presentation type. For example,"type": ["VerifiablePresentation", "CredentialManagerPresentation"]
|
Presentation object |
VerifiablePresentation and, optionally, a more specific
verifiable presentation type. For example,"type": ["VerifiablePresentation", "CredentialManagerPresentation"]
|
Proof object |
A valid proof type. For example,"type": "RsaSignature2018"
|
credentialStatus object |
A valid credential status type. For example,"type": "CredentialStatusList2017"
|
termsOfUse object |
A valid terms of use type. For example,"type": "OdrlPolicy2017" )
|
evidence object |
A valid evidence type. For example,"type": "DocumentVerification2018"
|
검증가능한 크리덴셜 데이터 모델의 타입시스템은 [[JSON-LD]]와 동일하며
섹션 5.4:
Specifying the Type 그리고 섹션 8: JSON-LD
Grammar에 자세히 설명되어 있다. JSON-LD 컨텍스트를 사용할 때 (
참조),
이 규격의 @type
키워드를 다른 이름인 type
으로 바꾸면
JSON-LD 문서의 이해가 쉬워질 것이다.
애플리케이션 개발자와 문서 작성자는 JSON-LD 타입 시스템의 세부사항을 이해할 필요는 없지만,
상호운용 가능한 확장성을 지원하려는 이 규격의 구현자들은 그 내용을 이해해야 한다.
모든 크리덴셜, 프레젠테이션, 그리고 캡슐화된 객채들은 추가정보를 처리할 수 있도록,
더욱 제한된 타입들(예를 들어 UniversityDegreeCredential
과 같은)을
반드시 명시하거나 연관시켜야 한다.
이 규격에 정의된 캡슐화된 객체
(예를 들어 credentialSubject
객체와 관련되거나 깊이 중첩된 객체들)들을 처리할 때,
소프트웨어 시스템은 객체를 캡슐화할때 사용된 상위 계층의타입 정보를 사용해야 한다.
구체적으로 크리덴셜과 같은 캡슐화된 객체들은 연관된 객체 타입을 전달하여,
검증자가 캡슐화 객체의 타입에 기초하여 관련 객체의 내용을 신속하게 파악할 수 있어야한다.
예를 들어, UniversityDegreeCredential
과 같은 type
의 크리덴셜 객체는
다음 항목을 위한 식별자가 credentialSubject
속성에 포함되어 있다는 것을
검증자에게 전송한다:
id
속성이 가지고 있는 주체
type
속성이 가지고 있는 학위 형식
name
속성이 가지고 있는 학위 타이틀
이를 통해 구현자는 검증을 목적으로 type
속성과 관련된 값에 의존할 수 있다.
타입 및 관련 속성은 최소한 사람이 읽을 수 있는 규격으로 문서화하는 것과 함께,
가급적 기계판독가능한 설명을 추가해야 한다.
이 규격에 기술된 데이터 모델에 사용되는 타입 시스템은 타입과 데이터를 연결하는 여러가지 방법을 허용한다. 구현자와 작성자는 검증가능한 크리덴셜 구현 가이드[[?VC-IMP-GUIDE]]의 타이핑에 관한 섹션을 읽어야 한다.
검증가능한 크리덴셜 에는 하나 이상의 주체들에 대한 클레임이 포함된다.
이 규격은 하나 이상의 주체들에 대한 클레임을 표현하기 위한 항목인
credentialSubject
속성을 정의한다.
검증가능한 크리덴셜에는 무조건 credentialSubject
속성이 있어야 한다.
credentialSubject
property is defined as
credentialSubject
속성의 값은 검증가능한 크리덴셜의 주체와
각각 관련된 하나 이상의 특성을 포함하는
객체 세트로 정의된다. 에 설명 된대로 각 객체에는 id
가 포함될 수도 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
검증가능한 크리덴셜로 여러 주체와 관련된 정보를 표현할 수 있다.
아래의 예는 배우자 관계인 두 주체를 지정한다.
여러 주체를 credentialSubject
특성과 연관시키기 위해 배열 표기법을 사용한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "RelationshipCredential"], "credentialSubject": [{ "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "name": "Jayden Doe", "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1" }, { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": "Morgan Doe", "spouse": "did:example:ebfeb1f712ebc6f1c276e12ec21" }], "proof": { ... } }
이 규격은 검증가능한 크리덴셜의 발급자를 표현하기 위한 속성을 정의한다.
검증가능한 크리덴셜은 무조건 issuer
속성이 있어야 한다.
issuer
속성 값은 무조건 URI이거나 id
속성을 포함하는 객체여야한다.
issuer
또는 해당 id
의 URI는 역 참조 된 경우
크리덴셜에 표시된 정보를 검증하는 데 사용할 수 있는
issuer에 대한 기계판독 가능한 정보를 포함하는 문서를 생성하는 URI 여야 한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
객체를 발급자 특성과 연관시켜 발급자에 대한 추가 정보를 표현 할 수도 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
issuer
속성값은 JWK (예를 들어, "https://example.com/keys/foo.jwk"
)
또는 a DID (예를 들어, "did:example:abfe13f712120431c276e12ecab"
)이 될 수 있다.
이 규격은 크리덴셜이 유효한 날짜 및 시간을 표현하기 위한 issuanceDate
속성을 정의한다.
issuanceDate
속성을 가져야 한다.
issuanceDate
속성의 값은
크리덴셜이 유효한 날짜와 시간을 나타내는 [[!RFC3339]] 결합 날짜 및 시간
문자열의 문자열 값이어야하며 이는 미래의 날짜와 시간 일 수 있다. 이 값은 credentialSubject
속성과 연관된 정보가 유효 해지는 가장 빠른 시점을 나타낸다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
이 스펙의 다음 버전은 validFrom
속성을 추가하고
새로운 issued
된 속성을 위해 issuanceDate
속성을
더 이상 사용하지 않을 것으로 예상된다. 두 속성의 값 범위는 [[?RFC3339]] 결합 날짜 및 시간 문자열로 유지
될 것으로 예상한다. 구현자는 validFrom
및 issued
속성을 예약하고
다른 목적으로 사용하지 않는 것이 좋다.
크리덴셜 또는 프레젠테이션이 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션이 되도록 최소한 하나의 증명 메커니즘과 그 증거를 평가하는데 필요한 세부 사항을 표현해야 한다. 즉, 검증 할 수 있어야 한다.
이 규격은 두가지 종류의 메커니즘을 식별한다: 외부 증명과 내장된 증명. 외부 프루프은 섹션에 자세히 설명되어 있는 JSON 웹 토큰과 같은 데이터 모델의 표현을 감싸는 것이다.내장 된 프루프는 섹션에 자세히 설명된 linked data signature과 같은 데이터에 증명이 포함되는 메커니즘이다.
프루프을 포함 할 때는 proof
속성을 무조건 사용해야 한다.
type
속성을 사용하여 포함해야한다.
수학적 증명에 사용되는 방법은 표현 언어와 사용 된 기술에 따라 다르므로 proof
속성의 값으로 예상되는
이름-값 쌍 세트는 그에 따라 달라진다. 예를 들어, 프루프 메커니즘에 디지털 서명이 사용되는 경우 proof
속성에는 서명, 서명 엔터티에 대한 참조 및 서명 날짜 표시가 포함 된 이름-값 쌍이 있어야한다. 아래 예는 RSA
디지털 서명을 사용한다.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.gov/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2018-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.com/jdoe/keys/1",
"jws": "eyJhbGciOiJQUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19
..DJBMvvFAIC00nSGB6Tn0XKbbF9XrsaJZREWvR2aONYTQQxnyXirtXnlewJMB
Bn2h9hfcGZrvnC1b6PgWmukzFJ1IiH1dWgnDIS81BH-IxXnPkbuYDeySorc4
QU9MJxdVkY5EL4HYbcIfwKj6X4LBQ2_ZHZIu1jdqLcRZqHcsDF5KKylKc1TH
n5VRWy5WhYg_gBnyWny8E6Qkrze53MR7OuAmmNJ1m1nN8SxDrG6a08L78J0-
Fbas5OjAQz3c17GY8mVuDPOBIOVjMEghBlgl3nOi1ysxbRGhHLEK4s0KKbeR
ogZdgt1DkQxDFxxn41QWDw_mmMCjs9qxg0zcZzqEJw"
}
}
에서 논의 된 바와 같이, 여러 가지 가능한 증명 메커니즘이 있으며,
이 사양은 검증가능한 크리덴셜과 함께 사용하기위한 단일 증명 메커니즘을 표준화하거나 권장하지 않는다.
proof
메커니즘에 대한 자세한 내용은 다음 사양을 참조하시오. Linked Data Proofs [[LD-PROOFS]],
Linked Data Signatures [[LD-SIGNATURES]], 2018 RSA Signature Suite [[LDS-RSA2018]] 및 JSON Web Signature(JWS)
Unencoded Payload Option [[RFC7797]]. 프루프메커니즘 목록은 Verifiable Credentials Extension Registry
[[VC-EXTENSION-REGISTRY]]에서 찾을 수 있다.
이 사양에서는 크리덴셜 만료 정보 표현을위한 expirationDate
속성을 정의한다.
expirationDate
속성의 값은 무조건 크리덴셜이 유효하지 않은 날짜와 시간을
나타내는 [[!RFC3339]] 결합 날짜 및 시간 문자열의 문자열 값이어야 한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "expirationDate": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
이 규격의 다음 버전에서는 사용되지 않는 방식으로 validUntil
속성을 추가하지만 expirationDate
속성과의 호환성을 유지해야한다.
구현자는 validUntil
속성이 이미 용도결정이 되어 있고
다른 용도로 사용하지 않는 것이 좋다.
이 규격은 검증가능한 크리덴셜의 현재 상태(예를들어 일시중지 또는 취소)에 대한 정보를 검색하기 위해
다음 credentialStatus
속성을 정의한다.
credentialStatus
속성의 값은 무조건 다음 사항들을 포함해야 한다.
크리덴셜 상태 정보의 정확한 내용은
특정 credentialStatus
유형 정의에 의해 결정되며
구현이 간단한지 또는 개인정보 보안강화 여부와 같은 요소에 따라 다르다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "credentialStatus": { "id": "https://example.edu/status/24", "type": "CredentialStatusList2017" }, "proof": { ... } }
상태 체계에 대한 데이터 모델, 형식 및 프로토콜 정의는 이 사양에서 다루지 않는다. a>검증가능한 크리덴셜 상태 확인의 구현을 원하는 개발자가 사용할 수 있는 상태 스키마를 포함하는 Verifiable Credentials Extension Registry [[?VC-EXTENSION-REGISTRY]]가 존재한다.
프레젠테이션들은 크리덴셜들을 결합하고 제시하는데 사용될 수 있다. 이들은 데이터의 소유권을 검증가능한 방식으로 결합될 수 있다. 프레젠테이션의 데이터는 대부분 동일한 주체에 관한 것이지만, 데이터의 주체나 발급자 수에는 제한이 없다. 여러 검증가능한 크리덴셜에서 정보를 합치는것은 일반적인 검증가능한 프레젠테이션의 사용법이다.
검증가능한 프레젠테이션은 보통 다음과 같은 속성들로 구성되어있다.
id
속성은 선택적이고 프레젠테이션의 고유한 식별자로 사용될 수 있다.
이 속성에 관한 자세한 사항은 에서 볼 수 있다.
type
속성은 필수적이고 VerifiablePresentation
같이 프레젠테이션의 유형을 표현한다.
이 속성에 관한 자세한 사항은 에서 볼 수 있다.
verifiableCredential
속성이 존재한다면,
최소 한개 이상의 검증가능한 프레젠테이션이나
암호학적으로 검증가능한 형태의 검증가능한 크리덴셜의 데이터로 무조건 구성되어야 한다.
holder
속성이 존재한다면, 이 프레젠테이션을 생성하는 엔터티의 URI여야 한다.
proof
속성이 존재한다면, proof
의 값이 프레젠테이션이 검증가능한것임을 보장한다.
이 속성에 관한 자세한 사항은 에서 볼 수 있다.
아래 예제는 검증가능한 크리덴셜들을 포함하고 있는 검증가능한 프레젠테이션을 보여준다.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
"type": ["VerifiablePresentation", "CredentialManagerPresentation"],
"verifiableCredential": [{ ... }],
"proof": [{ ... }]
}
위에 표시된 verifiableCredential
속성의 내용은 이 사양에 설명 된대로 검증가능한 크리덴셜이다.
proof
속성의 내용은 Linked Data Proofs [[?LD-PROOFS]] 사양에 설명 된 증명방법이다.
JWT 증명 방법을 이용한 검증가능한 프레젠테이션 예시는 에서 볼 수있다.
일부 영지식 증명 체계는 보유자가 검증가능한 크리덴셜 자체를 밝히지 않고 검증가능한 크리덴셜으로부터 클레임들을 보유하고 있음을 간접적으로 입증 할 수있도록 해준다. 이러한 방식에서, 검증가능한 크리덴셜의 클레임들은 제시된 값을 도출한는데 사용될 수 있으며, 이는 검증자가 발급자를 신뢰하는 경우, 암호학적으로 그 값을 보장할 수 있다.
예를 들어, 생년월일
클레임이 포함된 검증가능한 크리덴셜을 사용하여
15세 이상
의 제시된 값을 암호학적으로 검증가능한방식으로 도출할 수 있다.
즉, 검증자는 발급자를 신뢰하는 경우 파생된 값을 계속 신회할 수 있다.
검증가능한 크리덴셜에서 데이터를 직접 내포하지 않고 추출해서 사용하는 ZKP 스타일의 검증가능한 프레젠테이션 예시를 보고싶다면 를 참조.
영지식 증명을 사용하는 선택적 공개 체계에서는 이 모델에 포현된 클레임들을 사용하여 해당 클레임에 대한 추가적인 주장들을 만들어낼 수 있다. 예를 들어, 어떤 주체의 생년월일을 나타내는 클레임은 해당 주체의 나이가 주어진 범위 안에 있음을 증명하는데 사용될 수 있고, 따라서 대상이 나이 관련 할인을 받을 수 있음을 실제로 주체의 생년월일을 밝히지 않고 증명할 수 있다. 보유자는 원하는 검증가능한 프레젠테이션에 적용할 수 있는 방식으로 클레임을 사용할 수 있는 유연성을 가지게 된다.
에서 소개된 개념들을 바탕으로 이 섹션에서는 검증가능한 크리덴셜의 더 복잡한 주제들을 다룬다.
는 검증가능한 크리덴셜 생태계의 개요를 제공했다. 이 섹션에서는 생태계가 어떻게 작동할 것인지에 대한 자세한 정보를 제공한다.
검증가능한 크리덴셜 생태계의 역할과 정보의 흐름은 다음과 같다:
위 내용들의 순서는 고정되어 있지 않으며 일부 동작들은 두 번 이상 수행될 수 있다. 이러한 재동작은 즉시 또는 나중에 발생할 수 있다.
가장 일반적인 동작 순서는 다음과 같다:
이 사양은 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션을 전송하기 위한 프로토콜을 정의하지 않지만, 다른 사양에서 엔터티간 전송 방법을 지정한다고 가정하면 이 검증가능한 크리덴셜 데이터 모델을 바로 적용할 수 있다.
이 사양은 인증 프레임워크나 검증자가 보유자, 검증가능한 크리덴셜의 발급자, 검증가능한 크리덴셜의 내용, 그리고 자체 정책을 고려하여 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션을 검증한 후 내리는 결정에 대해 정의하지 않는다.
특히 와 는 검증자가 다음 사항들을 결정할 수 있는 방법을 지정한다:
검증가능한 크리덴셜의 신뢰 모델은 다음과 같다:
이 신뢰 모델은 다음 사항을 보장함으로써 다른 신뢰 모델과 차별점을 갖는다:
신원 제공자와 신뢰 당사자간의 신뢰 결합을 제거함으로써 더 유연하고 동적인 신뢰 모델이 생성되고, 그로 인해 시장 경쟁이 치열해지고 고객 선택의 폭이 증가한다.
워킹 그룹에서 연구한 이 신뢰 모델이 어떻게 다양한 위협 모델과 상호작용하는가에 대한 더 많은 정보는 검증가능한 크리덴셜 유즈케이스 문서 참조. [[VC-USECASES]]
이 규격에서 설명하고 있는 데이터 모델은 전통적인 인증 기관의 신뢰 모델에서 제공하는 것과 같은 전이 가능한(transitive) 신뢰 모델을 내포하지는 않는다. 검증가능한 크리덴셜 데이터 모델에서 검증자는 발급자를 직접 믿을 수도 있고 믿지 않을 수도 있다. 검증가능한 크리덴셜 데이터 모델을 이용하는 전이 가능한 신뢰 모델을 구축하는 것이 가능함에도 불구하고, 구현자는 인증 기관 시스템에서 채택했던 것과 마찬가지로 광범위 위임 신뢰(broadly delegating trust)에서 소개된 보안 취약점에 대해 공부해야 한다.
검증가능한 크리덴셜 데이터 모델의 목표 중 하나는 비허가형 방식의 혁신을 활성화하는데 있다. 이러한 목표를 달성하기 위하여, 이 데이터 모델은 수많은 다른 방법으로 확장가능할 필요가 있다. 이 데이터 모델에 요구되는 것은:
데이터 모델링에 대한 이러한 접근 방식은 종종 “열린 세계 가정 (open world assumption)"이라고하며, 이는 누구나 다른 누군가에 대해 말할 수 있다는 것을 의미한다. 이러한 접근 방식이 간단하고 예측 가능한 소프트웨어 시스템을 구축하는 것과 충돌하는 것처럼 보일 수 있음에도 불구하고, 프로그램의 정확성과 확장성 간에 균형을 맞추는 것은 폐쇄형 소프트웨어 시스템보다 열린 세계 가정에서 항상 더 도전적인 과제이다.
이 섹션의 나머지 부분에서는 여러 예제들을 통해 확장성과 프로그램 정확성을 모두 달성하는 방법에 대해 설명한다.
다음과 같은 검증가능한 크리덴셜로 시작한다고 간주해보자.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.com/credentials/4643",
"type": ["VerifiableCredential"],
"issuer": "https://example.com/issuers/14",
"issuanceDate": "2018-02-24T05:28:04Z",
"credentialSubject": {
"id": "did:example:abcdef1234567",
"name": "Jane Doe"
},
"proof": { ... }
}
이 검증가능한 크리덴셜이 나타내는 것은
이 개체가 name
속성의 값이 Jane Doe
라는 값을 가진
did:example:abcdef1234567
과 관련있다는 것이다.
이제 어떤 개발자가 이 검증가능한 크리덴셜을 확장해서 두 개의 추가적인 정보를 저장하고 싶다고 해보자: 내부 기업 참조 번호와 Jane이 가장 좋아하는 음식.
첫 번째로 해야할 일은 아래와 같이 두 개의 새로운 용어가 포함된 JSON-LD 컨텍스트를 생성하는 것이다.
{ "@context": { "referenceNumber": "https://example.com/vocab#referenceNumber", "favoriteFood": "https://example.com/vocab#favoriteFood" } }
이 JSON-LD 컨텍스트가 생성된 이후에,
그 개발자는 생성한 것을 어딘가에 발행해서 이 검증가능한 크리덴셜을 처리할 검증자가 접근할 수 있도록 만든다.
위의 JSON-LD 컨텍스트가 https://example.com/contexts/mycontext.jsonld
에 발행되었다고 가정하면,
우리는 이 검증가능한 크리덴셜에 컨텍스트를 포함하고
새로운 속성 및 크리덴셜 타입을 추가함으로써 이 예제를 확장할 수 있게 된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://example.com/contexts/mycontext.jsonld" ], "id": "http://example.com/credentials/4643", "type": ["VerifiableCredential", "CustomExt12"], "issuer": "https://example.com/issuers/14", "issuanceDate": "2018-02-24T05:28:04Z", "referenceNumber": 83294847, "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe", "favoriteFood": "Papaya" }, "proof": { ... } }
이 예제는 검증가능한 크리덴셜 데이터 모델이 비허가형이고 탈중화된 방식으로 확장되는 것을 보여준다. 이 메커니즘은 또한, 이런 방식으로 생성된 검증가능한 크리덴셜이 네임스페이스 충돌 및 의미 중의성을 방지하기 위한 메커니즘을 제공한다는 것을 확실히 보여준다.
이러한 동적 확장성 모델은 구현 부담을 분명히 증가시킨다. 이런 시스템용으로 작성된 소프트웨어는, 응용 프로그램의 위험 프로파일을 기반으로 확장된 검증가능 크리덴셜을 받아들일지 여부를 결정해야한다. 어떤 응용 프로그램은 특정 확장을 허용하면서도 높은 보안성이 요구되는 환경에서는 모든 확장을 허용하지 않을 수 있다. 이러한 결정은 응용 프로그램 개발자에게 달려 있으며 이 규격에서 구체적으로 다루는 영역이 아니다.
개발자는 확장된 JSON-LD 컨텍스트의 가용성을 높이기 위해 노력해야 한다. 컨텍스트를 가져올 수 없는 구현물은 오류를 발생 시킬 것이다. 컨텍스트를 위한 내용 지정 URL들의 사용, 컨텍스트 문서와 구현물의 번들링, 또는 컨텍스트의 적극적인 캐싱 활성화를 포함하여 확장 JSON-LD 컨텍스트를 보장하는 전략은 언제나 유효하다.
Implementers are advised to pay close attention to the extension points in this specification, such as in Sections , , ,, , and . While this specification does not define concrete implementations for those extension 구현자는 , , , , , 에서 설명하고 있는 확장 기능에 대단히 주의를 기울여야 한다. 비록 이 규격이 확장 기능과 관련한 구체적인 구현에 대해 정의하고 있진 않지만, 검증가능한 크리덴셜 확장 레지스트리[VC-EXTENSION-REGISTRY]는 개발자가 활용할 수 있도록 비공식적인 확장 기능 목록을 제공한다.
본 규격은 JSON-LD 프로세서를 사용하기 위한 JSON 구현의 필요 없이 전통적인 JSON 과 JSON-LD의 문법이 의미적으로 호환되도록 보장한다. 이를 달성하기 위해서, 규격은 다음의 추가적인 요구사항을 양쪽 모두의 문법에 부과한다.
@context
키를 처리해야 한다.
크리덴셜 타입이 처리되기 위해서는 기대되는 값들이 기대되는 순서로 존재하는 것이 보장되어야 하기 때문이다.
그 순서가 중요하다. 크레덴션에 사용된 키들은 @context
와 관련된 값들을 이용하여 정의되고,
“먼저 정의된 것이 이기는” 메커니즘에 의하여 정의되기 때문에 순서를 바꾸는 것은 다른 정의가 “이기는” 결과를 초래한다.
@protected
기능을 살펴보아야 한다.
@context
속성의 기대되는 값 순서를 기술하는,
사람이 읽을 수 있는 문서는 상호운용성을 추구하는 구현자에 의하여 게시되어야 한다.
기계가 읽을 수 있는 설명(즉, 일반 JSON-LD 컨텍스트 문서)는
상호 운용성을 추구하는 JSON-LD 구현자가 @context
속성에 지정된 URL에 게시해야 한다.
위의 요구사항은 @context
메커니즘에 의해 정의된 term에 대해
JSON과 JSON-LD 간의 의미론적 상호운용성을 보장한다.
JSON-LD 프로세서가 특정 메커니즘을 사용하여 모든 term이 올바르게 지정되었는지 확인할 수 있는 반면,
JSON 기반 프로세서는 term들이 올바르게 지정되었는지 확인하는 테스트 없이 암시적으로 동일한 term들의 집합을 수용한다.
즉, 데이터 교환이 발생하는 컨텍스트는 동일한 메커니즘을 사용하여 JSON과 JSON-LD 모두에서 명시적으로 선언된다.
이것이 JSON 기반 프로세서에서는 JSON-LD 처리 라이브러리를 사용할 필요없이 간단한 방식으로 달성된다.
데이터 스키마는 주어진 데이터 컬렉션에 특정 구조를 적용할 때 유용하다. 이 규격에서는 고려하는 데이터 스키마 유형은 최소 두 가지가 있다.
데이터 스키마는 @context
와는 다른 용도로 사용된다는 것을 이해해야 한다.
@context
속성은 데이터 구조나 데이터 구문을 강요하지도 않고
임의의 인코딩 정의를 대체 표현 형식으로 변환하게 할 수도 없다.
이 규격은 데이터 스키마 표현을 위해 다음 속성을 정의한다.
credentialSchema
속성의 값은
제공된 데이터가 제공된 스키마와 일치하는지 판별하기에 충분한 정보를 검증자에게 제공하는
하나 이상의 데이터 스키마여야 한다.
각각의 credentialSchema
은 그것의 타입을 지정해야 한다(예: JsonSchemaValidator2018
).
credentialSchema
의 id
속성은 스키마 파일을 식별할 수 있는 URI여야 한다.
각 데이터 스키마의 정확한 내용은 구체적인 타입 정의에 의해 결정된다.
credentialSchema
속성은 타입 정의에 주석을 달거나 특정 버전의 용어에 고정할 수 있게 한다.
검증가능한 크리덴셜의 작성자는 일부 콘텐츠 무결성 보호 메커니즘에 고정된 credentialSchema
을 사용하여
정적 버전의 용어를 포함할 수 있다.
credentialSchema
속성을 사용하면 크리덴셜에 대해 구문 검사를 수행하고
JSON 스키마 [[JSON-SCHEMA-2018]] 유효성 검사와 같은 검증 메커니즘을 사용할 수 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "credentialSchema": { "id": "https://example.org/examples/degree.json", "type": "JsonSchemaValidator2018" }, "proof": { ... } }
위의 예에서 발급자는 credentialSchema
를 지정하고 있는데,
해당 credentialSchema
는 검증가능한 크리덴셜이 제대로 구성되어 있는지 확인할 수 있도록
검증자가 사용할 수 있는 [[?JSON-SCHEMA-2018]] 파일을 가리킨다.
JSON 스키마 [[JSON-SCHEMA-2018]] 또는 기타 검증 메커니즘에 대한 링크 정보는 검증가능한 크리덴셜 구현 가이드라인 [[VC-IMP-GUIDE]] 문서를 참조.
Data schemas can also be used to specify mappings to other binary formats, such
as those used to perform zero-knowledge proofs. For more information on using
the credentialSchema
property with zero-knowledge proofs,
see Section .
데이터 스키마를 사용하여 영지식 증명을 수행하는 데 사용되는 것과 같은 다른 이진 형식에 대한 맵핑을 지정할 수도 있다.
영지식 증명으로 credentialSchema
속성을 사용하는 것에 대한 자세한 정보는
섹션 을 참조.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "credentialSchema": { "id": "https://example.org/examples/degree.zkp", "type": "ZkpExampleSchema2018" }, "proof": { ... } }
위의 예에서 발급자는 영지식 증명용으로 패키징된 이진 데이터 형식을 가리키는 credentialSchema
를 지정한다.
이 이진 데이터 형식은 입력 데이터를 검증자가 이용할 수 있는 형식으로 변환할 수 있는데,
검증자는 변환된 데이터 형식을 이용하여 검증가능한 크리덴셜과 함께 제공된 증명의 유효성을 확인할 수 있다.
만료된 검증가능한 크리덴셜을 수동 또는 자동으로 리프레시할 수 있게 하는 것은 시스템에 유용하다.
만료된 검증가능한 크리덴셜에 대한 더 자세한 정보는
섹션 에서 기술한다.
이 규격은 발급자가 리프레시 서비스에 대한 링크를 포함할 수 있도록 refreshService
속성을 정의한다.
만약 검증가능한 크리덴셜이 검증자나 보유자(또는 둘 다)를 위한 용도라면, 발급자는 검증가능한 크리덴셜 내부의 요소로서 리프레시 서비스를 포함시킬 수 있고, 보유자만을 위한 경우라면 검증가능한 프레젠테이션 내부의 요소로서 포함시킬 수 있다. 후자의 경우, 검증자와 공유할 검증가능한 프레젠테이션을 생성하기 전에 보유자는 검증가능한 크리덴셜을 리프레시 할 수 있다. 전자의 경우 검증가능한 크리덴셜 안에 리프레시 서비스를 포함시키면, 보유자나 검증자가 크리덴셜의 향후 업데이트를 수행할 수 있다.
리프레시 서비스는 크리덴셜이 만료되었거나
발급자가 크리덴셜 상태 정보를 게시하지 않은 경우에만 사용되어야 한다.
공개된 정보를 포함하지 않거나 리프레시 서비스가 어떤 식으로든 보호되지 않는 검증 가능한 크리덴셜에
refreshService
속성을 넣는 것은 발급자에게 권장되지 않는다.
검증자가 사용할 수 있도록 refreshService
속성을 검증가능한 크리덴셜 안에 배치하면
보유자가 제어와 동의를 할 수 없게 되고 검증가능한 크리덴셜이
직접적으로 검증자에게 발행되어 보유자를 우회하게 된다.
refreshService
속성의 값은 수신자가 검증가능한 크리덴셜을 리프레시할 수 있도록
수신자의 소프트웨어에 충분한 정보를 제공하는 하나 이상의 리프레시 서비스여야 한다.
각각의 refreshService
값은 타입(예: ManualRefreshService2018
)과
서비스의 URI인 id
를 지정해야 한다.
각 리프레시 서비스의 자세한 내용은 특정 refreshService
의 타입 정의에 의해 결정된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "refreshService": { "id": "https://example.edu/refresh/3732" "type": "ManualRefreshService2018", }, "proof": { ... } }
위의 예에서 발급자는 보유자 또는 검증자를
https://example.edu/refresh/3732
로 디렉팅하는데 사용될 수 있는 수동 refreshService
를 지정한다.
이용약관은 발급자 또는 보유자가 검증가능한 크리덴셜 또는
검증가능한 프레젠테이션이 발급 된 조건을 전달하기 위해 사용될 수 있다.
발급자는 이용약관을 검증가능한 크리덴셜에 배치한다.
보유자는 이용약관을 검증가능한 프레젠테이션에 배치한다.
본 명세서에서는 이용약관 정보를 표현하기 위한 termsOfUse
속성을 정의한다.
termsOfUse
속성의 값은 검증자에게
검증가능한 크리덴셜 또는 검증가능한 프레젠테이션을
승인할 경우 수행해야 하는 조치 (의무), 수행이 허용되지 않거나
(금지) 또는 수행이 허용되는 (허가) 조치를
검증자에게 전한다.
보유자가 아닌 주체가 검증가능한 크리덴셜에 이용약관을 배치하는 방법을 결정하기 위해서 추가 연구가 필요하다. 한가지 방법은 주체가 발급자에게 발급된 검증가능한 크리덴셜 내에 이용 약관을 배치하도록 요청할 수 있다. 다른 방법은 주체가 검증가능한 크리덴셜을 보유자에게 위임하고 위임된 검증가능한 크리덴셜에 이용 약관 제한을 설정할 수 있다.
termsOfUse
속성의 값은 무조건 작성자가 크리덴셜 또는
프레젠테이션을 발행 한 하나 이상의 이용 약관 정책을 지정해야만 한다.
수령자 (보유자 또는 검증자)가 지정된 이용 약관을 준수하지 않을 경우,
책임을 지고 명시된 이용 약관을 위반할 경우 법적 책임을 질 수 있다.
각 termsOfUse
값은 타입을 지정해야 하고
(예: IssuerPolicy
), 인스턴스 id
를 지정할 수 있다.
각 이용 약관의 정확한 내용은 특정 code>termsOfUse 타입 정의에 의해
결정된다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "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"] }] }, "proof": { ... } }
위의 예에서 발급자(assigner
, 양도자)는
검증자(assignee
, 양수자)가 데이터를 아카이브에 저장하지 못하도록 금지한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": ["VerifiablePresentation"], "verifiableCredential": [{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }], "termsOfUse": [{ "type": "HolderPolicy", "id": "http://example.com/policies/credential/6", "profile": "http://example.com/profiles/credential", "prohibition": [{ "assigner": "did:example:ebfeb1f712ebc6f1c276e12ec21", "assignee": "https://wineonline.example.org/", "target": "http://example.edu/credentials/3732", "action": ["3rdPartyCorrelation"] }] }, "proof": [ ... ] }
위의 예에서, 주체인 보유자(assigner
, 양도자)는
검증자(assignee
, 양수자, https://wineonline.example.org
)가
제 3자 서비스를 사용하여 보유자 또는 주체의 상관관계를 표현하기 위해
제공된 정보를 사용하는 것을 금지하는 사용 기간을 명시한다.
검증자가 상관관계를 위해 제 3자 서비스를 사용하는 경우,
보유자는 프레젠테이션을 작성하는 조건을 위반한다.
이 기능은 정부에서 발행한 검증가능한 크리덴셜에 의해 사용되어 전자 지갑이 시민들의 민감한 데이터를 예기치 않게 사용되는 것을 막기 위하여 유사한 정부 기관으로의 사용을 제한하도록 지시한다. 유사하게 민간 산업에서 발행한 검증가능한 크리덴셜은 조직, 부서 내 또는 업무 시간동안 사용을 제한할 것으로 예상된다. 구현자는 검증가능한 크리덴셜 구현 지침 [[?VC-IMP-GUIDE]] 문서의 적합한 장에서 빠르게 발전하는 기능에 대하여 자세히 읽어야 한다.
발급자는 검증자에게 검증가능한 크리덴셜에 추가 지원 정보를 제공하기 위하여 증거가 포함될 수 있다. 이것은 검증자에 의해 검증가능한 크리덴셜의 요구에 의존하는 신뢰를 설정하기 위해 사용될 수 있다.
예를 들어, 발급자는 크리덴셜을 발급하기 전에 주체가 제공한 실제 문서를 확인하거나 사전 검사를 수행할 수 있다. 특정 시나리오에서 이 정보는 주어진 크리덴셜에 의존하는 것과 관련된 위험을 결정할 때 검증자에게 유용하다.
본 명세서는 증거 정보를 표현하기위한 evidence
속성을 정의한다.
evidence
속성의 값은 무조건 검증자가 발급자에
의해 수집한 증거가 크리덴셜에 의존하기 위한 신뢰 요구 사항을 충족하는지 여부를
판단할 수 있는 충분한 정보를 제공하는 하나 이상의 증거 체계이어야만 한다.
각 증거 체계는 타입별로 식별된다.
id
속성은 선택 사항이지만 존재한다면, 이 증거 인스턴스에 대한
추가 정보를 찾을 수 있는 URL을 포함해야 한다. 각 증거 체계의 정확한 내용은 특정
evidence
타입 정의에 의해 결정된다.
명세서에서 크리덴셜 및 크리덴셜이 아닌 데이터에 대한 첨부 및 참조를 지원하는 방법에 대한 자세한 내용은 검증가능한 크리덴셜 구현 지침 [[VC-IMP-GUIDE]] 문서를 참조.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "evidence": [{ "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231", "type": ["DocumentVerification"], "verifier": "https://example.edu/issuers/14", "evidenceDocument": "DriversLicense", "subjectPresence": "Physical", "documentPresence": "Physical" },{ "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192dxyzab", "type": ["SupportingActivity"], "verifier": "https://example.edu/issuers/14", "evidenceDocument": "Fluid Dynamics Focus", "subjectPresence": "Digital", "documentPresence": "Digital" }], "proof": { ... } }
evidence
속성은 proof
속성에 대하여
서로 다른 보완 정보를 제공한다. evidence
속성은
검증가능한 크리덴셜의 무결성과 관련된 문서 증거와 같은 지원 정보를 표현하는 데
사용된다. 반면에 proof
속성은 발급자의 진위 및
검증가능한 크리덴셜의 무결성과 관련된 기계-검증가능한 수학적 증명을
표현하는 데 사용된다. proof
속성에 대한 자세한 내용은
을 참조.
영지식 증명은 개체가 실제 값을 공개하지 않고 특정 값을 알고 있음을 다른 개체에 증명할 수 있는 암호학적 방법이다. 실제 예를 들면 당신의 신분 또는 학위에 포함된 다른 개인 식별 정보 드러내지 않고, 공인된 대학이 당신에게 학위를 수여했음을 증명하는 것이다.
영지식 증명 메커니즘에 의해 도입된 주요 기능은 보유자가 다음을 수행할 수 있게 한다.
이 규격은 영지식 증명 메커니즘을 지원하는 데이터 모델을 설명한다. 아래 예는 데이터 모델을 사용하여 영지식 검증가능한 크리덴셜을 발급, 제시 및 검증 하는 방법을 보여준다.
영지식 검증가능한 크리덴셜을 사용하려면 발급자는 반드시 보유자가 프라이버시 강화 방식으로 검증자에게 정보 제시가 가능하도록 검증가능한 크리덴셜을 발급해야 한다. 이는 보유자가 서명된 값을 밝히지 않거나 선택된 특정 값만 밝힐 때에도 발급자 서명의 유효성을 입증할 수 있음을 의미한다. 표준 관행은 서명 자체를 밝히지 않고, 서명에 대한 지식을 증명함으로써 그렇게 하는 것이다. 검증가능한 크리덴셜을 영지식 증명 시스템에서 사용할 때 두 가지 요구 사항이 있다. 검증가능한 크리덴셜은 반드시 다음을 포함해야 한다.
credentialSchema
속성을 사용한 크리덴셜의 정의.
모든 당사자가 다양한 영지식 암호화 작업을 수행하는 데 사용할 수 있다.
proof
속성을 사용한 프루프.
이것은 원본 검증가능한 크리덴셜에 포함 된 정보를 영지식으로 제시하는
검증가능한 프레젠테이션을 도출하는데 사용할 수 있다.
영지식 검증가능한 프레젠테이션은 보유자가 공개하려 의도하지 않은 정보를 절대 공개해서는 안된다.
다음 예는 영지식 검증가능한 크리덴셜을 사용하는 한 가지 방법을 보여 준다. CL 서명을 사용하여, 검증가능한 크리덴셜 값의 선택적 공개를 통해 보유자와 주체의 프라이버시를 지원하는 방식으로 검증가능한 크리덴셜을 제시할 수 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSchema": { "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o", "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG" }, "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619", "credentialSubject": { "givenName": "Jane", "familyName": "Doe", "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts", "college": "College of Engineering" } }, "proof": { "type": "CLSignature2019", "issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D", "attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy", "signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs", "signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH" } }
위의 예는 credentialSchema
속성과 Camenisch-Lysyanskaya 영지식 증명 시스템에서 사용할 수 있는
특정 증명을 이용하여 검증가능한 크리덴셜의 정의를 제공한다.
다음 예는 위의 검증가능한 크리덴셜을 사용하여 프라이버시 보호 증명이 포함된 새로운 파생 검증가능한 크리덴셜을 생성한다. 파생된 검증가능한 크리덴셜은 검증가능한 프레젠테이션에 배치되며, 이는 전체 주장이 유효함을 추가로 입증한다. 검증가능한 프레젠테이션을 영지식 시스템에서 사용할 때 세 가지 요구사항이 있다.
credentialSchema
속성이 있어야 한다.
이를 통해 파생 검증가능한 크리덴셜이 파생된 증명을 생성하는 데 사용된 크리덴셜의 정의를 참조할 수 있다.
proof
속성을 반드시 포함해야 한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": "VerifiablePresentation", "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSchema": { "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o", "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG" }, "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619", "credentialSubject": { "degreeType": "BachelorDegree", "degreeSchool": "College of Engineering" }, "proof": { "type": "AnonCredDerivedCredentialv1", "primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737", "nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h" } }], "proof": { "type": "AnonCredPresentationProofv1", "proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D" } }
크리덴셜 정의의 형식 및 프루프에 대한 중요한 세부 정보는 이 문서의 범위를 벗어나므로 의도적으로 생략되었다. 이 섹션의 목적은 검증가능한 크리덴셜과 검증가능한 프레젠테이션을 확장하여 영지식 증명 시스템을 지원하려는 구현자들을 안내하는 것이다.
발급자가 발급한 크리덴셜에 이의를 제기하려는 개체에 대하여 최소 두 가지 경우를 고려해야한다:
address
속성이 맞지 않거나 기한이 지났다.
DisputeCredential
을 발급하는 메커니즘은 DisputeCredential
속성의 credentialSubject
식별자가 이의를 제기하는
크리덴셜의 식별자만 제외하면 일반 크리덴셜과 동일하다.
예를 들어, 식별자가 https://example.org/credentials/245
인
크리덴셜에 이의가 있는 경우에 주체는 아래에 표시된 크리덴셜을
발급하고, 이 크리덴셜의 이의를 제기한 크리덴셜과 함께 검증자에게 제시할 수 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.com/credentials/123", "type": ["VerifiableCredential", "DisputeCredential"], "credentialSubject": { "id": "http://example.com/credentials/245", "currentStatus": "Disputed", "statusReason": { "value": "Address is out of date.", "lang": "en" }, }, "issuer": "https://example.com/people#me", "issuanceDate": "2017-12-05T14:27:42Z", "proof": { ... } }
위의 검증가능한 크리덴셜에서 발급자는 이의 제기 가능한 검증가능한 크리덴셜의 주소가 틀렸다고 주장한다.
크리덴셜에 식별자가 없는 경우 content-addressed 식별자를 사용하여 이의를 제기한 크리덴셜을 식별할 수 있다. 유사하게 content-addressed 식별자는 개별 요구사항을 고유하게 식별하는데 사용될 수 있다.
본 연구 영역은 빠르게 발전하고 있으며, 다른 크리덴셜의 정확성에 대해 이의를 제기하는 크리덴셜을 발행하는데 관심이 있는 구현자는 검증가능한 크리덴셜 구현 지침 [[VC-IMP-GUIDE]] 문서에서 분쟁과 관련된 부분을 읽어야 한다.
검증가능한 크리덴셜은 주체에 대한 신뢰할 수 있는 신원증명의 수단으로 만들어졌다. 역할 기반 접근 제어(Role Based Access Controls, RBACs)와 속성 기반 접근 제어(Attribute Based Access Controls, ABACs)는 주체가 자원에 접근하는 것을 승인하는 수단으로써 이 신원인증에 의존하는 것으로 인식되지만, 이 사양은 RBAC 또는 ABAC를 위한 완전한 해결책을 제공하지는 않는다. 승인의 경우 승인 프레임워크 없이 본 사양을 사용하는 것은 적절치 않다.
워킹 그룹은 본 규격의 작성과정에서 인증의 사용 사례를 고려하였으며, 본 규격 위에 구축된 구조적 계층으로서의 작업을 추구하고 있다.
, 그리고 에서 설명한 데이터 모델은 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 규범적 구조적 표현이다. 모든 직렬화는 특정 형식의 데이터 모델의 표현이다. 본 섹션에서는 데이터 모델이 JSON-LD와 일반 JSON에서 실현되는 방식을 명시한다. 비록 이 두 구문에서만 구문적 매핑이 제공되지만, 데이터 모델을 표현할 수 있는 기타 데이터 표현 구문(XML, YAML 또는 CBOR)도 사용할 수 있다. 검증과 유효성 검사 필요사항이 데이터 모델의 관점에서 정의되므로, 모든 직렬화 구문은 결정적으로 처리, 검증 또는 비교를 위한 데이터 모델로 변환되어야 한다. 본 사양은 어떠한 특정 직렬화 형식을 지원하기 위한 요구사항을 만들지 않는다.
본 사양에서 속성 값의 예상되는 아리티 및 그러한 값을 가지는 결과 데이터 타입은 속성에 따라 변동될 수 있다. 만약 존재하는 경우, 다음과 같은 속성들은 단일 값으로 표현된다.
다른 모든 속성들은, 만약 존재할 경우, 단일 값 또는 값의 배열로 표현된다.
섹션 3. 에서 설명한 것과 같이 데이터 모델은 속성 값을 다음과 같은 JSON 타입에 매핑함으로써 Javascript Object Notation (JSON) [[!RFC8259]]으로 인코딩할 수 있다.
여기 나열된 변환은 잠재적으로 양립할 수 없는 해석을 가지고 있으므로, 데이터 모델의 결정론적 변환을 제공할 수 있으려면 추가적인 JSON 형식의 프로파일링이 필요하다.
[[!JSON-LD]]는 연결된 데이터를 직렬화하기 위해 사용되는 JSON기반의 형식이다. 해당 구문은 이미 JSON을 사용하는 것으로 배포된 시스템에 쉽게 통합할 수 있도록 설계되었으며, JSON에서 [[!JSON-LD]]로 부드럽게 업그레이드 할 수 있는 길을 제공한다. 이는 주로 웹 기반 프로그래밍 환경에서 연결된 데이터를 사용하고, 상호 운용 가능한 웹 서비스를 구축하며, JSON 기반 저장소 엔진에서 연결된 데이터를 저장하는 방식으로 사용한다.
[[!JSON-LD]]는 본 사양에서 설명한 데이터 모델을 확장할 때 유용하다. 데이터 모델의
인스턴스는 @context
속성의 추가를 통해, JSON(섹션 )으로 인코딩되는 방식과 동일하게
[[!JSON-LD]]로 인코딩된다. JSON-LD 컨텍스트는
[[!JSON-LD]] 사양에서 상세하게 설명되어 있고,
그것의 사용은 섹션 에서 상술하고 있다.
관용적 JSON에서의 검증가능한 크리덴셜에 대한 임의의 정보를 표현하기 위해 다수의
컨텍스트가 사용되거나 결합될 수 있다. https://www.w3.org/2018/credentials/v1
에서 확인할 수 있는 JSON-LD 컨텍스트는
고정 문서로서 절대 업데이트 되지 않는다.
따라서 클라이언트 사이드에 캐시하거나 다운로드 할 수 있다. 검증가능한 크리덴셜 데이터 모델에
대한 연계된 용어 문서는 https://www.w3.org/2018/credentials
에서 확인할 수 있다.
일반적으로, 본 문서에서 설명하고있는 데이터 모델 및 구문은 개발자가 사례를 복사, 붙여넣기 함으로써 자신의 소프트웨어 시스템에 검증가능한 크리덴셜을 포함할 수 있도록 설계되었다. 이러한 접근의 디자인 목표는 이기종 소프트웨어 시스템 간 글로벌 상호 운용성을 보장하는 동시에 진입장벽을 낮추는 것이다. 본 섹션에서는 대부분의 개발자가 눈치채지 못할 수 있지만 구현하는 사람에게는 관심이 있을 접근방식들에 대해 설명한다. [[!JSON-LD]]에서 가장 주목할만한 신택틱 슈거(Syntatic Sugars)는 아래와 같다.
@id
와 @type
키워드는
각각 id
와 type
으로 구분되어,
개발자가 이 규격을 관용적 JSON으로 사용할 수 있도록 한다.
verifiableCredential
과 proof
속성은
그래프 컨테이너(Graph Containers)로 처리된다.
이는 다른 개체가 주장하는 데이터 집합을 분리하는데 사용되는 메커니즘이다.
이것은 각 발급자가 제공한 데이터 그래프와 각 그래프에 대한 유래를 보장하기 위해
검증가능한 크리덴셜을 제시하는 보유자가 제공하는 정보 간의
적절한 암호학적 구분을 보장한다.
@protected
속성 기능은
본 규격에서 정의한 용어를 재정의할 수 없도록 하는데 사용된다.
이는 동일한 @context
선언이
검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 상단에서 이루어지는 한,
[[!JSON-LD]] 프로세서의 사용 여부와 상관없이
사용자가 이해한 모든 용어에 대한 상호운용성을 보장한다는 의미이다.
이 규격에 기술된 데이터 모델은 증명 형식에 구애받지 않도록 설계되었다. 이 규격은 특정한 디지털 증명이나 서명 형식을 표준으로 요구하지 않는다. 데이터 모델은 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 규범적 표현이지만, 이들의 입증 메커니즘은 종종 당사자 사이의 문서 전송에 사용되는 구문과 관련이 있다. 이와 같이 각 증명 메커니즘은 전송되는 문서의 상태에 대해, 변환된 데이터 모델을 기준으로 또는 다른 양식에 대해 검증이 계산되는지 여부를 명시해야 한다. 출판 당시, 적어도 두 개의 증명 형식이 구현자에 의해 활발하게 사용되고 있으며 작업 그룹은 이러한 증명 형식이 무엇이고 어떻게 사용되고 있는지를 문서화하는 것이 구현자에게 유익할 것이라고 생각했다. 검증가능한 크리덴셜을 발급하기 위해 적극적으로 활용되고 있는 현재 증명 형식을 상세히 기술하는 섹션은 다음과 같다.
JSON Web Token (JWT) [RFC7519]은 여전히 두 당사자 간에 전달되는 클레임을 표현하기 위해 널리 사용되는 수단이다. JWT에 대한 검증가능한 크리덴셜 데이터 모델을 제공함으로써 기존 시스템과 라이브러리가 섹션 에 설명된 생태계에 참여할 수 있다. JWT는 일련의 클레임 JSON Web Signature (JWS) [RFC7515] 또는 JWE [RFC7516]에 포함된 JSON 개체로 인코딩한다. 이 규격에서 JWE의 사용은 범위를 벗어나므로 다루지 않는다.
이 규격은 검증가능한 크리덴셜 데이터 모델의 인코딩 규칙을 JWT 및 JWS에 정의한다. 또한 JWT에 기초한 시스템이 이 규격을 준수할 수 있도록 특정 JWT 형식에 등록된 클레임의 이름과 특정 JWS 등록 헤더 파라미터 이름을 언제 어떻게 사용하는지를 정의한다. 이러한 특정 클레임의 이름과 헤더 파라미터가 존재하는 경우, 그에 대응되는 표준 검증가능한 크리덴셜과 검증가능한 프레젠테이션은 중복 방지를 위해 생략될 수 있다.
이 규격은 JWT에 대한 명시적 인코딩 규칙이 존재하지 않는 표준 검증가능한 크리덴셜 및 검증가능한 프레젠테이션의 일부를 포함하는 새로 등록된 두 개의 클레임의 이름에 대해 소개한다. 이러한 객체들은 다음과 같이 JWT 전송 데이터에 포함되어있다:
vc
: JWT 형식의 검증가능한 크리덴셜에 반드시 있어야 하는 JSON 개체.
객체는 이 규격을 따른 검증가능한 크리덴셜을 포함한다.
vp
: JWT 검증가능한 프레젠테이션에 반드시 있어야 하는 JSON 객체.
객체는 이 규격에 따라 검증가능한 프레젠테이션을 포함한다
검증가능한 크리덴셜을 JWT로 인코딩하려면 이 규격에 의해 명시된 특정 속성은 다음 중 한가지 조건을 만족해야 한다.
명시적 규칙이 지정되지 않은 경우 속성들은 표준 검증가능한 크리덴셜과 동일한 방식으로 인코딩되며
JWT의 vc
클레임에 추가된다. 모든 JWT와 마찬가지로, JWT 구문에 표시된 검증가능한 크리덴셜의
JWS 기반 서명은 디코딩 또는 변환 규칙 적용 전의 JWT 문자열 값에 대해 계산된다.
다음 단락은 이러한 인코딩 규칙을 설명한다.
JWS가 존재하는 경우, 디지털 서명은 검증가능한 크리덴셜의 발급자를 입증하거나,
검증가능한 프레젠테이션의 경우, 검증가능한 크리덴셜의 보유자를 입증한다.
JWS는 JWT의 발급자가 JWT 페이로드에 서명했음을 증명한다. 따라서 proof
속성은 생략될 수 있다.
JWS가 없는 경우 반드시 proof
속성을 제공해야 한다.
proof
속성은 작성자가 발급자와 다른 경우에 필요할 수 있고,
작업 증명과 같은 디지털 서명에 근거하지 않은 증명을 나타내기 위해 사용될 수 있다.
발급자는 검증가능한 크리덴셜에 JWS와 proof
속성을 모두 포함할 수 있다.
하지만 역호환성을 고려한다면 발급자는 JWS를 사용하여 디지털 서명에 기반한 증명을 나타내야 한다.
다음 규칙은 이 규격의 context에서 JOSE 헤더에 적용된다.
alg
는 디지털 서명을 위해 반드시 설정되어야 한다.
선택한 서명 방법에 proof
속성만 필요한 경우(즉, 해당 메소드 내에 선택한 알고리즘이 없는경우)
alg
헤더를 none
으로 설정해야 한다.
kid
를 사용할 수 있다.
주요 과정은 이 규격의 범위를 벗어난다.
예를 들어, kid
는 DID 문서의 키를 참조하거나 JWKS 내부의 키 식별자가 될 수 있다.
typ
가 있는 경우 JWT
로 설정해야 함
JWT 프로세서와의 역호환성을 위해, 다음의 JWT 형식에 등록된 클레임 명칭은 반드시 각각에 대응되는 표준 검증가능한 크리덴셜 대신, 또는 추가로 사용되어야 한다.
exp
는 expirationDate
속성을 나타내야 하고
UNIX 타임스탬프(NumericDate
)로 인코딩되어야 한다.
iss
는 반드시 검증가능한 크리덴셜의 issuer
속성
또는 검증가능한 프레젠테이션의 holder
속성을 나타내야 한다.
nbf
는 반드시 issuanceDate
를 나타내야하고,
UNIX 타임스탬프(NumericDate
)로 인코딩되어야 한다.
jti
는 반드시 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의
id
속성을 나타내야 한다.
sub
는 반드시 검증가능한 크리덴셜 주체에 포함된 id
속성을 나타내야 한다.
aud
는 반드시 검증가능한 프레젠테이션의 의도된 대상
(즉, 프레젠테이션 보유자가 검증가능한 프레젠테이션을 수신하고 검증하도록 의도된 검증자)을
나타내야 한다.(즉, 식별하다)
명시적으로 사용이 금지되어있지 않다면
본 문서에 명시되지 않은 다른 JOSE 헤더 매개변수 및 JWT 클레임 이름을 사용할 수 있다.
추가적인 검증가능한 크리덴셜 클레임은 JWT의 credentialSubject
속성에 추가되어야 한다.
여기에 지정되지 않은 JOSE 헤더 매개 변수 및/또는 JWT 클레임 이름 사용에 대한 자세한 내용은 검증가능한 크리덴셜 구현 지침 [[?VC-IMP-GUIDE]] 문서를 참조.
이 규격 버전은 섹션 고급 개념
(예: refreshService
, termsOfUse
및 evidence
)에 요약된 개념에 대한
JWT별 인코딩 규칙을 정의하지 않는다.
이러한 개념은 별도의 변환 없이 그대로 인코딩할 수 있으며,
JWT의 vc
클레임에 추가될 수 있다.
구현자는 JWT가 복수의 주체들을 인코딩할 수 없고, 따라서 검증가능한 크리덴셜을 둘 이상의 주체와 인코딩할 수 없다는 경고를 받는다. JWT는 향후 여러 주제를 지원할 수 있으며, 구현자는 다중 주체 JWT 클레임 명칭에 대한 JSON Web Token Claim Registry 또는 Nested JSON Web Token 규격을 참조할 것을 권고한다.
JWT를 표준 검증가능한 크리덴셜으로 디코딩하려면 다음 변환을 수행해야 한다.
JWT 특정 헤더 및 클레임을 변환하려면 반드시 다음 작업을 수행.
exp
의 경우 UNIX 타임스탬프는 [[!RFC3339]] date-time
으로 변환해야 하며,
새 JSON 객체의 credentialSubject
expirationDate
속성 값을 설정하는 데 사용해야 한다.
iss
의 경우,
새로운 검증가능한 크리덴셜 JSON 개체의 issuer
속성이나
새로운 검증가능한 프레젠테이션 JSON 개체의 holder
속성을 설정하는 데 이 값을 사용해야 한다.
nbf
의 경우 UNIX 타임스탬프는 [[!RFC3339]] date-time
으로 변환해야 하며,
새로운 JSON 개체의 issuanceDate
속성 값을 설정하는 데 사용해야 한다.
sub
의 경우 이 값을 사용하여 새 JSON 개체의
credentialSubject
의 id
속성 값을 설정해야 한다.
jti
의 경우 값은 반드시 새 JSON 객체의 id
속성 값을 설정하여 사용해야 한다.
{ "alg": "RS256", "typ": "JWT", "kid": "did:example:abfe13f712120431c276e12ecab#keys-1" }
위의 예에서 검증가능한 크리덴셜은 JWS
전자 서명을 기반으로 하는 proof
를 사용하며,
해당 검증 키는 kid
헤더 매개변수를 사용하여 얻을 수 있다.
{ "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21", "jti": "http://example.edu/credentials/3732", "iss": "https://example.com/keys/foo.jwk", "nbf": 1541493724, "iat": 1541493724, "exp": 1573029723, "nonce": "660!6345FSer", "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": ["VerifiableCredential", "UniversityDegreeCredential"], "credentialSubject": { "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } } } }
위의 예시에서 JWT
인코딩은 고유한 식별자를 나타내기 위해
jti
속성을 사용하기 때문에 vc
는 id
속성을 포함하지 않는다.
sub
속성은 credentialSubject
의 id
속성으로 표시되는 정보를 인코딩한다.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0
MzFjMjc2ZTEyZWNhYiNrZXlzLTEifQ.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxY
zI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzc
yI6Imh0dHBzOi8vZXhhbXBsZS5jb20va2V5cy9mb28uandrIiwibmJmIjoxNTQxNDkzNzI0LCJpYXQiO
jE1NDE0OTM3MjQsImV4cCI6MTU3MzAyOTcyMywibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY
29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd
3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjd
CI6eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IjxzcGFuIGxhbmc9J2ZyL
UNBJz5CYWNjYWxhdXLDqWF0IGVuIG11c2lxdWVzIG51bcOpcmlxdWVzPC9zcGFuPiJ9fX19.KLJo5GAy
BND3LDTn9H7FQokEsUEi8jKwXhGvoN3JtRa51xrNDgXDb0cq1UTYB-rK4Ft9YVmR1NI_ZOF8oGc_7wAp
8PHbF2HaWodQIoOBxxT-4WNqAxft7ET6lkH-4S6Ux3rSGAmczMohEEf8eCeN-jC8WekdPl6zKZQj0YPB
1rx6X0-xlFBs7cl6Wt8rfBP_tZ9YgVWrQmUWypSioc0MUyiphmyEbLZagTyPlUyflGlEdqrZAv6eSe6R
txJy6M1-lD7a5HTzanYTWBPAUHDZGyGKXdJw-W_x0IWChBzI8t3kpG253fg6V3tPgHeKXE94fz_QpYfg
--7kLsyBAfQGbg
{ "alg": "RS256", "typ": "JWT", "kid": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1" }
위의 예시에서 검증가능한 프레젠테이션은
JWS
디지털 서명에 기초한 proof
를 사용하며,
해당 검증 키는 kid
헤더 매개변수를 사용하여 얻을 수 있다.
{ "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", "aud": "did:example:4a57546973436f6f6c4a4a57573", "nbf": 1541493724, "iat": 1541493724, "exp": 1573029723, "nonce": "343s$FSFDa-", "vp": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": ["VerifiablePresentation"], // base64url-encoded JWT as string "verifiableCredential": ["..."] } }
위의 예시 에서 JWT
인코딩은 고유한 식별자를 나타내기 위해
jti
속성을 사용하기 때문에 vp
는 id
속성을 포함하지 않는다.
verifiableCredential
에는 JWT
콤팩트 직렬화를 사용하는
검증가능한 크리덴셜의 문자열이 포함되어 있다.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWJjI2tleTEifQ.e
yJpc3MiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJ1cm46d
XVpZDozOTc4MzQ0Zi04NTk2LTRjM2EtYTk3OC04ZmNhYmEzOTAzYzUiLCJhdWQiOiJkaWQ6ZXhhbXBsZ
To0YTU3NTQ2OTczNDM2ZjZmNmM0YTRhNTc1NzMiLCJuYmYiOjE1NDE0OTM3MjQsImlhdCI6MTU0MTQ5M
zcyNCwiZXhwIjoxNTczMDI5NzIzLCJub25jZSI6IjM0M3MkRlNGRGEtIiwidnAiOnsiQGNvbnRleHQiO
lsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCJodHRwczovL3d3dy53My5vc
mcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50Y
XRpb24iLCJDcmVkZW50aWFsTWFuYWdlclByZXNlbnRhdGlvbiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhb
CI6WyJleUpoYkdjaU9pSlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkltUnBaRHBsZUdGd
GNHeGxPbUZpWm1VeE0yWTNNVEl4TWpBME16RmpNamMyWlRFeVpXTmhZaU5yWlhsekxURWlmUS5leUp6Z
FdJaU9pSmthV1E2WlhoaGJYQnNaVHBsWW1abFlqRm1OekV5WldKak5tWXhZekkzTm1VeE1tVmpNakVpT
ENKcWRHa2lPaUpvZEhSd09pOHZaWGhoYlhCc1pTNWxaSFV2WTNKbFpHVnVkR2xoYkhNdk16Y3pNaUlzS
W1semN5STZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWpiMjB2YTJWNWN5OW1iMjh1YW5kcklpd2libUptS
WpveE5UUXhORGt6TnpJMExDSnBZWFFpT2pFMU5ERTBPVE0zTWpRc0ltVjRjQ0k2TVRVM016QXlPVGN5T
Xl3aWJtOXVZMlVpT2lJMk5qQWhOak0wTlVaVFpYSWlMQ0oyWXlJNmV5SkFZMjl1ZEdWNGRDSTZXeUpvZ
EhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZrWlc1MGFXRnNjeTkyTVNJc0ltaDBkSEJ6T
2k4dmQzZDNMbmN6TG05eVp5OHlNREU0TDJOeVpXUmxiblJwWVd4ekwyVjRZVzF3YkdWekwzWXhJbDBzS
W5SNWNHVWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSlZibWwyWlhKemFYUjVSR1ZuY
21WbFEzSmxaR1Z1ZEdsaGJDSmRMQ0pqY21Wa1pXNTBhV0ZzVTNWaWFtVmpkQ0k2ZXlKa1pXZHlaV1VpT
25zaWRIbHdaU0k2SWtKaFkyaGxiRzl5UkdWbmNtVmxJaXdpYm1GdFpTSTZJanh6Y0dGdUlHeGhibWM5S
jJaeUxVTkJKejVDWVdOallXeGhkWExEcVdGMElHVnVJRzExYzJseGRXVnpJRzUxYmNPcGNtbHhkV1Z6U
EM5emNHRnVQaUo5ZlgxOS5LTEpvNUdBeUJORDNMRFRuOUg3RlFva0VzVUVpOGpLd1hoR3ZvTjNKdFJhN
TF4ck5EZ1hEYjBjcTFVVFlCLXJLNEZ0OVlWbVIxTklfWk9GOG9HY183d0FwOFBIYkYySGFXb2RRSW9PQ
nh4VC00V05xQXhmdDdFVDZsa0gtNFM2VXgzclNHQW1jek1vaEVFZjhlQ2VOLWpDOFdla2RQbDZ6S1pRa
jBZUEIxcng2WDAteGxGQnM3Y2w2V3Q4cmZCUF90WjlZZ1ZXclFtVVd5cFNpb2MwTVV5aXBobXlFYkxaY
WdUeVBsVXlmbEdsRWRxclpBdjZlU2U2UnR4Snk2TTEtbEQ3YTVIVHphbllUV0JQQVVIRFpHeUdLWGRKd
y1XX3gwSVdDaEJ6STh0M2twRzI1M2ZnNlYzdFBnSGVLWEU5NGZ6X1FwWWZnLS03a0xzeUJBZlFHYmciX
X19.ft_Eq4IniBrr7gtzRfrYj8Vy1aPXuFZU-6_ai0wvaKcsrzI4JkQEKTvbJwdvIeuGuTqy7ipO-EYi
7V4TvonPuTRdpB7ZHOlYlbZ4wA9WJ6mSVSqDACvYRiFvrOFmie8rgm6GacWatgO4m4NqiFKFko3r58Lu
eFfGw47NK9RcfOkVQeHCq4btaDqksDKeoTrNysF4YS89INa-prWomrLRAhnwLOo1Etp3E4ESAxg73CR2
kA5AoMbf5KtFueWnMcSbQkMRdWcGC1VssC0tB0JffVjq7ZV6OTyV4kl1-UVgiPLXUTpupFfLRhf9QpqM
BjYgP62KvhIvW8BbkGUelYMetA
이 규격은 Linked Data를 이용하여 URL, JSON-LD와 같은 표준을 사용하여 웹에 정보를 게시하여 주체와 관련 속성을 식별한다. 이러한 방식으로 정보를 제시하면 다른 관련 정보를 쉽게 발견할 수 있고 새로운 정보를 기존의 지식 그래프로 쉽게 통합할 수 있다. Linked Data는 분산된 방식으로 확장 가능하여 대규모 통합에 대한 장벽을 크게 줄인다. 이 규격의 데이터 모델은 이 규격에 설명된 대로 데이터 모델을 보호하도록 설계된 Linked Data Proofs, Linked Data Signatures 및 관련 Linked Data Cryptographic Suites와 잘 작동한다.
JSON Web Token의 사용과 달리 별도의 사전 또는 후처리는 필요하지 않다. Linked Data Proofs 형식은 검증가능한 크리덴셜과 검증가능한 프레젠테이션을 간단하고 쉽게 보호하도록 설계되었다. 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션을 보호하는 것은 이 규격의 유효한 예를 Linked Data Signatures 구현에 전달하고 디지털 서명을 생성하는 것만큼 간단하다.
다양한 syntax 형식(예: JSON+JWT, JSON-LD+JWT 또는 JSON-LD+LD-Proofs)의 다양한 품질에 대한 자세한 내용은 검증가능한 크리덴셜 구현 지침 [[VC-IMP-GUIDE]] 문서를 참조.
이 섹션에서는 검증가능한 크리덴셜 데이터 모델을 프로덕션 환경에 배포할 때의 일반적인 프라이버시 고려사항 및 특정 프라이버시 관련 영향에 대해 자세히 설명한다.
익명부터 강하게 식별되는 범위에 이르는 프라이버시의 범주가 있음을 인지하는 것은 중요하다. 사례에 의하면, 사람들은 제공하고자하는 정보와 제공되는 정보에서 파생된 정보에 대해 서로 다른 안도감의 단계를 가지고 있다
예를 들어, 대부분의 사람들은 주류를 구입할 때 익명을 유지하기를 원하는데 그 이유는 필요한 규제 확인은 전적으로 그 사람이 특정 연령 이상인지 여부에 달려있기 때문이다. 그 대신, 의사가 환자를 위해 작성한 의료 처방전의 경우, 처방을 이행하는 약국은 의료 전문자와 환자를 강하게 식별해야 한다. 따라서 모든 사례에 적합한 하나의 프라이버시 접근법은 없다. 프라이버시 해결책은 사례에 따라 다르다.
주류를 구입할 때 익명을 유지하려는 경우에도, 상인에게 적절한 보증을 제공하기 위해 사진 신분증이 필요할 수 있다. 상인은 (당신이 특정 연령 이상이라는 것 이외에) 당신의 이름이나 다른 세부 정보를 알 필요가 없지만, 많은 경우 나이 증명은 규정을 충족하기에 아직 불충분하다.
검증가능한 크리덴셜 데이터 모델은 전체 프라이버시 범주를 지원하기 위해 노력하고 있으며, 어떤 특정 트랜잭션에 대해서도 올바른 수준의 익명성에 대한 철학적 입장을 취하지 않는다. 다음 섹션은 프라이버시에 적대적인 특정 시나리오들을 피하려는 구현자들을 위한 지침을 제공한다.
credential.credentialSubject
필드에 저장된 검증가능한 크리덴셜 관련 데이터는
검증자와 공유할 경우 프라이버시 침해를 허용할 수 있다. 정부에서 발행한 식별자,
배송지 주소, 성명 등과 같은 개인식별정보는 개체를 특정하거나 추적하고 상관관계를
확인하는데 쉽게 사용될 수 있다. 비록 생일과 우편번호의 조합 같이 개인을 식별별하는데
쓸 수 없을 것 같은 정보라도 매우 강력한 상관관계 및 재식별화(De-anonymizing)의
가능성을 가지고 있다.
구현자는 이러한 종류의 특성을 가진 데이터를 공유할 경우 보유자에게 경고할 것을 강력하게
권고한다. 발급자는 가능하면 프라이버시를 보호하는 검증가능한 크리덴셜을 제공할 것을
강력하게 권고한다. 예를들면, 검증자가 개체의 성인 여부를 확인하고자 하면, 생년월일을
담은 검증가능한 크리덴셜을 발행하는 대신 ageOver
검증가능한 크리덴셜을 발행하는 것이다.
검증가능한 크리덴셜은 종종 개인식별정보(PII)를 포함하고 있기 때문에, 구현자는 검증가능한 크리덴셜을 저장하고 전송하는 과정에서 접근하지 말아야 할 사람들로부터 데이터를 보호하기 위한 메커니즘을 사용하도록 해야 한다. 고려할 수 있는 매커니즘은 전송계층보안(TLS, Transport Layer Security) 또는 그 외에 데이터 전송시에는 데이터를 암호화하고 전송 중이 아니더라도 검증가능한 크리덴셜의 데이터를 암호화하거나 접근 제어하는 수단이 있을 수 있다.
검증가능한 크리덴셜의 주체는 credential.credentialSubject.id
필드를 사용하여
식별된다. 주체를 식별하기 위해 사용되는 식별자는 식별자의 수명이 길고 하나 이상의
웹 도메인을 넘나들며 사용될 경우 더 큰 상관관계의 위험을 야기한다.
유사하게, 크리덴셜 식별자(credential.id
)를 공개하는 것은러 검증자가 결탁하거나
혹은 발급자와 검증자가 결탁하여 보유자와의 상관관계를 파악할 수 있는 상황으로 이끌
수 있다. 만약 보유자가 상관관계를 줄이고 싶다면, 검증가능한 프레젠테이션을 하는 동안
식별자를 숨기는 검증가능한 크리덴셜 스킴을 사용해야 한다. 그러한 스킴은 보유자가
식별자를 생성하고 사용자로부터 식별자를 숨기는 것을 허용하는 한편 식별자를 검증가능한 크리덴셜
안에 포함하고 서명할 수 있도록 유지한다.
만약 강력한 상관관계 방지 속성이 요구되는 검증가능한 크리덴셜 체계인 경우, 식별자는 다음 중 하나를 만족하도록 강력히 권고된다:
검증가능한 크리덴셜의 내용은 credential.proof
필드를 사용하여 보호한다. 이 필드의
속성들은 같은 값이 하나 이상의 세션 혹은 도메인에서 사용되고 그 값이 변하지 않을 경우
더 큰 상관관계의 위험을 만들 수 있다. verificationMethod
, create
, proofPurpose
,
jws
필드가 이에 속한다.
만약 강력한 상관관계 방지(Anti-Correlation) 속성이 필요할 경우, 제3자 쌍 서명, 영지식증명 또는 집단 서명 등의 기술을 사용하여 매번 서명값과 메타데이터를 재생성하는 것을 권장한다.
비록 상관관계 방지용 서명을 사용하더라도, 검증가능한 크리덴셜에는 사용된 암호 기술의 상관관계 방지 속성을 무력화시킬 수 있는 정보가 여전히 포함될 수 있다
Verifiable credentials might contain long-lived identifiers that could be used to correlate individuals. These types of identifiers include subject identifiers, email addresses, government-issued identifiers, organization-issued identifiers, addresses, healthcare vitals, verifiable credential-specific JSON-LD contexts, and many other sorts of long-lived identifiers. 검증가능한 크리덴셜은 개인의 상관관계를 파악하는데 사용될 수 있는 수명이 긴 식별자를 포함할 수 있다. 이러한 종류의 식별자에는 주체 식별자, 이메일 주소, 정부 발행 식별자, 조직 발행 식별자, 주소, 헬스케어 바이탈, 검증가능한 크리덴셜 특화 JSON-LD 컨텍스트, 그리고 수 많은 종류의 수명이 긴 식별자가 포함된다.
보유자에게 소프트웨어를 제공하는 조직은 개인의 상관관계를 파악하는데 사용되는 정보가 포함된 검증가능한 크리덴셜의 필드를 식별하여, 이 정보가 공유될 때 보유자에게 경고해야 한다
인터넷과 웹상에서 개인을 추적하고 상관관계를 파악하는데 사용되는 검증가능한 크리덴셜 외부의 메커니즘들이 있다. 이러한 메커니즘은 인터넷 프로토콜(IP) 주소 추적, 웹 브라우저 핑거프린팅, 에버쿠키(evercookie), 광고 네트워크 추적기, 모바일 네트워크 위치 정보, 인앱 GPS API 등을 포함한다. 검증가능한 크리덴셜을 사용하는 것이 이러한 기술을 사용하는 것을 막지는 못한다. 또한, 이러한 기술들이 검증가능한 크리덴셜과 결합되어 사용되면 새로운 상관관계를 파악할 수 있는 정보들을 발견할 수도 있다. 예를 들어, 생일과 GPS 위치를 결합하면 다수의 웹사이트에서 개인에 대한 강력한 상관관계를 파악하는데 사용될 수 있다.
개인정보보호를 중요하게 여기는 시스템에서 검증가능한 크리덴셜을 사용하는 경우, 이러한 추적 기술들의 사용을 방지하도록 하는 것이 권장한다. 경우에 따라서는 보유자를 대신하여 검증가능한 크리덴셜을 전송하는 기기에서 추적 기술들이 비활성화 하는 것도 요구될 수 있다.
검증가능한 크리덴셜을 받는 사람이 필요 이상으로 개인식별정보를 노출하지 않으면서도 다양한 상황에서 활용할 수 있도록 하기 위해 발급자는 크리덴셜의 정보를 예상되는 목적에 필요한 최소한의 정보로 제한하는 것을 고려해야 한다. 개인식별정보를 크리덴셜에 포함하지 않도록 하는 방법 중 하나는 주체에 대한 특정한 정보를 제공하지 않으면서도 검증자의 요구를 만족시키는 추상 속성을 사용하는 것이다.
예를 들면, 본 문서는 강력한 개인식별정보인 생일을 사용하는 대신 ageOver
속성을 사용한다.
만약 특정 시장의 소매업자가 일반적으로 구매자에게 특정 나이 이상을 요구하는 경우,
그 시장에서 신뢰받는 발급자는 주체의 생일에 대한 클레임을 포함하는 검증가능한 크리덴셜을
제공하기 보다는 주체가 그 조건을 만족한다고 주장하는 검증가능한 크리덴셜을 제공하는 것을
선택할 것이다. 이로인해 개인 소비자가 특정 개인식별정보를 드러내지 않으면서도 구매를 할 수 있게 된다.
한 컨텍스트에서 유출된 정보가 다른 컨텍스트로 유출되면 개인정보보호 위반이 발생한다. 이러한 위반을 방지하기 위해 허용되는 모범 사례는 요청 및 수신한 정보를 최소한으로 제한하는 것 이다. 데이터 최소화 접근법은 미국의 HIPAA (Health Insurance Portability and Accountability Act) 및 EU의 GDPR (General Data Protection Regulation)을 포함한 여러 관할권의 규정에 의해 요구된다.
발급자를 위한 데이터 최소화가 뜻하는 것은 검증가능한 크리덴셜의 사용을 예상하여 잠재적 검증자가 요구하는 최소값으로 제한하는 것을 의미한다. 검증자의 경우 데이터 최소화는 서비스 접근에 요구 또는 정보의 범위를 제한하는 것을 의미한다.
예를 들어, 면허 번호, 키, 몸무게, 생일, 주소가 포함된 운전 면허증은 개인이 특정 연령 이상임을 확인하는데 필요한 것보다 많은 정보가 포함된 크리덴셜이다.
발급자가 정보를 원자화하거나 선택적 공개를 허용하는 서명 체계를 사용하는
것이 가장 좋은 사례이다. 예를 들어, 운전면허 발급자는 운전 면허에 나타나는
모든 속성이 포함된 검증가능한 크리덴셜과 개인의 생일과 같은 단일 속성만
포함되는 검증가능한 크리덴셜 집합을 발급할 수 있다. 또한, 더 추상적인
검증가능한 크리덴셜을 발행할 수 있다 (예 : ageOver
특성만
포함하는 검증가능한 크리덴셜). 한 가지 가능한 적용 방법은 발급자가
검증가능한 크리덴셜의 익명 사용을 촉진하는 일회용 무기명 크리덴셜을
검색하기 위한 보안 HTTP 엔드포인트를 제공하는 것이다. 부적절하거나 위험을 발견한
구현자는 선택적 공개를 사용하여 발급자에 대한 의존성을 제거하고
발급자의 일시적인 상관 위험을 줄여야 한다.
검증자는 특정 트랜젝션이 발생하는데 꼭 필요한 정보만 요청해야 한다. 이는 두 종류의 이유로 중요하다:
최소 공개 원칙을 실행하는 것은 가능하지만, 단일 또는 다중 세션 동안 특정 사례에서 개인의 강력한 식별을 피하는 것은 불가능할 수 있다. 본 표준의 저자는 실제 시나리오에서 원칙을 달성하는 것은 어려울 수 있다고 강요하지 않는다.
무기명 크리덴셜은 콘서트 티켓과 같은 개인정보보호 강화 정보로, 보유자에게는 자신에 대한 민감한 정보를 공개하지 않고도 특정 자원에 대한 크리덴셜을 부여 할 수 있다. 무기명 크리덴셜은 종종 무기명 크리덴셜 공유가 문제가 되지 않거나 경제적 또는 평판의 손실이 크지 않은 저 위험 사례에서 사용된다.
무기명 크리덴셜인 검증가능한 크리덴셜은
credentialSubject
속성에 중첩된 id
속성을
사용하여 표현된 주체 식별자를 지정하지 않으면 가능하다.
예를 들어 다음과 같은 검증가능한 크리덴셜은 무기명 크리덴셜이다:
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/temporary/28934792387492384", "type": ["VerifiableCredential", "UniversityDegreeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2017-10-22T12:23:48Z", "credentialSubject": { // 무기명 크리덴셜에 ‘id’ 속성이 지정되어 있지 않음 "degree": { "type": "BachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { ... } }
무기명 크리덴셜은 개인정보보호를 강화할 수 있지만, 무기명 크리덴셜 보유자가 예상한 것보다 더 많은 정보를 실수로 공개하지 않도록 신중하게 만들어야 한다. 예를 들어, 다수의 사이트에서 동일한 무기명 크리덴셜을 반복적으로 사용하면 사이트들이 담합하여 잠재적으로 보유자를 추적하거나 연동시킬 수 있다. 또한 생년월일 및 우편 번호와 같이 식별할 수 없는 것처럼 보이는 정보를 사용하여 동일한 무기명 크리덴셜 또는 세션에서 함께 사용될 경우, 개인을 통계적으로 식별할 수 있다.
무기명 크리덴셜 발급자는 무기명 크리덴셜이 다음과 같은 개인정보보호 강화를 제공하는지 확인해야 한다:
민감한 정보가 포함된 무기명 크리덴셜이 발행, 요청되거나 하나 이상의 세션에서 두 가지 이상의 무기명 크리덴셜을 결합되거나 상관 관계 위험이 있는 경우, 소프트웨어는 보유자에게 경고해야 한다. 모든 상관 관계 위험을 감지하는 것은 불가능하지만 일부는 확실하게 감지할 수 있다.
검증가능한 크리덴셜을 처리할 때 검증자는 의 유효성 검증 및 다양한 특정 비즈니스 프로세스 점검에 나열된 검사를 수행해야 한다. 유효성 검사는 아래 항목이 포함된다:
이러한 검사를 수행하면 정보 유출로 인해 보유자의 개인정보보호 위반이 발생할 수 있다. 예를 들어 폐기 목록 확인과 같은 간단한 조작으로 특정 비즈니스가 보유자와 상호작용 한다는 것을 발급자에게 알릴 수 있다. 이는 발급자들은 담합과 연동을 개인들에 대한 정보 없이 할 수 있다.
발급자는 크리덴셜마다 검증과정에서 개인정보보호 위반이 발생할 수 있는 구간에 크리덴셜마다 고유한 폐기 목록과 같은 메커니즘을 사용하지 않아야 한다. 보유자에게 소프트웨어를 제공하는 조직은 크리덴셜 검증 과정 중에 개인정보보호 위반으로 이어질 수 있는 정보가 포함된 경우 경고해야 한다. 검증자는 개인정보 침해를 유발하거나 개인정보보호 정책을 위반하는 크리덴셜을 거부해야 한다.
보유자가 발급자로부터 검증가능한 크리덴셜을 받으면 검증가능한 크리덴셜은 어딘가에 저장되어야 한다 (예: 크리덴셜 저장소). 보유자는 검증가능한 크리덴셜의 정보가 본질적으로 민감하고, 고도로 개인화되어 데이터 마이닝의 가치 높은 대상이 된다는것을 경고받는다. 검증가능한 크리덴셜의 무료 저장을 홍보하는 서비스는 실제로 개인 데이터를 마이닝하여 개인 및 조직에 대한 개인화된 프로필을 구축하려는 조직에 판매하는 것일 수 있다.
보유자들은 크리덴셜 저장소의 서비스 약관, 특히 서비스 제공 업체에 검증가능한 크리덴셜을 저장하는 사람들을 위한 상관 관계 및 데이터 마이닝으로부터 보호에 대한 부분을 알고있어야 한다.
데이터 마이닝 및 프로파일링에 대한 몇가지 효과적인 방법은 다음과 같다:
동일한 주체에 대해 두 개의 정보를 보유하면, 그 정보가 다른 채널을 통해 전달되는 경우에도 그 주체에 대해 두 개의 합계보다 더 많은 정보를 노출하게 된다. 검증가능한 크리덴셜을 수집하는것은 프라이버시 위험이며 이 생태계의 모든 참가자들은 데이터 수집의 위험성을 알고있어야 한다.
예를 들어, 이메일 주소에 대한 크리덴셜이 하나 있고 보유자가 21세 이상이라는 사실에 대한 크리덴셜이 하나 있는 상황에서 두개의 크리덴셜이 다수의 세션에 걸쳐 공유되었다면, 검증자는 이제 그 개인에 대한 고유한 식별자와 연령 관련 정보를 갖게 된다. 이제 시간이 갈수록 그 보유자에 대한 프로필을 생성하기 점점 더 쉬워진다. 여러 사이트에서 크리덴셜 수집을 할수도 있고, 이는 심각한 프라이버시 문제를 초래할 수도 있다.
기술적인 관점에서 볼 때 정보 수집을 방지하는것은 매우 어려운 프라이버시 문제이다. 영지식증명과 같은 새로운 암호화 기술이 수집 및 상관관계 문제에 대한 솔루션으로 제안되고 있지만, 오래 지속되는 식별자와 브라우저 추적 기술의 존재는 가장 현대적인 암호화 기술조차도 능가한다.
상관관계 또는 수집의 프라이버시 영향에 대한 해결책은 본질적으로 기술적인것이 아니라 정책 중심이다. 따라서 보유자가 자신에 대한 정보가 수집되길 바라지않는 경우, 그들이 보내는 검증가능한 프레젠테이션에 표시해야 한다.
개인정보보호를 위한 최선의 노력에도 불구하고 실제로 검증가능한 크리덴셜을 사용하면 익명성이 해제되고 프라이버시가 손실될 수 있다. 이 상관관계는 다음과 같은 경우에 발생할 수 있다:
어떤 부분들은 다음과 같은 방법으로 비익명화 및 프라이버시 손실을 완화 할 수 있다:
이러한 완화 기술이 항상 실용적이거나 필요한 사용법과 호환되는 것은 아님을 이해해야 한다. 때로는 상관관계가 필요하기도 하다.
예를 들어, 일부 처방약 모니터링 프로그램에서는 사용량 모니터링이 필요하다. 집행 주체는 개인이 통제 약품에 대해 복수의 처방을 받기 위해 시스템을 속이는 것이 아님을 확인할 수 있어야 한다. 사용량의 상관관계를 위한 법규나 규정은 개인의 프라이버시 문제보다 중요하다.
검증가능한 크리덴셜은 서비스들 사이에서 의도적으로 연관시키는 경우가 있다. 예를 들어, 동일 페르소나가 다수의 서비스에 로그인 할 때, 각각의 서비스에서 활동들이 의도적으로 동일 인물에게 연결된다. 이러한 각 서비스들이 예상한 방식으로 상관관계를 사용하는 한 프라이버시 문제는 아니다.
어떤 보유자가 어떤 검증자와 정보를 공유하기로 결정했을 때, 그 검증자는 정직하지 못하게 행동하면서 보유자에게 해를 끼치는데 사용할 수 있는 정보를 요청하는 경우가 발생할 수 있다. 예를 들어, 검증자는 은행 계좌 번호를 요청하고 다른 정보와 함께 사용함으로써 보유자나 은행을 속일 수 있다.
발급자는 가능한 많은 정보를 토큰화함으로써, 보유자가 뜻하지 않게 크리덴셜들을 잘못된 검증자에게 전달한 경우에도, 그 상황이 재앙이 되지 않도록 노력해야 한다.
예를 들어 개인의 은행 잔고를 확인하기 위해 은행 계좌 번호를 (검증가능한 크리덴셜에) 포함하는 대신에, 잔액이 얼마 이상인지만 검증자가 확인하는데 사용할 수 있는 토큰을 제공할 수 있다. 이 경우에 은행은 잔액 확인용 토큰이 포함된 검증가능 크리덴셜을 보유자에게 발급할 수 있다. 보유자는 그 검증가능한 크리덴셜을 검증가능한 프레젠테이션에 포함하고, 전자 서명을 이용하여 그 토큰을 신용 조회 기관에 결합시킨다. 검증자는 그들의 전자서명으로 검증가능한 프레젠테이션을 한번 감싸고, 그것을 발급자에게 돌려주므로써 동적으로 계좌 잔액을 확인할 수 있다.
이러한 접근 방식을 이용하여, 보유자가 계좌 잔액 토큰을 잘못된 당사자에게 공유했다 하더라도 공격자는 은행 계좌 번호나 정확한 계좌 잔고를 알 수 없게 된다. 그리고 (보유자의) 카운터 서명에 주어진 유효 기간으로 인해, 몇 분이 지나면 토큰에 대한 접근 권한을 얻지 못하게 된다.
섹션 에 자세히 설명한 것처럼, 사용 패턴은 특정 형태의 행위와 연관될 수 있다. 이러한 연관성은 보유자가 발급자에 대한 지식 없이 검증가능한 크리덴셜을 사용함으로써 일부 완화된다. 그러나 발급자는 그들이 발급하는 검증가능한 크리덴셜을 단기적이고 자동갱신 되도록 만듬으로써 이러한 보호를 의미없게 만들 수 있다.
예를 들어, ageOver
검증가능 크리덴셜은 술집 출입 가능 여부를 판단하는데 유용하다.
만약 발급자가 그러한 검증가능 크리덴셜을 아주 짧은 만료 시기와 자동 갱신 메커니즘으로 발급한다면,
발급자는 보유자의 행위를 보유자에게 부정적인 영향을 미치는 방식으로 연관시킬 수 있다.
보유자에게 소프트웨어를 제공하는 조직들은 보유자가 짧은 수명을 가진 크리덴셜을 반복적으로 사용하는 경우에 보유자에게 행위 연관성이 발생할 수 있음을 경고해야 한다. 발급자는 사용 패턴을 연관시키는 방식의 크리덴셜 발급을 피해야한다.
이상적인 사생활 존중 시스템은 검증자와 상호작용하기 위해 필요한 정보만을 보유자가 공개하도록 요구한다. 검증자는 공개 요구사항을 만족하는 정보만을 기록하고, 공개된 정보 중 나머지 민감한 정보는 저장하지 않는다. 많은 경우에 규제적인 부담과 같은 우선순위의 경쟁으로 인해 이런 이상적인 시스템을 채택하는 것이 쉽지 않다. 다른 경우는, 수명이 긴 식별자가 일회성을 저해한다. 그러나 모든 검증가능한 크리덴셜 생태계의 설계는 가능할 때마다 일회용 검증가능한 크리덴셜을 선호함으로써 사생활을 존중하기 위해 노력해야 한다.
일회용 검증가능한 크리덴셜을 사용하는 것은 여러가지 이점이 있다. 첫번째 이점은 검증자 입장에서 검증가능한 크리덴셜에 있는 데이터가 최신이라는 것을 확신할 수 있다는 점이다. 두번째 이점은 보유자 입장에서 만약 수명이 긴 식별자가 검증가능한 크리덴셜에 존재하지 않는다면 검증가능한 크리덴셜 자체는 온라인 상에서 자신을 추적하거나 연관시킬 수 없다는 점을 알게된다는 점이다. 마지막으로 공격자가 훔칠만한 것이 존재하지 않기 때문에 운영되는 전체 생태계가 더 안전해진다는 것이다.
이상적인 시크릿 브라우징 모드 시나리오에서는, 어떤 개인 개인식별정보(PII, Personally Identifiable Information)도 노출되지 않을 것이다. 많은 크리덴셜들이 개인식별정보를 포함하고 있기 때문에, 소프트웨어를 제공하는 조직들은 시크릿 브라우징 모드에서 크리덴셜과 프레젠테이션을 사용하면 개인식별정보가 노출될 수 있음을 보유자에게 경고해야 한다. 각 브라우저 공급자들마다 시크릿 모드를 처리하는 방식이 다르고, 어떤 브라우저는 이러한 경고 기능을 제공하지 않을 수도 있기 때문에, 구현자들이 이러한 차이점을 인지하고 그에 맞게 솔루션을 구현하는 것이 중요하다.
발급자, 보유자, 검증자가 이 명세서에서 설명하고 있는 데이터를 처리할 때 인지하고 있어야 하는 보안 고려사항이 아주 많이 있다. 이 섹션에서 설명하는 내용이 함축하는 바를 무시하거나 이해하지 못한다면 보안 취약점이 발생할 수 있다.
이번 섹션에서 다양한 보안 고려사항을 강조하고 있지만, 이것이 완전한 리스트는 아니다. 구현자는 이 명세서에서 서술한 기술을 이용하여 미션 크리티컬한 시스템을 구축하는 경우, 보안과 암호학 전문가들에게 추가적인 조언을 구해야 한다.
이 명세서에서 설명한 데이터 모델의 일부 측면은 암호학을 이용하여 보호할 수 있다. 구현자가 크리덴셜과 프레젠테이션을 생성하고 처리함에 있어서 사용되는 암호화 스위트와 라이브러리를 이해하는 것은 중요하다. 암호화 시스템을 구축하고 감사하는 것은 일반적으로 상당한 경험을 필요로 한다. 효과적인 레드팀 구성을 통해 보안성 리뷰에서 나타날 수 있는 편향을 방지할 수 있다.
암호화 스위트와 라이브러리는 일종의 유통기한이 있어서 결국 새로운 공격과 기술 발달에 노출된다. 제품 품질 관리 시스템은 이러한 특성을 고려하여 만료되거나 깨진 암호화 수트와 라이브러리를 간단히 선제적으로 업그레이드가 가능하도록 구성하고, 이미 발급된 크리덴셜을 무효화하고 교체할 수 있는 메커니즘을 보장해야 한다. 주기적인 모니터링은 크리덴셜을 처리하는 시스템의 장기 생존을 보장하는데 중요하다.
검증가능한 크리덴셜에는 외부에서 자신을 검증하기 위한 검증가능한 크리덴셜을 가르키는 URL들이 종종 포함되어 있다. 외부에 존재하는 이미지, JSON-LD 컨택스트 및 기계판독가능데이터들과 같은 링크된 컨텐츠는 검증가능한 크리덴셜의 증명을 통한 보호에서 벗어나 있기 때문에, 변조로 부터 종종 보호되지 않는다. 예를 들어 다음과 같이 강조표시된 링크들은 컨탠츠 무결성이 보호되지 않지만, 아마도 다음과 같을 것이다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/58473", "type": ["VerifiableCredential", "AlumniCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "image": "https://example.edu/images/58473", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }, { "value": "Exemple d'Université", "lang": "fr" }] } }, "proof": { ... } }
이 규격에서 내용 무결성 보호를 위해 특정한 방법을 권장하지 않지만, 링크된 내용의 무결성 보호를 원하는 작성자는 내용의 무결성을 강화하는 URL체계를 사용할 것을 권장한다. 이러한 2가치 체계는 [[HASHLINK]]규격과 [[IPFS]]이다. 다음의 예제는 이전의 예를 변형해서 [[HASHLINK]]규격을 이용해 JSON-LD 컨텍스트에 내용 무결성 보호를 추가하고, [[IPFS]] 링크를 사용하여 이미지에 내용 무결성 보호를 추가하였다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1?hl=z3aq31uzgnZBuWNzUB", "https://www.w3.org/2018/credentials/examples/v1?hl=z8guWNzUBnZBu3aq31" ], "id": "http://example.edu/credentials/58473", "type": ["VerifiableCredential", "AlumniCredential"], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "image": "ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }, { "value": "Exemple d'Université", "lang": "fr" }] } }, "proof": { ... } }
프로덕션 구현에는 중요한 JSON-LD 컨텍스트의 정적 사본이 제공 될 것으로 예상되므로, 위의 JSON-LD 컨텍스트에 보호가 필요한지 여부는 논란의 여지가 있다.
위의 예는 내용 무결성 보호를 달성하는 한 가지 방법이지만 특정 애플리케이션들에 더 적합한 다른 솔루션들이 있다. 구현자들은 내용 무결성으로 보호되지 않는 외부의 기계판독가능한 내용들에 대한 링크가 어떻게 그들의 어플리케이션에 대한 성공적인 공격을 만들어 낼 수 있는지 이해해야 한다.
이 규격은 어떠한 서명이나 증명도 포함하지 않은 크리덴셜을 만들 수 있도록 한다. 이러한 유형의 크리덴셜은 웹 페이지에서 양식을 작성하는 것과 유사한 자가증명, 중간 저장소에 종종 유용하다. 구현자는 이러한 종류의 크리덴셜들은 작성자가 알려지 있지 않거나, 신뢰할 수 없기 떄문에 검증할 수 없다는걸 알아야 한다.
검증자는 이것이 중간자 공격의 목표가 아닌 검증가능한 프레젠테이션의 수신자인지 확인해야 할 수도 있다. 요청에 의해서 검증가능한 프레젠테이션 응답을 묶은 토큰 바인딩 [[RFC8471]]과 같은 접근 방법으로 프로토콜을 보호할 수 있다. 보안되지 않은 모든 프로토콜은 중간자 공격에 취약하다.
발급자가 크리덴셜의 정보를 원자화하거나, 선택적 공개를 허용하는 서명체계를 이용하는 것이 가장 좋다. 원자화의 경우에, 만약 발급자에 의해 안전하게 완료되지 않았다면, 발급자가 의도하지 않은 방식으로 보유자의 다른 크리덴셜과 묶일 수 있다.
예를 들어, 대학은 한사람에게 2종류의 검증가능한 크리덴셜을 발급할 수 있는데, 각 자격증에는 "컴퓨터 부서"의 "담당자" 또는 "경제학과"의 "대학원생"과 같이 주어진 "부서"와 "역할"의 2가지 속성이 각각 포함되어 있다. 만약 이러한 속성들 중 단지 하나만이 크리덴셜에 포함되어 원자화된다면, 대학은 한사람에게 4개의 크리덴셜을 발급해야 한다. 각각의 크리덴셜들은 "직원", "대학원생", "컴퓨터 부서", "경제학과"가 될 것이다. 보유자는 검증자에게 "직원"과 "경제학과"의 검증가능한 크리덴셜을 전송할 수 있으며, 이는 잘못된 클레임이 된다.
매우 동적인 정보에 대한 검증가능한 크리덴셜을 발급하는 경우, 구현자는 만료기간을 적절하게 설정해야한다. 검증가능한 크리덴셜의 유효기간보다 만료기간이 더 길다면 악용가능한 보안취약성이 발생할 수 있다. 검증가능한 크리덴셜을 통해 표현되는 정보의 만료기간이 유효기간보다 짧으면 보유자와 검증자에게 부담을 준다. 따라서 사용사례와 검증가능한 크리덴셜에 포함된 정보의 예상 수명에 유효기간의 적절한 설정은 중요하다.
검증가능한 크리덴셜이 저장된 장치가 분실되거나 도난당했을 때, 공갹자가 피해자의 검증가능한 크리덴셜을 사용하여 시스템에 접속할 수 있다. 이러한 유형의 공격을 완화하는 방법으로는:
구현자가 이 규격에 기술된 데이터를 처리할 때 알아야할 많은 접근성에 대한 고려사항이 있다. 모든 웹표준 또는 프로토콜의 구현과 마찬가지로 접근성 문제에 대한 무시하게 되면 모집단의 상당부분에서 이 정보를 이용할수 없게 된다. [[WCAG21]]과 같은 접근성 가이드라인과 표준을 지켜 모든 사람들이 능력에 개의치 않고 이 정보를 사용할 수 있게 만드는 것은 매우 중요하다. 역사적으로 보조기술에 문제를 야기한 암호학을 이용한 시스템을 구축할 때 이것은 특별히 중요하다.
이 절에서는 이 데이터 모델을 활용할 때 고려해야 할 일반적인 접근성에 대한 고려사항을 자세히 설명한다.
정부에서 발행한 신분증과 같이 오늘날 사용하고 있는 많은 물리적인 인증서들은 인쇄가 너무 작거나, 작지만 고해상도의 이미지에 의존하거나, 시각적 장애를 가진 사람들에게 제공할 수 없는 등의 제약이 포함되어 있는 특징들에 의해 접근성이 매우 열악하다.
데이터모델을 이용해 검증가능한 크리덴셜을 만들때, 데이터 모델 디자이너는 데이터 우선 접근 방식을 사용하는 것이 좋다. 예를 들어, 크리덴셜을 묘사하기 위해 데이터 또는 그래픽 이미지를 사용하기로 선택한 경우, 디자이너는 기관의 이름 또는 전문 자격과 같은 이미지의 모든 요소를 시청자의 해석에 의존하지 말고 기계판독이 가능한 방식으로 표현해야한다. 데이터 우선 접근 방식은 다양한 능력을 가진 사람들을 위해 서로 다른 인터페이스를 구축을 위한 기본 요소를 제공하기 때문에 선호된다.
구현자는 이 사양에 설명 된 데이터를 게시 할 때 여러 국제화 고려 사항을 알고 있어야 한다. 웹 표준 또는 프로토콜 구현과 마찬가지로 국제화를 무시하면 데이터의 다른 언어와 사회에서 데이터를 생성하고 소비하기가 어려워지므로 사양의 적용 가능성이 제한되고 표준으로서의 가치가 크게 떨어진다.
구현자는 국제화를 지원하기 위해 텍스트에 대한 신뢰할 수 있는 메타 데이터를 제공하는 W3C 국제화 활동에서 발행 한 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [[STRING-META]] 읽기를 권장한다. 국제화 고려 사항에 대한 최신 정보를 얻으려면 구현자는 확인 가능한 자격 증명 구현 지침 [[VC-IMP-GUIDE]] 문서를 읽어야한다.
이 섹션에서는이 데이터 모델을 사용할 때 고려해야 할 일반적인 국제화 고려 사항에 대해 간략하게 설명하고 있으며 구현자가 관심 있을 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [[STRING-META]]의 특정 부분을 강조하기 위해 구현되었다.
데이터 퍼블리셔는 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [[STRING-META]]의 교차 구문 표현식 섹션을 읽고 [[JSON-LD]], [[JSON]] 및 CBOR [[?RFC7049]]와 같이 여러 표현식 구문에서 언어 및 기본 방향 정보를 표현할 수 있도록 하는 것이 좋다.
일반적인 디자인 패턴은 언어 및 선택적으로 특정 기준 방향으로 태그가 지정된 텍스트 문자열을 표현할 때 다음 마크 업 템플릿을 사용하는 것이다.
"property": { "value": "The string value", "lang": "LANGUAGE
" "dir": "DIRECTION
" }
위의 디자인 패턴을 사용하여 다음 예제는 텍스트 방향을 지정하지 않고 책 제목을 영어로 표현한다.
"title": {
"value": "HTML and CSS: Designing and Creating Websites",
"lang": "en
"
}
다음 예는 오른쪽에서 왼쪽으로 기본 방향으로 아랍어로 표현 된 유사한 제목을 사용한다.
"title": { "value": "HTML و CSS: تصميم و إنشاء مواقع الويب", "lang": "ar
" "dir": "rtl
" }
많은 시스템에서 텍스트 문자열의 첫 번째 문자를 사용하여 텍스트 방향을 결정하므로 위의 텍스트는 언어와 방향을 명시적으로 표현하지 않고 왼쪽에서 오른쪽으로 잘못 표시된다.
JSON-LD를 사용하는 구현자는
국제화 된 속성을 정의하는 JSON-LD 컨텍스트를 extend하고
JSON-LD의 범위
지정된 컨텍스트 기능을 사용하여
@value
, @language
및 @direction
키워드를
value
, lang
및 dir
로 별명
지정해야한다. 각기. 이를 수행하는 JSON-LD 컨텍스트 스니펫의 예는 다음과 같다.
"title": {
"@context": {"value": "@value", "lang": "@language", "dir": "@direction"},
"@id": "https://www.w3.org/2018/credentials/examples#title"
}
여러 언어, 기본 방향 및 주석이 단일 자연 언어 문자열로 사용되는 경우
일반적으로 더 복잡한 메커니즘이 필요하다.
HTML과 같은 마크 업 언어를 사용하여 여러 언어와 기본 방향으로 텍스트를 인코딩 할 수 있다.
rdf : HTML
데이터 유형을 사용하여 이러한 값을 JSON-LD로 정확하게 인코딩 할 수도 있다.
정보를 HTML로 인코딩하는 기능에도 불구하고 구현자는 다음과 같은 이유로 이 작업을 수행하지 않는 것이 좋다.
script
태그가 실행될 수 있으므로 이 데이터 모델을 사용할 때 보안 공격 영역이 증가한다.
구현자가 특정 사용 사례를 해결하기 위해 HTML 또는 실행 가능한 스크립트를 포함 할 수있는 다른 마크 업 언어를 사용해야한다고 생각하는 경우, 구현자는 공격자가 어떻게 마크 업을 사용하여 마크 업 소비자에 대한 인젝션 공격을 마운트 하는지 분석 후 식별된 공격에 대한 완화를 배포 한다.
이 사양은 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 검증 프로세스에 대한 적합성 기준을 제공하지는 않지만 독자는 유효성 검사에서 검증자가 이 데이터 모델의 정보를 어떻게 활용할지 궁금 할 것이다. 이 섹션에서는 검증자가이 사양에서 예상되는 데이터 필드 사용과 관련하여 실무 그룹(working group)이 보유한 대화를 공유(capture)한다.
보유자가 제시 한 검증가능한 크리덴셜에서
각 credentialSubject
의 id 속성과 연관된 값은 검증자에게
주체를 식별해야 한다. 보유자가 주체인 경우, 검증자는 보유자와 관련된 공개 키 메타 데이터가있는 경우
보유자를 인증 할 수 있다. 검증자는 검증가능한 프레젠테이션에 포함 된 보유자에 의해 생성 된 서명을
사용하여 보유자를 인증 할 수있다. id 속성은 선택 사항이다. 검증자는 검증가능한 크리덴셜에서 다른
속성들을 사용하여 주체를 고유하게 식별 할 수 있다.
인증 및 WebAuthn이 검증가능한 크리덴셜로 작동하는 방법에 대한 자세한 내용은 검증가능한 크리덴셜 구현 지침 [[VC-IMP-GUIDE]] 문서를 참조.
issuer
속성과 관련된 값은 검증자에게 알려지고 신뢰할 수있는 발급자를 식별해야한다.
issuer
속성에 대한 관련 메타 데이터가 검증자에게 제공 될 것으로 예상된다.
예를 들어, 발급자는 발급 한 검증가능한 크리덴셜을 디지털 서명하는 데 사용하는 공개 키가
포함 된 정보를 게시 할 수 있다. 이 메타 데이터는 검증가능한 크리덴셜에서 증명을 확인할 때 관련이 있다.
issuanceDate
는 검증자의 예상 범위 내에 있어야한다.
예를 들어, 검증자는 검증가능한 크리덴셜의 발급 날짜가 미래에 있지 않은지 확인할 수 있다.
검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 정보가 변조되지 않았음을 증명하는 데 사용되는 암호화 메커니즘을 증명이라고 하자. 디지털 서명, 영지식 증명, 작업증명, 지분증명 등을 포함하는 다양한 유형의 암호화 증명이 있다. 일반적으로 증명을 검증할 때, 구현시 다음을 보장해야 한다:
어떤 증명은 디지털 서명이다. 일반적으로 디지털 서명을 검증할 때, 구현시 다음을 보장해야 한다:
proofPurpose
속성을
필요로 한다면
해당 속성은 존재해야 하고 assertionMethod
와 같은
유효한 값이어야 한다.
디지털 서명은 위변조 방지 외에도 여러가지 보호 기능을 제공한다.
예를 들어 연결된 데이터 서명 created
속성은
크리덴셜이
아직 검증된 상태가 아닌 것으로
간주되어야 할 날짜와 시간을 설정한다. The verificationMethod
속성속성은 디지털 서명을 확인하는데 사용될 수 있는 공개키를 지정한다.
공개키 URL을 참조 해제하면 키의 컨트롤러에 대한 정보가 표시되며,
이 정보는 크리덴셜 발급자에 대해 확인할 수 있다.
proofPurpose
속성은 증명 목적을 명확하게 표현하고, 이 정보가 서명으로
보호되도록 보장한다. 일반적으로 증명은 인증 목적으로
검증가능한 프레젠테이션에 첨부되거나
인증 보장의 방법으로써 검증가능한 크리덴셜에
첨부된다.
expirationDate
은 검증자의 예상
범위 안에
있어야 한다. 예를 들어 검증자는 검증가능한 크리덴셜의
만료 날짜가 과거 날짜가 아닌지 확인할 수 있다.
credentialStatus
이 사용 가능한 경우, 검증가능한 크리덴셜의 상태는 검증가능한
크리덴셜에 대한 credentialStatus
타입 정의 및
검증자의
평가 기준에 따라 검증자에
의해 평가되어야 한다. 예를 들어, 검증자는 검증가능한 크리덴셜의 상태가 "발급자에 의해 취소됨"이
아니라는 것을 보장할 수 있다.
목적 적합성은 검증가능한 크리덴셜의
사용자 지정 속성이 검증자의 목적에 적합한지
여부이다. 예를 들어 주체가 21세 이상인지 검증자가 확인해야 하는 경우
지정된 birthdate
속성 또는
ageOver
와 같은
보다 추상적인 속성에 의존할 수 있다.
발급자는 즉시 클레임을 생성할 수 있도록 검증자로부터 신뢰를 얻는다. 예를 들어, 프랜차이즈 패스트푸드 식당 위치는 프랜차이즈 본사에서 만든 항린 쿠폰 클레임을 신뢰한다. 발급자가 검증가능한 크리덴셜에 표현한 정책 정보는, 정책에 위배되는 책임을 용인하지 않는 한 보유자와 검증자에 의해 존중되어야 한다.
https://www.w3.org/2018/credentials/v1
에 있고 SHA-256 다이제스트
ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc
를 갖는 기본 컨텍스트는 로컬 캐시
복사본을 구현하는데 사용될 수 있다. 편의상 이번 장에서는 기본 컨텍스트가 함께 제공한다.
{ "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "VerifiableCredential": { "@id": "https://www.w3.org/2018/credentials#VerifiableCredential", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "cred": "https://www.w3.org/2018/credentials#", "sec": "https://w3id.org/security#", "xsd": "http://www.w3.org/2001/XMLSchema#", "credentialSchema": { "@id": "cred:credentialSchema", "@type": "@id", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "cred": "https://www.w3.org/2018/credentials#", "JsonSchemaValidator2018": "cred:JsonSchemaValidator2018" } }, "credentialStatus": {"@id": "cred:credentialStatus", "@type": "@id"}, "credentialSubject": {"@id": "cred:credentialSubject", "@type": "@id"}, "evidence": {"@id": "cred:evidence", "@type": "@id"}, "expirationDate": {"@id": "cred:expirationDate", "@type": "xsd:dateTime"}, "holder": {"@id": "cred:holder", "@type": "@id"}, "issued": {"@id": "cred:issued", "@type": "xsd:dateTime"}, "issuer": {"@id": "cred:issuer", "@type": "@id"}, "issuanceDate": {"@id": "cred:issuanceDate", "@type": "xsd:dateTime"}, "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"}, "refreshService": { "@id": "cred:refreshService", "@type": "@id", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "cred": "https://www.w3.org/2018/credentials#", "ManualRefreshService2018": "cred:ManualRefreshService2018" } }, "termsOfUse": {"@id": "cred:termsOfUse", "@type": "@id"}, "validFrom": {"@id": "cred:validFrom", "@type": "xsd:dateTime"}, "validUntil": {"@id": "cred:validUntil", "@type": "xsd:dateTime"} } }, "VerifiablePresentation": { "@id": "https://www.w3.org/2018/credentials#VerifiablePresentation", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "cred": "https://www.w3.org/2018/credentials#", "sec": "https://w3id.org/security#", "holder": {"@id": "cred:holder", "@type": "@id"}, "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"}, "verifiableCredential": {"@id": "cred:verifiableCredential", "@type": "@id", "@container": "@graph"} } }, "EcdsaSecp256k1Signature2019": { "@id": "https://w3id.org/security#EcdsaSecp256k1Signature2019", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "xsd": "http://www.w3.org/2001/XMLSchema#", "challenge": "sec:challenge", "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"}, "domain": "sec:domain", "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"}, "jws": "sec:jws", "nonce": "sec:nonce", "proofPurpose": { "@id": "sec:proofPurpose", "@type": "@vocab", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"}, "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"} } }, "proofValue": "sec:proofValue", "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"} } }, "EcdsaSecp256r1Signature2019": { "@id": "https://w3id.org/security#EcdsaSecp256r1Signature2019", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "xsd": "http://www.w3.org/2001/XMLSchema#", "challenge": "sec:challenge", "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"}, "domain": "sec:domain", "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"}, "jws": "sec:jws", "nonce": "sec:nonce", "proofPurpose": { "@id": "sec:proofPurpose", "@type": "@vocab", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"}, "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"} } }, "proofValue": "sec:proofValue", "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"} } }, "Ed25519Signature2018": { "@id": "https://w3id.org/security#Ed25519Signature2018", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "xsd": "http://www.w3.org/2001/XMLSchema#", "challenge": "sec:challenge", "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"}, "domain": "sec:domain", "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"}, "jws": "sec:jws", "nonce": "sec:nonce", "proofPurpose": { "@id": "sec:proofPurpose", "@type": "@vocab", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"}, "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"} } }, "proofValue": "sec:proofValue", "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"} } }, "RsaSignature2018": { "@id": "https://w3id.org/security#RsaSignature2018", "@context": { "@version": 1.1, "@protected": true, "challenge": "sec:challenge", "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"}, "domain": "sec:domain", "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"}, "jws": "sec:jws", "nonce": "sec:nonce", "proofPurpose": { "@id": "sec:proofPurpose", "@type": "@vocab", "@context": { "@version": 1.1, "@protected": true, "id": "@id", "type": "@type", "sec": "https://w3id.org/security#", "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"}, "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"} } }, "proofValue": "sec:proofValue", "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"} } }, "proof": {"@id": "https://w3id.org/security#proof", "@type": "@id", "@container": "@graph"} } }
이 섹션에서는 주체와 보유자 간의 성립 가능한 관계와 검증가능한 크리덴셜 데이터 모델이 이러한 관계를 어떻게 표현하는지 설명한다. 다음 다이어그램은 이러한 관계를 보여주며, 다음 섹션에서는 이 관계가 데이터 모델에서 처리되는 방식을 설명한다.
가장 일반적인 관계는 주체가 보유자인 경우이다. 이 경우에 만약 검증가능한 프레젠테이션이 보유자에 의해 디지털 서명 되어있고, 포함된 모든 검증가능한 크리덴셜이 보유자와 동일한 것으로 식별되는 주체에 관한 것이라면 검증자는 그 주체가 보유자라고 쉽게 추론할 수 있다.
만약 credentialSubject
만이 검증가능한 크리덴셜을 검증가능한 프레젠테이션에 삽입할 수 있는 경우,
발급자는
아래에 설명된대로 검증가능한 크리덴셜에
nonTransferable
속성을 삽입할 수 있다.
nonTransferable
속성은
검증가능한 크리덴셜을
credentialSubject
의해 발행된 증명을 가진 검증가능한 프레젠테이션에만 캡슐화해야 함을 나타낸다.
nonTransferable
속성이 없고 증명작성자가 credentialSubject
가 아닌
검증가능한 크리덴셜을 포함하는 검증가능한 프레젠테이션은 유효하지 않다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "ProofOfAgeCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "ageOver": 21 }, "nonTransferable": "True", "proof": { .. "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21", ... } }
이 경우 credentialSubject
속성은 주체의 여러 측면을 설명하는
다수의 속성이 포함될 수 있으며
그주체를 명확하게 식별하기 위해 결합된다. 일부 활용 사례는 의사(주체)가 보드-인증을 받았는지 확인하는 것과 같이
보유자를 전혀 식별하지 않을 수 있다.
다른 사용 사례에서는 검증자가 주체와 보유자사이의 관계를 결정하기 위해 범위 밖 지식을 사용해야 할 수 있다.
{
"@context": ["https://www.w3.org/2018/credentials/v1", "https://schema.org/"]
"id": "http://example.edu/credentials/332",
"type": ["VerifiableCredential", "IdentityCredential"],
"issuer": "https://example.edu/issuers/4",
"issuanceDate": "2017-02-24T19:73:24Z",
"credentialSubject": {
"name": "J. Doe",
"address": {
"streetAddress": "10 Rue de Chose",
"postalCode": "98052",
"addressLocality": "Paris",
"addressCountry": "FR"
},
"birthDate": "1989-03-15"
...
},
"proof": { ... }
}
위의 예는 개인의 이름, 주소, 생년월일을 이용하여주체를 고유하게 식별한다.
일반적으로 검증가능한 크리덴셜은 주체에 의하여 검증자에게 제공된다. 그러나, 경우에 따라서, 주체는 다른 보유자에게 검증가능한 크리덴셜의 전체 또는 일부를 전달해야 할지도 모른다. 예를 들어, 만약 환자 (주체) 너무 아파서 약사 (검증자)에게 처방전 (검증가능한 크리덴셜)을 받을 수 없는 경우, 그의 친구가 약을 수령하기 위해 처방전을 가져갈 수도 있다.
데이터 모델은 주체가 새로운검증가능한 크리덴셜을 발급하여 새로운 보유자에게 전달하고, 새로운 보유자는 두 개의 검증가능한 크리덴셜을 검증자에게 제시할 수 있도록 함으로써 이를 가능하게 한다. 하지만, 두 번째 검증가능한 크리덴셜의 내용은 어플리케에션별로 다를 수 있으며, 이 규격은 두 번째 검증가능한 크리덴셜의 내용을 표준화할 수 없다. 그럼에도 불구하고, 비표준적인 예가 수록되어 있다. .
‘검증가능한 크리덴셜 데이터 모델’은 최소한 다음과 같은 방법으로주체를 대신하여 보유자를 지원한다.
credentialSubject
속성에 보유자와
주체 사이의 관계를 포함할 수 있다.
위에 열거된 매커니즘은 보유자와 주체 사이의 관계를 설명하고, 검증자가 주어진 사용 사례에서 충분히 표현되는지 여부를 결정하도록 돕는다.
발급자 혹은 검증자가 주체와 보유자 사이의 검증하기 위해 사용하는 추가적인 매커니즘은 이 규격의 범위를 벗어난다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "AgeCredential", "RelationshipCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "ageUnder": 16, "parent": { "id": "did:example:ebfeb1c276e12ec211f712ebc6f", "type": "Mother" } }, "proof": { ... } // the proof is generated by the DMV }
위의 예에서, 발급자는 검증자가 크리덴셜을 아이 혹은 부모가 제공하는 경우에 가장 쉽게 수락할 수 있도록 아이와 부모 사이의 관계를 표현한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "RelationshipCredential"], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1c276e12ec211f712ebc6f", "child": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "Child" } }, "proof": { ... } // the proof is generated by the DMV }
위의 예에서, 발급자는 검증자가 아이에 의해 제공된 크리덴셜 혹은 위의 크리덴셜이 함께 제공된 아이의 크리덴셜을 대부분을 수락할 수 있도록 아이와 부모 사이의 관계를 별도의 크리덴셜로 표현한다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.org/credentials/23894", "type": ["VerifiableCredential", "RelationshipCredential"], "issuer": "http://example.org/credentials/23894", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "parent": { "id": "did:example:ebfeb1c276e12ec211f712ebc6f", "type": "Mother" } }, "proof": { ... } // the proof is generated by the child }
위의 예에서, 아이는 검증자가 위의 크리덴셜이 제공될 경우 아이의 크리덴셜을 가장 잘 받아들여질 수 있도록 아이와 부모 사이의 관계를 별도의 크리덴셜로 표현한다.
마찬가지로, 위에 예시에서 묘사된 전략은 대리인의 권한, 애완동물에 소유권 및 환자 처방전 대리수령(pick up)을 포함한 사용 사례의 많은 다른 종류를 위해 사용될 수 있다.
주체가 다른 보유자에게 검증가능한 크리덴셜을 전달하면, 그주체는 새로운 검증가능한 크리덴셜을 다음 사항이 적용되는보유자에게 발급할 수 있다.
보유자는 두 개의검증가능한 크리덴셜을 포함하는 새로운 검증가능한 프레젠테이션을 생성하여 검증자는 주체가 기존의 보유자에게 원본 검증가능한 크리덴셜을 부여했는지를 검증할 수 있다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2", "type": ["VerifiablePresentation"], "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.gov/credentials/3732", "type": ["VerifiableCredential", "PrescriptionCredential"], "issuer": "https://example.edu", "issuanceDate": "2010-01-01T19:73:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "prescription": {....} }, "revocation": { "id": "http://example.gov/revocations/738", "type": "SimpleRevocationList2017" }, "proof": {....} }, { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "https://example.com/VC/123456789", "type": ["VerifiableCredential", "PrescriptionCredential"], "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21", "issuanceDate": "2010-01-03T19:73:24Z", "credentialSubject": { "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2", "prescription": {....} }, "proof": { "type": "RsaSignature2018", "created": "2018-06-17T10:03:48Z", "proofPurpose": "assertionMethod", "jws": "pYw8XNi1..Cky6Ed=", "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234" } } ], "proof": [{ "type": "RsaSignature2018", "created": "2018-06-18T21:19:10Z", "proofPurpose": "authentication", "verificationMethod": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2", "challenge": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e", "jws": "BavEll0/I1..W3JT24=" }] }
위에 예시에서, 환자 (기존의 주체)가 친구에게 처방전(기존의 검증가능한 크리덴셜)을 전달했고 친구에게 새로운검증가능한 크리덴셜을 발급했고 친구가 주체인 경우, 기존의 검증가능한 크리덴셜의 주체는 발급자이며 그크리덴셜은 기존 처방전의 사본이다.
발급자가 보유자가 아닌 주체로 설명하는 크리덴셜을 보유자에게 부여하고 보유자는 주체와 알려진 관계가 없는 경우, 그리고 나서 발급자는 주체의 크리덴셜에 보유자의 관계를 삽입할 수 있다.
검증가능한 크리덴셜은 인증 프레임워크가 아니므로, 위임은 이 규격 범위를 벗어난다. 단, 검증가능한 크리덴셜이 인증과 위임시스템을 구축하기위해 사용될 가능성을 있는 것으로 이해된다. 다음은 일부 사용 사례에 적합할 수 있는 한 가지 접근법이다.
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "NameAndAddress"], "issuer": "https://example.edu/issuers/14", "holder": { "type": "LawEnforcement", "id": "did:example:ebfeb1276e12ec21f712ebc6f1c" }, "issuanceDate": "2010-01-01T19:73:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "name": "Mr John Doe", "address": "10 Some Street, Anytown, ThisLocal, Country X" }, "proof": { "type": "RsaSignature2018", "created": "2018-06-17T10:03:48Z", "proofPurpose": "assertionMethod", "verificationMethod": "https://example.edu/issuers/14/keys/234", "jws": "pY9...Cky6Ed = " } }
검증가능한 크리덴셜 데이터 모델은 이런 시나리오를 지원하지 않는다. 어떻게 지원할 수 있는지에 대해서는 추가적인 연구가 필요하다.
이 섹션은 검토, 승인, IANA의 “JSON Web Token Claims Registry” 등록을 위하여 인터넷 엔지니어링 스티어링 그룹(Internet Engineering Steering Group, IESG)에 제출될 것이다.
The Working Group would like to thank the following individuals for reviewing and providing feedback on the specification (in alphabetical order):
Christopher Allen, David Ammouial, Joe Andrieu, Bohdan Andriyiv, Ganesh Annan, Kazuyuki Ashimura, Tim Bouma, Pelle Braendgaard, Dan Brickley, Allen Brown, Jeff Burdges, Daniel Burnett, ckennedy422, David Chadwick, Chaoxinhu, Kim (Hamilton) Duffy, Lautaro Dragan, enuoCM, Ken Ebert, Eric Elliott, William Entriken, David Ezell, Nathan George, Reto Gmür, Ryan Grant, glauserr, Adrian Gropper, Joel Gustafson, Amy Guy, Lovesh Harchandani, Daniel Hardman, Dominique Hazael-Massieux, Jonathan Holt, David Hyland-Wood, Iso5786, Renato Iannella, Richard Ishida, Ian Jacobs, Anil John, Tom Jones, Rieks Joosten, Gregg Kellogg, Kevin, Eric Korb, David I. Lehn, Michael Lodder, Dave Longley, Christian Lundkvist, Jim Masloski, Pat McBennett, Adam C. Migus, Liam Missin, Alexander Mühle, Anthony Nadalin, Clare Nelson, Mircea Nistor, Grant Noble, Darrell O'Donnell, Nate Otto, Matt Peterson, Addison Phillips, Eric Prud'hommeaux, Liam Quin, Rajesh Rathnam, Drummond Reed, Yancy Ribbens, Justin Richer, Evstifeev Roman, RorschachRev, Steven Rowat, Pete Rowley, Markus Sabadello, Kristijan Sedlak, Tzviya Seigman, Reza Soltani, Manu Sporny, Orie Steele, Matt Stone, Oliver Terbu, Ted Thibodeau Jr, John Tibbetts, Mike Varley, Richard Varn, Heather Vescent, Christopher Lemmer Webber, Benjamin Young, Kaliya Young, Dmitri Zagidulin, and Brent Zundel.