검증 가능한 자격 증명은 운전면허증이나 교육 증명서와 같이
클레임
집합을 표현하는 특정한 방식입니다. 이
클레임은 발급자가 제기합니다. 이
명세는 검증 가능한 자격 증명을 위한 확장 가능한 데이터 모델,
변조로부터 이를 보호하는 방법, 그리고 발급자, 보유자,
및 검증자로 구성된 이러한 자격 증명의 교환을 위한 삼자 생태계를
설명합니다. 이 문서는 또한 이 명세에서 설명하는 기술을
사용하는 생태계를 위한 다양한 보안, 개인정보 보호,
국제화 및 접근성 고려 사항을 다룹니다.
이 문서의 상태
이 절은 이 문서가
발행된 시점의 상태를 설명합니다. 현재 W3C
발행물 목록과 이 기술 보고서의 최신 개정판은
https://www.w3.org/TR/의
W3C 표준 및 초안
색인에서
확인할 수 있습니다.
W3C 권고안은 광범위한 합의 형성 이후
W3C와 그 회원들이 승인하고,
워킹 그룹 구성원이 구현을 위한
로열티 없는 라이선스
제공을 약속한 명세입니다.
이 문서는
W3C
특허
정책에 따라 운영되는
그룹에 의해 작성되었습니다.
W3C는
해당 그룹의 산출물과 관련하여 이루어진
모든 특허 공개의 공개 목록을
유지합니다. 이 페이지에는
특허 공개 지침도 포함되어 있습니다. 개인이
필수 청구항을 포함한다고
믿는 특허에 대해 실제 지식을 가지고 있는 경우,
그 개인은 W3C 특허 정책 제6절에 따라
해당 정보를 공개해야 합니다.
자격 증명은 우리의 일상생활에 필수적입니다. 운전면허증은
우리가 자동차를 운전할 수 있음을 확인하고, 대학 학위는 우리의 교육
수준을 나타내며, 정부가 발급한 여권은 국가 간
여행 시 우리의 시민권을 증명합니다. 이 명세는 이러한 종류의 자격 증명을 웹에서
암호학적으로 안전하고, 개인정보 보호를 존중하며, 기계가 검증할 수 있는 방식으로
표현하기 위한 메커니즘을 제공합니다. 이러한
자격 증명은 물리적 세계에서 사용될 때 우리에게 이점을 제공하지만,
웹에서의 사용은 여전히 실현하기 어렵습니다.
현재 교육 자격, 의료
데이터, 금융 계좌 세부 정보 및 기타 제3자가 검증한
개인 정보를 웹에서 기계가 읽을 수 있는 방식으로 표현하기는 어렵습니다. 웹에서 디지털
자격 증명을 표현하는 문제는 물리적 자격 증명이
현실 세계에서 제공하는 것과 동일한 이점을 얻는 능력을 저해합니다.
검증 가능한 자격 증명과 관련된 개념에 익숙하지 않은 사람들을 위해,
다음 절에서는 다음 사항의 개요를 제공합니다.
이 명세는 디지털
자격 증명을 표현하는 편의성을 개선하려고 시도하는 동시에, 이 목표와 여러
개인정보 보호 목표의 균형을 맞추는 것을 목표로 합니다. 디지털 정보의 지속성과,
서로 다른 디지털 데이터 소스를 수집하고 상관시킬 수 있는 용이성은,
검증
가능한 그리고 쉽게
기계가 읽을 수 있는 자격 증명의 사용이 악화시킬 위험이 있는 개인정보 보호 문제를 구성합니다. 이 문서는
8. 개인정보 보호 고려 사항 절에서 이러한 문제 중 여러 가지를
개괄하고 해결하려고 시도합니다. 영지식 증명과 같은 개인정보 보호 강화 기술을
사용하여 이 데이터 모델을 사용하는 방법의 예도
이 문서 전반에 제공됩니다.
검증 가능한 자격 증명 및
검증 가능한 프레젠테이션이라는 용어에서 "검증 가능한"이라는 말은
자격 증명 또는 프레젠테이션이 이 문서에서 정의한
바와 같이 검증자에 의해 검증될 수 있는 특성을 가리킵니다.
자격 증명의 검증 가능성이 그 안에 인코딩된 클레임의 진실성을 의미하지는 않습니다. 대신,
검증 가능한 자격 증명 또는
검증 가능한 프레젠테이션의 진정성과 최신성을 확인한 뒤, 검증자는 이에 의존하기 전에
자체 비즈니스 규칙을 사용하여 포함된 클레임을 검증합니다.
그러한 의존은 발급자, 증명, 주체 및 클레임을 하나 이상의
검증자 정책에 따라 평가한 후에만 이루어집니다.
1.2 생태계 개요
이 절은 비규범적입니다.
이 절은 검증 가능한 자격 증명이
유용할 것으로 기대되는 생태계에서 핵심 행위자의 역할과 그들 사이의 관계를
설명합니다. 역할은 여러
다른 방식으로 구현될 수 있는 추상화입니다. 역할의 분리는
표준화를 위한 가능한 인터페이스와
프로토콜을 시사합니다. 이 명세는 다음
역할을 도입합니다.
하나 이상의
주체에 대한 클레임을 주장하고, 이러한 클레임으로부터 검증 가능한 자격 증명을 생성하며,
그 검증 가능한 자격 증명을 보유자에게 전송함으로써 엔터티가 수행할 수 있는 역할입니다. 예를 들어 발급자에는
기업, 비영리 조직, 업계 단체, 정부
및 개인이 포함됩니다.
식별자, 검증 자료 및
검증 가능한 자격 증명 스키마, 폐기
레지스트리 등과 같은 기타 관련 데이터의 생성 및 검증을 중개함으로써
시스템이 수행할 수 있는 역할이며, 이에는 검증 가능한 자격 증명의 사용이 필요할 수 있습니다.
일부
구성에서는 주체에 대해 상관 가능한 식별자가 필요할 수 있습니다. UUID와 검증 자료용 레지스트리와 같은 일부 레지스트리는
식별자를 위한 네임스페이스 역할만 할 수도 있습니다.
검증 가능한 데이터 레지스트리의 예로는 신뢰할 수 있는 데이터베이스,
탈중앙화 데이터베이스, 정부 ID 데이터베이스 및 분산 원장이 있습니다. 생태계에서는 대개
둘 이상의 유형의 검증 가능한 데이터 레지스트리가 사용됩니다.
위의 그림 1은 이 명세의 나머지 개념을 설명하기 위한
예시 생태계를 제공합니다. 보호된 환경이나 독점 시스템과 같은
다른 생태계도 존재하며, 그러한 곳에서도
검증 가능한 자격 증명은 이점을 제공합니다.
이 생태계는 일반적인 양자 간 또는 연합 신원
제공자 모델과 대조됩니다. 신원 제공자는 때때로 IdP로
약칭되며, 연합 또는 분산 네트워크 내의 의존 당사자
애플리케이션에 인증 서비스를 제공하면서 보유자의 신원 정보를 생성, 유지 및 관리하는 시스템입니다.
연합 신원 모델에서는 보유자가 신원 제공자에 강하게 결합됩니다.
이 명세는 이러한 개념을 다른 명세와 비교하거나 매핑할 때를 제외하고
"신원 제공자", "연합 신원" 또는
"의존 당사자" 용어를 사용하지 않습니다. 이 명세는 신원 제공자
개념을 두 가지 별개의 개념인 발급자와 보유자로 분리합니다.
비규범적이라고 표시된 절뿐만 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예시 및 참고는
비규범적입니다. 이 명세의 그 밖의 모든 것은 규범적입니다.
이 문서의 핵심 단어 MAY, MUST, MUST
NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, 및 SHOULD
NOT은
여기 표시된 것처럼 모두 대문자로 나타날 때, 그리고 오직 그 경우에만
BCP 14
[RFC2119] [RFC8174]에
설명된 대로 해석되어야 합니다.
적합 문서는 이
명세의 모든 관련 "MUST" 문장을 준수하는
압축된 JSON-LD
문서입니다. 구체적으로, 이 문서의 4. 기본 개념, 5. 고급
개념, 및
6.
구문 절의 관련 규범적 "MUST" 문장은 강제되어야 합니다.
적합 문서는 미디어 타입이 application/vc인 검증
가능한 자격 증명
또는 미디어 타입이 application/vp인 검증 가능한 프레젠테이션이어야 합니다. 적합 문서는
4.12 보안 메커니즘 절에 설명된 대로
적어도 하나의 보안 메커니즘으로 보호되어야 합니다.
적합
발급자 구현은
적합 문서를 생성하고, 생성하는
적합 문서에 모든 필수 속성을 포함해야 하며, 생성하는 적합 문서를
4.12 보안 메커니즘 절에 설명된 보안
메커니즘을 사용하여 보호해야 합니다.
적합 검증자 구현은
적합 문서를 소비하고,
적합 문서에 대해
4.12 보안 메커니즘 절에 설명된 대로 검증을 수행해야 하며, 각
필수 속성이 해당 속성에 대한 규범적 요구 사항을 만족하는지 확인해야 하고,
비적합 문서가 감지될 때 오류를 생성해야 합니다.
이 명세에는 필수 속성과 선택 속성이 모두 포함됩니다. 선택
속성은 적합 발급자 구현 및
적합 검증자 구현에 의해
무시될 수 있습니다.
이 문서에는 인라인 주석(//) 및 예시에 거의 가치를 더하지 않는 정보를
나타내기 위한 생략 부호
(...)의 사용과 같이 유효하지 않은 JSON 문자를 포함하는 예시도 들어 있습니다.
구현자는 이 정보를 유효한 문서로 사용하려는 경우 해당 내용을 제거해야 함을
유의해야 합니다.
참고: 영어의 사람이 읽을 수 있는 텍스트는 예시임
이 문서 전반에 제공된 예시에는 각
명세 예시의 개념을 단순화하기 위해 name 및 description과 같은
설명 속성이 영어 값으로 포함되어 있습니다. 이러한 예시는 반드시 국제적 사용에
필요한 데이터 구조를 반영하는 것은 아니며, 이는
11. 국제화 고려 사항 절에서 더 자세히 설명합니다.
발급자가 제기한 하나 이상의 클레임 집합입니다. 자격 증명 안의
클레임은
서로 다른 주체에 관한 것일 수 있습니다. 이 명세에서
사용되는 자격 증명의 정의는
NIST의
자격 증명 정의와 다릅니다.
분산
식별자
DID라고도 알려진 이식 가능한 URL 기반 식별자로,
엔터티와 연결됩니다. 이러한 식별자는 가장 흔히
검증 가능한 자격 증명에서 사용되며, 주체와 연결되어
검증 가능한 자격 증명을 다시 발급하지 않고도 하나의
자격 증명 저장소에서 다른 저장소로 쉽게 이식할 수 있게 합니다.
DID의 예는 did:example:123456abcdef입니다. 자세한 내용은
분산 식별자
(DID) v1.0 명세를 참조하십시오.
추상적이거나 구체적인 명사로 문장에서 참조될 수 있는 모든 것입니다.
엔터티에는 사람, 조직, 물리적 사물,
문서, 추상 개념, 허구의 인물, 임의의 텍스트 등이 포함되지만 이에
한정되지는 않습니다. 어떤 엔터티든 그렇게 할 수 있다면 생태계에서 역할을
수행할 수 있습니다. 일부 엔터티는 본질적으로 행동을 취할 수 없다는 점에 유의하십시오.
예를 들어 문자열 "abc"는 자격 증명을 발급할 수 없습니다.
그래프
주체와 다른 주체 또는 데이터와의
관계로 구성된 정보 네트워크를 형성하는 클레임 집합입니다. 각 클레임은
그래프의 일부입니다. 명명된 그래프의 경우에는
명시적이고, 기본 그래프의 경우에는 암시적입니다.
특정 발급자의 클레임이 특정 용도에 대한
검증자의 비즈니스 요구 사항을 만족한다는 보장입니다. 이 명세는
검증자가 검증 가능한 자격 증명과 검증 가능한 프레젠테이션을 검증하는 방법을 정의합니다. 또한 검증자가 이에 의존하기 전에
검증 가능한 자격 증명 안의 클레임을
유효성 확인해야 한다고 명시합니다.
그러나 그러한 유효성 확인의 수단은 매우 다양하며 이 명세의 범위를 벗어납니다.
검증자는 특정 클레임에 대해 특정 발급자를 신뢰하고,
어떤 자격 증명 안의 어떤 클레임이
자신의 시스템에서 사용하기에 적합한지를 판단하기 위해 자체
규칙을 적용합니다.
검증 가능한 자격 증명
작성자를 암호학적으로 검증할 수 있는, 변조가 드러나는 자격 증명입니다. 검증 가능한 자격 증명은
검증 가능한 프레젠테이션을 만드는 데 사용할 수 있으며, 이 역시
암호학적으로 검증 가능할 수 있습니다.
검증 가능한
데이터 레지스트리
식별자, 검증 자료 및
검증 가능한 자격 증명 스키마, 폐기 레지스트리
등과 같은 기타 관련 데이터의 생성 및 검증을
중개함으로써 시스템이 수행할 수 있는 역할이며, 이에는 검증 가능한 자격 증명의 사용이 필요할 수 있습니다. 일부
구성에서는 주체에 대해 상관 가능한 식별자가 필요할 수 있습니다. UUID 및
검증 자료용 레지스트리와 같은 일부
레지스트리는 식별자를 위한 네임스페이스 역할을 할 수 있습니다.
검증 가능한
프레젠테이션
암호학적 검증 과정을 거친 뒤 데이터의 작성자를 신뢰할 수 있도록
인코딩된, 변조가 드러나는 정보의 프레젠테이션입니다.
특정 유형의 검증 가능한 프레젠테이션은 원본
검증 가능한 자격 증명에서 합성되었지만 이를 포함하지는 않는
데이터(예: 영지식 증명)를 포함할 수 있습니다.
검증
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션이 각각 발급자 또는 제시자의 진정하고 최신인
진술인지 평가하는 것입니다. 여기에는 자격 증명 또는 프레젠테이션이
명세에 적합한지, 보안 메커니즘이 충족되는지, 그리고 상태 검사가
있는 경우 성공하는지를 확인하는 일이 포함됩니다. 자격 증명의 검증은
그 자격 증명에 인코딩된 클레임의 진실성을 평가한다는 의미가 아닙니다.
검증자
처리를 위해 선택적으로
검증 가능한 프레젠테이션 안에 포함된 하나 이상의
검증 가능한 자격 증명을 수신함으로써
엔터티가 수행하는 역할입니다. 다른 명세에서는
이 개념을 의존 당사자라고 부를 수 있습니다.
검증 자료
암호학적으로 보호된 정보의 보안을 검증하는 데 사용되는 정보입니다.
예를 들어 암호학적 공개 키는 검증 가능한 자격 증명과 연결된 디지털 서명을 검증하는 데
사용됩니다.
URL
URL 표준에서 정의한
Uniform Resource Locator입니다. URL은
역참조되어 문서와 같은 리소스를 생성할 수 있습니다. URL을
역참조하거나 가져오는 규칙은 URL scheme에 의해 정의됩니다.
이 명세는 URI 또는 IRI라는 용어를 사용하지 않습니다. 이러한 용어는
웹 개발자에게 혼란을 주는 것으로 여겨졌기 때문입니다.
여기까지 클레임과 정보
그래프의 개념이 소개되었습니다.
클레임을 신뢰할 수 있으려면 더 많은 정보가
그래프에 추가될 것으로 예상되며, 더 많은 정보가 그래프에
추가될 것으로 예상됩니다.
3.2 자격 증명
이 절은 비규범적입니다.
자격 증명은 동일한 엔터티가 제기한 하나 이상의
클레임 집합입니다.
자격 증명에는 자격 증명의 속성을 설명하기 위한
식별자와 메타데이터가
포함될 수도 있습니다. 예를 들어 발급자, 유효 날짜 및
기간, 대표 이미지, 검증 자료, 상태
정보 등이 있습니다. 검증 가능한 자격 증명은 누가 이를 발급했는지를
암호학적으로 증명하는, 변조가 드러나는 클레임과 메타데이터의 집합입니다.
검증 가능한 자격 증명의 예에는 디지털 직원 신분증,
디지털 운전면허증, 디지털 교육 증명서 등이 포함되지만
이에 한정되지는 않습니다.
개인정보 보호 강화는 이 명세의 핵심 설계 특징입니다. 따라서 이 기술을 사용하는
엔터티가 주어진 상황에 적절한 자신의 페르소나 부분만을
표현하는 것은 매우 중요합니다. 자신의 페르소나의 하위 집합을 표현하는 것을
검증 가능한 프레젠테이션이라고 합니다.
서로 다른 페르소나의 예에는 개인의 직업적 페르소나,
온라인 게임 페르소나, 가족 페르소나 또는 익명 페르소나가 포함됩니다.
1.2 생태계 개요 절에서 설명한 것처럼, 엔터티는
특정 자격 증명 교환에 참여하면서 하나 이상의 역할을 맡을 수 있습니다.
일반적으로 보유자가 프레젠테이션을 생성할
것으로 기대되지만,
발급자 또는 검증자가
자신을 보유자에게 식별하기 위해 프레젠테이션을
생성할 수도 있습니다. 이는 보유자가
검증 가능한 프레젠테이션의 일부로
민감한 정보를 넘기기 전에 발급자 또는 검증자로부터
더 높은 보증이 필요한 경우 발생할 수 있습니다.
4. 기본 개념
이 절에서는 문서의 뒤쪽에 있는
5. 고급 개념 절에 대비하여
이 명세의 몇 가지 기본 개념을 소개합니다.
4.1 시작하기
이 절은 비규범적입니다.
이 명세는 새로운 유형의
검증 가능한 자격 증명 프로토타입 작성을 쉽게 하도록 설계되었습니다.
개발자는 아래 템플릿을 복사하여 일반적인
검증 가능한 자격 증명 도구에 붙여 넣어 프로토타입 자격 증명의 발급,
보유 및
검증을 시작할 수 있습니다.
개발자는 아래의 MyPrototypeCredential을 만들고자 하는 자격 증명
유형으로 변경하게 됩니다. 검증 가능한 자격 증명은
주체에 대해 말하므로,
credentialSubject 객체의 각 속성-값 쌍은 자격 증명 주체의
특정 속성을 표현합니다. 개발자가 이러한 속성-값 조합을
여러 개 추가한 후, 수정된 객체를
적합 발급자 구현으로 보낼 수 있으며, 그러면 개발자를 위한
검증 가능한 자격 증명이
생성됩니다. 프로토타입 작성 관점에서는 이것이
개발자가 해야 할 전부입니다.
모든 자격 증명 속성이 안정화된 후, 개발자는 다른 개발자와의
상호운용성을 촉진하기 위해 안정적인 URL에 어휘 및 컨텍스트 파일을
생성하고 게시하는 것이 좋습니다. 그러면 위의
https://www.w3.org/ns/credentials/examples/v2 URL은
사용 사례별 컨텍스트의 URL로 대체됩니다. 이
과정은 5.2 확장성 절에서 다룹니다. 또는
개발자는 자신의 사용 사례에 우연히 맞는 기존 어휘 및 컨텍스트 파일을
재사용할 수 있습니다. 재사용 가능한 리소스를 찾기 위해
검증 가능한 자격
증명 확장을
살펴볼 수 있습니다.
두 소프트웨어 시스템이 데이터를 교환해야 할 때, 두 시스템 모두가 이해하는
용어를 사용해야 합니다. 두 사람이 동일한 언어를 사용하여 효과적으로
의사소통하는 방식을 생각해 보십시오. 이때 그들이 사용하는 "name" 및
"website" 같은 단어는 각 개인에게 같은 의미를 가집니다. 이는 때때로
대화의 컨텍스트라고 불립니다. 이 명세는 소프트웨어 시스템이
의사소통할 수 있는 컨텍스트를 설정함으로써 비슷한 결과를 얻기 위해
유사한 개념을 사용합니다.
검증 가능한 자격 증명 및
검증 가능한 프레젠테이션을 처리하는 소프트웨어 시스템은
각 용어에 대해 URL을 사용하여 용어를 식별합니다. 그러나
이러한 URL은 길고 사람에게 친숙하지 않을 수 있으며, 짧고
사람이 읽기 쉬운 별칭이 더 유용할 수 있습니다. 이 명세는
@context속성을 사용하여 짧은 형식의 별칭을
URL에
매핑합니다.
검증 가능한 자격 증명 및 검증 가능한 프레젠테이션은
@context속성을 포함해야 MUST 합니다. 애플리케이션 개발자는 자신의 애플리케이션에서
사용하는 모든 JSON-LD
컨텍스트를, 적어도 그 애플리케이션에서 사용되는 용어의 의미에 영향을 미치는 범위까지는
이해해야 MUST 합니다. 이를 수행하는 한 가지 메커니즘은
검증
가능한 자격 증명 데이터 무결성
1.0 명세의
컨텍스트 검증 절에
설명되어 있습니다. 이 명세를 기반으로 하는 다른 명세는
5.3 관련 리소스의 무결성 절에 설명된
relatedResource 기능이나 실질적으로 동등한 메커니즘을 사용하여 JSON-LD 컨텍스트가 무결성
보호되도록 요구할 수 MAY 있습니다.
@context
@context속성의 값은
첫 번째 항목이 값
https://www.w3.org/ns/credentials/v2를 가진 URL인
순서 있는 집합이어야
MUST 합니다.
순서 있는 집합의 후속 항목은
각각이 JSON-LD Context로
처리 가능한
URL과 객체의 임의 조합으로 구성되어야
MUST 합니다.
위 예제는 기본 컨텍스트 URL
(https://www.w3.org/ns/credentials/v2)을 사용하여 데이터 교환이
검증 가능한 자격 증명에 관한 것임을 설정합니다. 이 개념은
5.2
확장성 절에서 더 자세히 설명됩니다.
https://www.w3.org/ns/credentials/v2에서 사용할 수 있는 데이터는
부록 B.1
기본 컨텍스트에 제공된 처리 지침을 가진 영구적으로 캐시 가능한 정적
문서입니다. 검증 가능한 자격 증명 데이터 모델에 대한 관련 사람이 읽을 수 있는
어휘 문서는
https://www.w3.org/2018/credentials/에서 사용할 수 있습니다.
두 번째 URL (https://www.w3.org/ns/credentials/examples/v2)은
예제를 보여주는 데 사용됩니다. 구현은 파일럿 또는 프로덕션 시스템과 같은
다른 어떤 목적으로도 이
URL을
사용하지 않을 것으로 기대됩니다.
사람, 제품 또는 조직과 같은 특정 대상에 관한 진술을 표현할 때,
그 대상에 대해 전역적으로 고유한 식별자를 사용하는 것이 유용할 수 있습니다.
전역적으로 고유한 식별자는 다른 사람이 동일한 대상에 관해 진술을
표현할 수 있게 합니다. 이 명세는 그러한 식별자를 위해 선택적
id속성을 정의합니다. id속성은
검증 가능한 자격 증명 안에서 특정 대상에 관한 진술을 표현할 수 있게 하며,
검증 가능한 자격 증명에서 객체를 표현할 때에는
발급자가, 검증 가능한 프레젠테이션에서 객체를 표현할 때에는
보유자가 설정합니다. id속성은
해당 식별자로 식별되는 특정 대상에 관한 진술을 표현할 때 다른 사람이 사용할 것으로
기대되는 식별자를 표현합니다. 예시 id 값에는
UUID(urn:uuid:0c07c1ce-57cb-41af-bef2-1b932b986873), HTTP URL
(https://id.example/things#123) 및 DID(did:example:1234abcd)가 포함됩니다.
참고: 어떤 종류의 식별자든 상관 가능성을 높임
개발자는 가명이 필요한 경우 식별자가 해로울 수 있음을 상기해야 합니다.
이러한 시나리오를 고려할 때, 개발자는
8.4
식별자 기반 상관관계 절을 주의 깊게 읽을 것이 권장됩니다.
개인정보 보호 문제를 만드는 다른 유형의 접근 및 상관 메커니즘도
8. 개인정보 보호 고려 사항 절에 문서화되어 있습니다.
개인정보 보호가 중요한 고려 사항인 경우
id속성을 생략하는 것이 허용됩니다. 일부 사용 사례는
id속성이 필요하지 않거나 명시적으로 생략해야 합니다.
마찬가지로 공개적으로 해석 가능한 URL과 다른 형태의 식별자 사이의 선택에
특별한 주의를 기울여야 합니다. 공개적으로 해석 가능한 URL은 검증과 상호운용성을
쉽게 할 수 있지만, 신중하게 사용하지 않으면 잠재적으로 민감한 정보에 대한 접근을
의도치 않게 허용할 수도 있습니다.
id
id속성은 OPTIONAL입니다. 존재하는 경우,
id속성의 값은
역참조 가능할 MAY 있는 단일
URL이어야
MUST 합니다. id의 URL은 역참조 가능한 경우
id에 관한 기계 판독 가능 정보를 포함하는 문서가 결과로 나오도록 하는 것이
RECOMMENDED됩니다.
이 문서에 지정된 종류의 객체를 처리하는 소프트웨어 시스템은 제공된
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션이 의도된 사용 사례에
적합한지 여부를 판단하기 위해 타입 정보를 사용합니다. 이 명세는 객체 타입 정보를 표현하기 위한
type속성을 정의합니다. 이 타입
정보는 부록
A.
유효성 확인에 설명된 것처럼
유효성 확인 과정에서 사용될 수 있습니다.
유효한 credentialSchema 타입. 예를 들면, "type": "JsonSchema"
참고: 검증 가능한 자격 증명 데이터 모델은 JSON-LD에 기반함
검증 가능한 자격 증명 데이터 모델의 타입 시스템은
JSON-LD
1.1의 타입 시스템과 동일하며,
3.5절:
타입 지정 및
9절: JSON-LD
문법에서 자세히 설명됩니다. JSON-LD 컨텍스트(5.2 확장성 절
참조)를 사용할 때, 이 명세는
JSON-LD 문서를 더 쉽게 이해할 수 있도록
@type 키워드를 type으로 별칭 지정합니다.
애플리케이션 개발자와 문서 작성자는 JSON-LD 타입 시스템의 세부 사항을
이해할 필요가 없지만, 상호운용 가능한 확장성을 지원하려는 이 명세의 구현자는
이를 이해해야 합니다.
모든 자격 증명, 프레젠테이션 및
캡슐화된 객체는 소프트웨어 시스템이 이 추가 정보를
더 쉽게 감지하고 처리할 수 있도록 추가적이고 더 좁은
타입
(예: ExampleDegreeCredential)을 지정하거나 이와 연결되어야
SHOULD 합니다.
이 명세에 정의된 캡슐화된 객체, 예를 들어 credentialSubject 객체와
관련되거나 그 안에 깊게 중첩된 객체를 처리할 때, 소프트웨어 시스템은 계층 구조상
더 높은 캡슐화 객체에 지정된 타입 정보를 사용해야
SHOULD 합니다. 구체적으로,
자격 증명과 같은 캡슐화 객체는 관련 객체의
타입을 전달하여
검증자가 캡슐화 객체
타입을 바탕으로 관련 객체의 내용을 빠르게 판단할 수 있게 해야
SHOULD 합니다.
예를 들어 type이 ExampleDegreeCredential인
자격 증명 객체는
검증자에게
credentialSubject 속성과 연결된 객체가 다음의 식별자를 포함한다는 신호를 보냅니다.
자격 증명을 표시할 때,
발급자가 제공한 텍스트가 있으면 유용할 수 있습니다. 이 텍스트는
자격 증명에 이름과 그 목적에 대한 짧은 설명을 제공합니다.
name 및 description속성은
이러한 목적을 수행합니다.
name
자격 증명의 이름을 표현하는
OPTIONAL 속성입니다. 존재하는 경우,
name속성의 값은 문자열 또는
11.1 언어와 기본 방향에 설명된
언어 값 객체여야 MUST 합니다. 이상적으로
자격 증명의 이름은 간결하고 사람이 읽을 수 있으며,
개인이 보유할 수 있는 다른 어떤 자격 증명과도
하나의 자격 증명을
빠르게 구별할 수 있게 해 줍니다.
description
자격 증명에 대한 구체적인 세부 사항을 전달하는
OPTIONAL 속성입니다. 존재하는 경우,
description속성의 값은
문자열 또는
11.1 언어와 기본 방향에 설명된
언어 값 객체여야 MUST 합니다. 이상적으로
자격 증명의 설명은 몇 문장 이내의 길이이며,
전체 클레임을
살펴보지 않고도 개인이 그 내용을 떠올릴 수 있을 만큼
자격 증명에 관한 충분한 정보를 전달합니다.
이름과 설명은 서로 다른 언어로 콘텐츠를 표현하는 것도 지원합니다.
언어 및 기본 방향
정보를 가진
문자열을 표현하려면, 각각 텍스트 값, 언어 태그 및 기본 방향을 표현하는
@value, @language, @direction
속성을 포함하는 객체를 사용할 수 있습니다. 자세한 내용은
11.1 언어와 기본 방향을 참조하십시오.
참고: 단일 언어 문자열에는 @direction이 필요하지 않음
아래 예제의 @direction 속성은 연결된 단일 언어 문자열에
필요하지 않습니다. 그 기본 방향이 @direction 값으로 설정된 방향과
동일하기 때문입니다. 여기서는 설명의 명확성을 위해, 그리고 복사+붙여넣기+수정이
작동하는 결과를 제공하도록 @direction 속성을 포함합니다.
구현자는 JSON-LD
1.1 명세의
문자열
국제화 절을 읽는 것이 권장됩니다.
issuer속성의 값은
URL이거나, 값이 URL인 id속성을
포함하는 객체여야 MUST 합니다. 어느 경우든
발급자는 전역적으로 모호하지 않은 방식으로 자신을 식별하기 위해 이
URL을 선택합니다. 이
URL은 역참조되는 경우
제어된 식별자
v1.0 명세에 정의된
제어된 식별자 문서가 결과로 나오는 것이
RECOMMENDED됩니다. 이 문서는
자격 증명에 표현된 정보를
검증하는 데 사용할 수 있는
발급자에 관한 것입니다.
credentialSubject속성의 값은 객체들의 집합이며,
각 객체는 하나 이상의 클레임의 주체여야 MUST 하며,
그 클레임은 credentialSubject속성 내부에
직렬화되어야 MUST 합니다. 각 객체는 또한
섹션 4.4 식별자에서 설명한 것처럼
주체를 식별하기 위한 id속성을 포함할 수 MAY 있습니다.
이 명세는 발급자가 자격 증명이 유효해지는 날짜와 시간을 표현하는 데
도움이 되는 validFrom속성과,
자격 증명이 더 이상 유효하지 않게 되는 날짜와 시간을 표현하는
validUntil속성을 정의합니다.
날짜와 시간을 비교할 때 계산은 "시간적으로" 수행됩니다. 이는 문자열 값이
타임라인의 한 지점으로 존재하는 "시간 값"으로 변환된다는 뜻입니다.
그런 다음 비교되는 날짜와 시간이 타임라인의 특정 지점과 관련하여
어디에 있는지 확인하여 시간 비교가 수행됩니다.
validFrom
존재하는 경우, validFrom속성의 값은
자격 증명이 유효해지는 날짜와 시간을 나타내는
[XMLSCHEMA11-2]
dateTimeStamp 문자열 값이어야 MUST 하며,
이는 미래 또는 과거의 날짜와 시간일 수 있습니다. 이 값은
credentialSubject속성과 연결된 정보가 유효해지는
가장 이른 시점을 나타냅니다. validUntil 값도 존재하는 경우,
validFrom 값은 validUntil 값이 표현하는 시점과 시간적으로 같거나
그보다 이른 시점을 표현해야 MUST 합니다.
validUntil
존재하는 경우, validUntil속성의 값은
자격 증명이 더 이상 유효하지 않게 되는 날짜와 시간을 나타내는
[XMLSCHEMA11-2]
dateTimeStamp 문자열 값이어야 MUST 하며,
이는 과거 또는 미래의 날짜와 시간일 수 있습니다. 이 값은
credentialSubject속성과 연결된 정보가 유효한
가장 늦은 시점을 나타냅니다. validFrom 값도 존재하는 경우,
validUntil 값은 validFrom 값이 표현하는 시점과 시간적으로 같거나
그보다 늦은 시점을 표현해야 MUST 합니다.
validFrom과 validUntil이 존재하지 않는 경우,
검증 가능한 자격 증명의 유효 기간은
무기한 유효한 것으로 간주됩니다. 이러한 경우, 검증 가능한 자격 증명은
verifiable credential이 생성된 시점부터 유효한 것으로 간주됩니다.
4.10 상태
이 명세는 검증 가능한 자격 증명의 상태와 관련된 정보,
예를 들어 그것이 일시 정지되었는지 또는 폐기되었는지를 발견하기 위한
credentialStatus속성을
정의합니다.
존재하는 경우, credentialStatus속성과 연결된 값은
단일 객체 또는 하나 이상의 객체 집합입니다. 다음 속성은
모든 객체에 대해 정의됩니다:
id
id속성은 OPTIONAL입니다. 이는
자격 증명 상태 객체에 대한 고유 식별자를 제공하는 데 사용될 수 MAY 있습니다. 존재하는 경우,
섹션 4.4 식별자의 규범적 지침을
따라야 MUST 합니다.
type
type속성은 REQUIRED입니다. 이는
객체가 표현하는 상태 정보의
타입을 표현하는 데 사용됩니다. 섹션 4.5 타입의 관련 규범적
지침을 따라야 MUST 합니다.
자격 증명 상태 정보의 정확한 내용은
특정 credentialStatus타입 정의에 의해 결정되며,
구현이 단순한지 또는 개인정보 보호를 강화하는지와 같은 요인에 따라
달라집니다. 값은 자격 증명의 현재 상태와, URL에서 기계 판독 가능한 정보를
검색할 수 있는지를 결정하기에 충분한 정보를 제공합니다. 예를 들어, 객체는
자격 증명이 일시 정지되었는지 또는 폐기되었는지를
기록하는 외부 문서에 대한 링크를 포함할 수 있습니다.
자격 증명 상태 명세는, 특정 보유자 또는 주체에
검증자가 관심을 가질 때 발급자에게
직접 또는 간접적으로 통지되는 것과 같은 개인 추적을 가능하게 해서는 MUST NOT
안 됩니다. 허용되지 않는 접근 방식에는, 자격 증명을 사용할 때마다 특정 개인의 상태를 확인하기 위해
자격 증명의 발급자에게 연락하는
"전화 홈" 방식이나, 자격 증명을 사용할 때마다 발급자에게 정보를 요청하게 하여
발급자가 특정 개인에 대한
검증자의 관심을 추론할 수 있게 하는
"가명성 감소" 방식이 포함됩니다.
4.11 데이터 스키마
데이터 스키마는 주어진 데이터 컬렉션에 특정 구조를 강제할 때 유용합니다.
이 명세가 고려하는 데이터 스키마에는 적어도 두 가지 타입이 있습니다:
데이터 검증 스키마는 자격 증명 또는 검증 가능한 자격 증명의 구조와 내용이
공개된 스키마를 준수함을 확립하는 데 사용됩니다.
데이터 인코딩 스키마는 검증 가능한 자격 증명의 내용을
영지식 증명에서 사용되는 형식과 같은 대체 표현 형식에 매핑하는 데 사용됩니다.
데이터 스키마는 @context 속성과 다른 목적을 수행한다는 점을
이해하는 것이 중요합니다. @context 속성은 데이터 구조나
데이터 구문을 강제하지 않으며, 대체 표현 형식으로의 임의 인코딩 정의를
가능하게 하지도 않습니다.
이 명세는 데이터 스키마를 표현하기 위한 다음 속성을 정의하며, 발급자는 자신이 발급하는
검증 가능한 자격 증명에 이를 포함할 수 있습니다:
credentialSchema
credentialSchema속성의 값은,
제공된 데이터가 제공된 스키마(들)를 준수하는지 판단할 수 있을 만큼 충분한 정보를
검증자에게 제공하는 하나 이상의
데이터 스키마여야 MUST 합니다. 각
credentialSchema는 그 type(예:
JsonSchema)과, 스키마 파일을 식별하는 URL이어야 MUST 하는
id속성을
지정해야 MUST 합니다. 특정 타입 정의는 각 데이터 스키마의
정확한 내용을 결정합니다.
여러 스키마가 존재하는 경우, 유효성은 연결된 각 type 속성이
개요로 제시하는 처리 규칙에 따라 결정됩니다.
참고: 자격 증명 타입별 구문 검사가 가능합니다
credentialSchema속성은 타입 정의에 주석을 달거나
이를 어휘의 특정 버전에 고정할 수 있게 합니다.
검증 가능한 자격 증명의 작성자는
어떤 콘텐츠 무결성 보호 메커니즘으로 보호된 정적 버전의 어휘를
credentialSchema를 사용하여 포함할 수 있습니다. credentialSchema속성은 또한
자격 증명에 대해 구문 검사를 수행하고 JSON Schema
[VC-JSON-SCHEMA]
검증과 같은 검증 메커니즘을 사용할 수 있게 합니다.
예제
14: JSON 스키마 검증을 수행하기 위해 credentialSchema 속성 사용
검증 가능한 프레젠테이션은 매우 짧은 수명을 가져야 하며
검증자가 제공한 챌린지에 바인딩되는 것이 좋습니다 SHOULD. 이를
달성하기 위한 세부 사항은 보안 메커니즘, 전송 프로토콜 및
검증자 정책에
따라 달라집니다.
특정 보안 메커니즘이나 임베딩 프로토콜이 추가 요구 사항을 정의하지 않는 한,
검증자는 일반적으로
검증 가능한 프레젠테이션이 제시된
검증 가능한 자격 증명과 상관관계가 있다고 가정할 수 없습니다.
id속성은 선택 사항입니다. 이는
검증 가능한 프레젠테이션에 대한
고유 식별자를 제공하는 데 사용될 수 MAY 있습니다. 존재하는 경우,
섹션 4.4 식별자의 규범적 지침을 따라야
MUST 합니다.
type
type속성은 존재해야 MUST 합니다.
이는 검증 가능한 프레젠테이션의
타입을 표현하는 데 사용됩니다. 이 속성의 한 값은
VerifiablePresentation이어야 MUST 하지만, 추가 타입도
포함될 수 MAY 있습니다.
섹션 4.5
타입의 관련 규범적 지침을 따라야
MUST 합니다.
검증 가능한 프레젠테이션은 holder속성을 포함할 수 MAY 있습니다. 존재하는 경우, 값은 URL이거나
id속성을 포함하는 객체여야 MUST 합니다.
holder의 URL 또는 그 id는,
역참조될 경우 보유자에 대한 기계 판독 가능한 정보를 담은 문서를 반환하고,
이 정보가 검증에 사용되어
검증 가능한 프레젠테이션에
표현된 정보를 검증할 수 있는 것이 권장됩니다 RECOMMENDED.
holder속성이 없는 경우,
보유자에 대한 정보는 보안 메커니즘을 통해 얻어지거나
검증 가능한 프레젠테이션의
유효성 판단과 관련이 없습니다.
일부 영지식 암호화 스킴은 보유자가
해당 검증 가능한 자격 증명의 모든 클레임을 공개하지 않고도,
검증 가능한 자격 증명에서 나온
클레임을 보유하고 있음을
간접적으로 증명할 수 있게 할 수 있습니다. 이러한
스킴에서는 검증 가능한 자격 증명이 제시 가능한
데이터를 파생하는 데 사용될 수 있으며, 이 데이터는 검증자가
발급자를 신뢰한다면 그 값을 신뢰할 수 있도록
암호학적으로 주장됩니다.
자격 증명이
발급자가 해당
자격 증명을 생성했으며, 그 자격 증명이
전송 중이나 저장 중에 변조되지 않았음을 명확히 확립하는 방식으로 전송됩니다.
이 기대 사항은 검증자의 위험 평가에 따라
약화될 수 있습니다.
모든 엔터티는 검증 가능한 데이터 레지스트리가 변조를 감지할 수 있고,
어떤 데이터가 어떤 엔터티에 의해 제어되는지에 대한 올바른 기록이기를 기대합니다.
이는 일반적으로 그 공개 방식에 의해 달성됩니다. 신뢰할 수 있는 게시자의
피어 투 피어 프로토콜, 공개적으로 접근 가능하고 잘 알려진 웹 사이트(콘텐츠 해시 포함),
블록체인 등을 통해 이루어질 수 있습니다. 엔터티가 자신에 대한
메타데이터를 게시할 때, 해당 게시물은 엔터티의 개인 키로 보호됨으로써
무결성 보호될 수 있습니다.
보유자는 발급자와
기존의 신뢰 관계를 가지고 있기 때문에 발급자의
클레임을 신뢰할 수 있습니다. 예를 들어,
고용주는 직원에게 고용 검증 가능한 자격 증명을 제공할 수 있고,
정부는 시민에게 전자 여권을 발급할 수 있습니다.
기존의 신뢰 관계가 없는 경우, 보유자는
제공되는 검증 가능한 자격 증명을
발급자가 발급할 자격이 있는지
판단할 수 있는 대역 외 수단을 가질 수 있습니다.
참고: 보유자가 항상 발급자를 신뢰할 필요는 없습니다.
발급된 검증 가능한 자격 증명이
보유자가 아닌 주체에 대한 주장일 수도 있고,
아무도 아닌 대상에 대한 주장일 수도 있으며,
보유자는 그 진실성에 대해 책임을 지지 않고도
이 정보를 검증자에게 전달하려 할 수 있기 때문입니다.
이 명세에서 자세히 설명하는 데이터 모델은 더 전통적인 인증 기관 신뢰
모델이 제공하는 것과 같은 전이적 신뢰 모델을 의미하지 않습니다.
검증 가능한 자격 증명 데이터 모델에서 검증자는
발급자를 직접 신뢰하거나 신뢰하지 않습니다.
검증 가능한 자격 증명 데이터 모델을 사용해 전이적 신뢰 모델을 구축하는 것은 가능하지만,
구현자는 인증 기관 시스템이 채택한 방식처럼
신뢰를 광범위하게 위임함으로써 도입되는
보안 취약점에 대해
알아볼 것을 강력히 권고받습니다.
5.2 확장성
검증 가능한 자격 증명 데이터 모델의 목표 중 하나는
허가 없는 혁신을 가능하게 하는 것입니다. 이를 달성하기 위해 데이터 모델은
여러 다른 방식으로 확장 가능해야 합니다. 데이터 모델은 다음을 요구받습니다:
위에서 개요를 제시한 모든 확장성 메커니즘을 소프트웨어 개발자와 웹 페이지 작성자에게
널리 쓰이는 데이터 형식으로 제공하며, 이는 JSON-LD 1.1 사용을 통해 가능합니다.
이러한 데이터 모델링 접근 방식은 종종
개방 세계 가정이라고 불리며, 이는 어떤 엔터티든 다른 어떤
엔터티에 대해서도 무엇이든 말할 수 있음을 의미합니다. 이 접근 방식은 단순하고
예측 가능한 소프트웨어 시스템을 구축하는 것과 충돌하는 것처럼 보이지만,
확장성과 프로그램 정확성의 균형을 맞추는 일은 닫힌 소프트웨어 시스템보다
개방 세계 가정에서 항상 더 어렵습니다.
이 섹션의 나머지 부분은 일련의 예제를 통해 확장성과 프로그램 정확성이
어떻게 달성되는지 설명합니다.
이 JSON-LD 컨텍스트가 생성된 후, 개발자는 이를 어딘가에 게시하여
검증자가
검증 가능한 자격 증명을 처리할 때 접근할 수 있게 합니다.
위 JSON-LD 컨텍스트가 https://extension.example/my-contexts/v1에 게시되어 있다고
가정하면, 컨텍스트를 포함하고 새 속성 및
자격 증명타입을
검증 가능한 자격 증명에 추가하여
이 예제를 확장할 수 있습니다.
이 예제는 검증 가능한 자격 증명 데이터 모델을 허가 없이 탈중앙화된 방식으로
확장하는 것을 보여줍니다. 표시된 메커니즘은 또한
이러한 방식으로 생성된 검증 가능한 자격 증명이
네임스페이스 충돌과 의미적 모호성을 방지할 방법을 제공하도록 보장합니다.
이와 같은 동적 확장성 모델은 구현 부담을 증가시킵니다.
그러한 시스템을 위해 작성된 소프트웨어는 확장이 있는
검증 가능한 자격 증명이 애플리케이션의 위험
프로파일에 따라 허용 가능한지 판단해야 합니다. 일부 애플리케이션은 특정
확장만 허용할 수 있으며, 매우 보안성이 높은 환경은 어떤 확장도 허용하지 않을 수 있습니다.
이러한 결정은 해당 애플리케이션의 개발자에게 달려 있으며,
구체적으로 이 명세의 영역이 아닙니다.
확장 명세 작성자는 JSON-LD 컨텍스트와 같은 자신의 문서가 높은 가용성을
가지도록 보장할 것을 강력히 권고받습니다. 이러한 문서를 사용하는 개발자는
문서를 검색할 수 없을 때 오류를 발생시키는 소프트웨어를 사용할 수 있습니다.
확장 JSON-LD 컨텍스트가 항상 사용 가능하도록 보장하는 전략에는
이러한 문서를 구현과 함께 묶는 것, 긴 캐싱 기간을 가진 콘텐츠
배포 네트워크, 또는 컨텍스트에 콘텐츠 주소 지정 URL을 사용하는 것이 포함됩니다.
이러한 접근 방식은 부록
B. 컨텍스트, 어휘, 타입 및 자격 증명 스키마에서 더 자세히 다룹니다.
가능하면 Schema.org와 같은
잘 알려진 공개 어휘에서 정의한 용어 및 그에 대응하는
URL을 재사용하는 것이 권장됩니다 RECOMMENDED.
새 용어는 각 용어에 대해 새 URL을 정의해야 MUST 합니다.
그렇게 할 때 [LINKED-DATA]의
일반 지침을 따를 것으로 기대되며, 특히:
각 용어의 의미와 사용 제약을 설명하는 사람이 읽을 수 있는 문서를
게시해야 MUST 합니다.
모든 새 용어의 모음을 RDF Schema 1.1을 사용해
기계 판독 가능한 어휘로도 게시하는 것이 권장됩니다
RECOMMENDED.
용어의 URL을 역참조하여 그 설명 및/또는 형식적 정의를 얻을 수 있어야
SHOULD 합니다.
또한 기계 판독 가능한 설명(즉,
JSON-LD 컨텍스트 문서)은
어휘에 대해 @context속성에 지정된 URL에
게시되어야 MUST 합니다. 이 컨텍스트는 각 용어를 그에 대응하는 URL에 매핑해야
MUST 하며, 속성 값의 타입과 같은 추가 제약을 동반할 수 있습니다.
상호운용성을 추구하는 모든 구현자는 @context속성 값의 예상 순서를 설명하는 사람이 읽을 수 있는 문서도
게시할 것으로 기대됩니다.
참고: 용어 재정의는 허용되지 않습니다
이 명세에서 정의된 기본 JSON-LD 컨텍스트 문서가 정의하는
활성
컨텍스트를 처리할 때, 적합한 JSON-LD 기반
처리기는 JSON-LD 컨텍스트가 어떤 용어라도 재정의하면 오류를 생성합니다.
기존 용어의 정의를 변경하는 유일한 방법은 그 새 용어의 범위 내에서
활성 컨텍스트를 지우는 새 용어를 도입하는 것입니다. 이 기능에 관심 있는 작성자는
JSON-LD 1.1 명세의 @protected
키워드에 대해 읽어야 합니다.
적합 문서는 프로덕션에서
@vocab 기능을
사용하지 않는 것이 좋습니다 SHOULD
NOT. 이는 JSON 용어 충돌을 일으켜 다른 애플리케이션과의 의미적 모호성을
초래할 수 있기 때문입니다. 대신, 적절한 상호운용성을 달성하기 위해
적합 문서는 앞서 섹션 5.2
확장성에서 설명한 것처럼,
애플리케이션에서 사용하는 모든 용어를 정의하는 JSON-LD 컨텍스트를 사용하는 것이 좋습니다
SHOULD. 적합 문서가 사용되는 모든 용어를 정의하는
JSON-LD 컨텍스트를 사용하지 않는 경우, @context 속성의 마지막 값으로
https://www.w3.org/ns/credentials/undefined-terms/v2를
포함해야 MUST 합니다.
5.3 관련 리소스의 무결성
검증 가능한 자격 증명에 외부 리소스에 대한 링크를 포함할 때,
해당 리소스가
검증 가능한 자격 증명이 발급된 이후 수정되었는지
아는 것이 바람직합니다. 이는 원격으로 검색되는
외부 리소스가 있는 경우뿐만 아니라,
발급자 및/또는 검증자가 리소스의
로컬 캐시 사본을 가지고 있을 수 있는 경우에도 적용됩니다.
검증자가
검증 가능한 자격 증명에서 사용된 JSON-LD 컨텍스트의 내용을 사용할 때,
그 내용이 발급자가 사용했을 때와 동일한지
아는 것도 바람직할 수 있습니다.
관련 리소스까지 무결성 보호를 확장하기 위해, 발급자는
검증 가능한 자격 증명에 MAYrelatedResource 속성을 포함할 수 있습니다:
relatedResource
relatedResource 속성의 값은 다음 형식의 객체 하나 이상이어야 합니다
MUST:
속성
설명
id
리소스의 식별자는 REQUIRED이며
섹션 4.4 식별자에서 정의된 형식을 따릅니다.
값은 관련 리소스 객체 목록 내에서 고유해야 합니다
MUST.
시스템이 만료된
검증 가능한 자격 증명을 수동 또는 자동으로 갱신할 수 있게 하는 것은 유용합니다.
검증 가능한 자격 증명의 유효 기간에 대한 자세한 내용은
섹션 A.7 유효 기간을 참조하십시오.
이 명세는 refreshService속성을 정의하며,
이는 발급자가 갱신 서비스에 대한 링크를 포함할 수 있게 합니다.
갱신 서비스는
자격 증명이 만료되었거나
발급자가
자격 증명 상태 정보를 게시하지 않는 경우에만 사용될 것으로 기대됩니다.
발급자는 공개 정보를 포함하지 않거나 갱신 서비스가 어떤 방식으로도
보호되지 않은
검증 가능한 자격 증명에
refreshService속성을 넣지 않도록 권고받습니다.
refreshService
refreshService속성의 값은
수신자가 검증 가능한 자격 증명을 갱신할 수 있도록
수신자의 소프트웨어에 충분한 정보를 제공하는 하나 이상의
갱신 서비스여야 합니다 MUST. 각
refreshService 값은 자신의 type을 지정해야 합니다 MUST.
각 갱신 서비스의 정확한 내용은 특정 refreshService타입 정의에 의해 결정됩니다.
termsOfUse속성의 값은
작성자가 자격 증명
또는 프레젠테이션을 발급한 하나 이상의 이용 약관 정책을 지정해야 합니다
MUST. 수신자(보유자 또는
검증자)가 지정된 이용 약관을 따를 의사가 없다면,
그들은 자신의 책임하에 그렇게 하는 것이며, 명시된 이용 약관을 위반할 경우
법적 책임을 질 수 있습니다. 각 termsOfUse 값은
예를 들어 TrustFrameworkPolicy와 같은 자신의
타입을 지정해야 하며 MUST, 자신의 인스턴스
id를 지정할 수 있습니다
MAY.
각 이용 약관의 정확한 내용은 특정 termsOfUse타입 정의에 의해 결정됩니다.
위 예제에서 발급자는
검증 가능한 자격 증명이 발급된 법적 근거가
특정 정책 링크와 함께 “Employment&Life” 신뢰 프레임워크를 사용하는
“professional qualifications directive”임을 주장하고 있습니다.
이 기능은 정부 발급 검증 가능한 자격 증명에서 디지털 지갑이
민감한 데이터의 예상치 못한 사용으로부터 시민을 보호하려는 시도로
유사한 정부 조직으로만 사용을 제한하도록 지시하는 데 사용될 것으로 기대됩니다.
마찬가지로, 민간 산업에서 발급한 일부 검증 가능한 자격 증명은
조직 내부 부서 내에서만 또는 업무 시간 동안만 사용을 제한할 것으로 기대됩니다.
구현자는 이 진화 중인 기능에 대해 Verifiable
Credentials Implementation Guidelines [VC-IMP-GUIDE] 문서의
해당 섹션에서 더 읽어볼 것을 강력히 권고받습니다.
5.6 증거
증거는 발급자가
검증자에게
검증 가능한 자격 증명 안의 추가적인 지원 정보를 제공하기 위해 포함할 수 있습니다.
이는 검증자가
검증 가능한 자격 증명의 클레임에 의존하는 신뢰도를 확립하는 데
사용될 수 있습니다. 예를 들어, 발급자는
주체가 제공한 물리적 문서를 확인하거나,
자격 증명을 발급하기 전에
일련의 배경 조사를 수행할 수 있습니다. 특정 시나리오에서 이 정보는
검증자가 주어진
자격 증명에 의존하는 것과 관련된 위험을 판단할 때 유용합니다.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
],
"id": "http://1edtech.edu/credentials/3732",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://1edtech.edu/issuers/565049",
"type": "Profile"
},
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"name": "Alice Smith",
"activityEndDate": "2023-12-02T00:00:00Z",
"activityStartDate": "2023-12-01T00:00:00Z",
"awardedDate": "2024-01-01T00:00:00Z",
"achievement": [{
"id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
"type": ["Achievement"],
"name": "Basic Barista Training",
"criteria": {
"narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
},
"description": "This achievement certifies that the bearer is proficient in basic barista skills."
}]
},
"evidence": [{
// 외부에 호스팅된 증거 파일/아티팩트의 URL
"id": "https://videos.example/training/alice-espresso.mp4",
"type": ["Evidence"],
"name": "Talk-aloud video of double espresso preparation",
"description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
// mp4 비디오 파일의 다이제스트 해시
"digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
}
]
}
위 evidence 예제에서 발급자는
자격 증명의
주체가
성취를 시연하는 영상을 자신이 가지고 있다고 주장하고 있습니다.
참고: 증거는 보안 메커니즘과 다른 목적을 가집니다
evidence속성은 사용된 보안 메커니즘과
다르고 별개의 정보를 제공합니다. evidence속성은
검증 가능한 자격 증명과 관련된 문서 증거와 같은
지원 정보를 표현하는 데 사용됩니다. 반대로 보안 메커니즘은
발급자의 진정성과
검증 가능한 자격 증명의 무결성과 관련된
기계가 검증할 수 있는 수학적 증명을 표현하는 데 사용됩니다. 보안 메커니즘에 대한 자세한 내용은
섹션 4.12
보안 메커니즘을 참조하십시오.
5.7 영지식 증명
영지식 증명은 보안 메커니즘으로,
보유자가 실제 값을 공개하지 않고도 값을 포함하는
검증 가능한 자격 증명을 보유하고 있음을 증명할 수 있게 합니다.
예를 들어 생일을 공개하지 않고도 개인이 25세 이상임을
증명할 수 있습니다. 이 데이터 모델은 영지식 증명을 사용한 보호를 지원합니다.
영지식 증명 메커니즘으로 가능해지는,
검증 가능한 자격 증명과 호환되는 일부 기능은 다음과 같습니다:
연결 불가능한 공개:
보유자가 검증자에게
검증 가능한 자격 증명의 속성을 연결 불가능하게 공개하는 것입니다.
블라인드 서명은 연결 불가능한 공개를 가능하게 하며,
이는 하나 이상의 검증자에게 여러 번 제시하는 동안
보유자 상관관계의 일반적인 원인을 제거합니다.
이는 보유자가
각 제시에 서로 다른 서명 값을 공유할 수 있게 하며, 그 결과 공유되는 데이터의 양을 줄입니다.
보안 메커니즘을 만드는 명세 작성자는
검증자가
서로 다른 검증자에게 제시된 여러
검증 가능한 프레젠테이션에서
보유자를 상관시킬 수 있게 하는 정보를 누출하는 방식으로
이를 설계해서는 안 됩니다 MUST NOT.
모든 영지식 증명 메커니즘에서 모든 기능이 지원되는 것은 아닙니다.
특정 영지식 증명 메커니즘이 제공하는 기능과 기술에 대한 구체적인 세부 사항,
그리고 이를 검증 가능한 자격 증명과 함께 사용하는 데 필요한 규범 요구 사항은,
해당 영지식 증명 메커니즘으로 검증 가능한 자격 증명을 보호하기 위한 명세에서 찾을 수
있을 것입니다.
그러한 명세의 예로 Data
Integrity BBS Cryptosuites v1.0을 참조하십시오.
위 검증 가능한 프레젠테이션은 이전 예제의 정보 중
연결 불가능한 부분집합과, 해당 정보가 기대한
발급자에서 비롯되었고 이 특정 정보 교환에 바인딩되어 있음을
검증자가 검증하는 데 사용할 수 있는
파생 증명을 포함하는
검증 가능한 자격 증명을 포함합니다.
5.8 시간 표현
구현자는 시간 값을 표현하고 처리하는 것이 보이는 것만큼 단순하지 않으며,
세계의 여러 지역에서 즉시 명확하지도 않고 균일하게 관찰되지도 않는
다양한 특이성을 가지고 있음을 이해할 것을 강력히 권고받습니다. 예를 들면:
그레고리력 이외의 달력 시스템이 여러 지역에서 적극적으로 사용됩니다.
일광 절약/서머 타임을 처리할 때는
1) 모든 지역에서 관찰되는 것은 아니며, 2) 반드시 같은 날이나 같은 시간에
시작하거나 끝나는 것은 아니고, 3) 조정의 양이나 방향이 다른 유사 지역과
항상 일치하지 않는다는 점을 이해하는 것이 중요합니다.
윤초는 모든 소프트웨어 시스템에서 고려되지 않을 수 있으며, 특히
윤초 도입 이전의 날짜와 시간에서는 더욱 그렇습니다. 윤초는 epoch로부터의 정확한
밀리초 오프셋에 의존하는 매우 민감한 시스템에 영향을 줄 수 있습니다. 그러나 대부분의 애플리케이션에서
영향을 받는 유일한 시간 순간은 윤초 자체의 1초 기간뿐이라는 점에 유의하십시오.
즉, 가장 최근 윤초 이후의 순간은 문제의 시스템이 윤초를 이해하는지 여부와 관계없이
항상 다음 날의 첫 순간(예:
2023-01-01T00:00:00Z)으로 표현될 수 있습니다.
이것들은 벽시계에서 볼 수 있는 실제 하루 중 시간이 한 지역에서는 존재하지만
다른 지역에서는 존재하지 않을 수 있음을 보여주는 몇 가지 예일 뿐입니다.
이러한 이유로 구현자는 일광 절약/서머 타임의 영향을 받는 값보다
Z 시간대에 고정된 값처럼 더 보편적인 시간 값을 사용할 것을 강력히 권고받습니다.
이 명세는 [XMLSCHEMA11-2] 명세에서 처음 확립한
dateTimeStamp 구성을 사용함으로써, 보편적으로 인식되는 날짜와 시간 조합의 수를 늘리고
시간 값의 오해 가능성을 줄이려 합니다. 서로 다른 시간대 간의 오해를 줄이기 위해,
적합 문서에 표현된 모든 시간 값은
dateTimeStamp 형식으로 지정하는 것이 좋습니다 SHOULD.
이는 값의 끝에 Z로 표시되는 협정 세계시(UTC)이거나 UTC에 상대적인
시간대 오프셋을 포함해야 합니다. 오프셋 없이 잘못 직렬화된 시간 값은
UTC로 해석되어야 합니다 MUST. UTC에 상대적인 유효한 시간대 오프셋의 예에는
Z, +01:00,
-08:00 및
+14:00이 포함됩니다. 허용 가능한 모든 값의 형식적 정의는 이 섹션 끝의
정규식을 참조하십시오.
시간대 정의는 때때로 그 관할 기관에 의해 변경됩니다.
검증 가능한 자격 증명을
교체하거나 새로 발급할 때, 구현자는 현지 시간대 규칙의 변경이
유효성에 예상치 못한 공백을 만들지 않도록 보장할 것을 권고받습니다.
예를 들어, 원시 오프셋이 UTC-8이고 2024년에 일광 절약 시간 관찰을 중단하기로
투표한 America/Los_Angeles 영역을 고려하십시오. validUtil
값이 2024-07-12T12:00:00-07:00인 주어진
검증 가능한 자격 증명은
validFrom 값이 2024-07-12T12:00:00-08:00이 되도록 재발급될 수 있으며,
이는 검증 가능한 자격 증명이 유효하지 않은
한 시간의 공백을 만들 수 있습니다.
dateTimeStamp 값의 유효성을 확인하려는 구현자는 아래에 제공된 정규식을 사용할 수 있으며,
이는 편의를 위해 [XMLSCHEMA11-2] 명세에서 재현한
것입니다.
의심을 피하기 위해, [XMLSCHEMA11-2]의
정규식이 규범 정의입니다. 구현자는 아래 정규식을 통과하는 모든
dateTimeStamp 값이 유효한 시간 순간인 것은 아니라는 점을 권고받습니다.
예를 들어 아래 정규식은 매월 31일을 허용하므로, 윤년과 윤초뿐만 아니라
존재하지 않는 장소의 날짜도 허용합니다. 그렇다 하더라도, 현대 시스템 라이브러리는
유효한 dateTimeStamp 값 생성에서 오류가 없는 경우가 많습니다.
아래 표시된 정규식(가독성을 위해 여기에 포함된 공백을 제외한 것)은
현대 시스템에서 라이브러리가 생성한 날짜와 시간을 처리할 때 흔히 충분합니다.
예제
32: 유효한 XML Schema
1.1: Part 2 dateTimeStamp를 감지하는 정규식
검증 가능한 자격 증명은
주체를 신뢰성 있게 식별하기 위한 수단으로 의도되었습니다.
역할 기반 접근 제어(RBAC)와 속성 기반 접근 제어(ABAC)가
주체에게 리소스 접근을 인가하는 수단으로 이 식별에 의존한다는 점은
인정되지만, 이 명세는 RBAC 또는 ABAC에 대한 완전한 해결책을 제공하지 않습니다.
인가는 수반되는 인가 프레임워크 없이는 이 명세의 적절한 사용이 아닙니다.
작업 그룹은 이 명세를 작성하는 동안 인가 사용 사례를 고려했으며,
이 명세 위에 구축되는 아키텍처 계층으로 그 작업을 추진하고 있습니다.
5.10 예약된 확장 지점
이 명세는 가능한 확장 지점으로 사용하기 위해 여러
속성을 예약합니다. 일부 구현자가 이러한 속성에
관심을 표시했지만, 이를 이 명세에 포함하는 것은 시기상조로 간주되었습니다.
이러한 속성 중 어느 것도 이 명세에서 정의되지 않는다는 점이 중요합니다.
따라서 구현자는 이러한 속성의 사용이 실험적인 것으로 간주됨을 유의해야 합니다.
구현자는 이러한 속성을 사용할 수 있지만 MAY, 이를 규범적으로 명시하는 과정에서
해당 속성 및/또는 그 의미가 변경될 것으로 예상하는 것이 좋습니다
SHOULD. 구현자는 구현을 설명하는 공개된 명세 없이
이러한 속성을 사용하지 않는 것이 좋습니다 SHOULD NOT.
다음 속성이 사용되는 방식과 관련한 충돌을 피하기 위해,
구현은 예약된 속성과 연결된 값에 type 속성을 지정해야 합니다
MUST. type 정보 추가와 관련된 자세한 내용은
섹션 4.5
타입을 참조하십시오.
예약된 속성
설명
confidenceMethod
검증자가 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션 안이나 그 자체의
속성 값이 정확하다는 확신을 높이는 데 사용할 수 있는 하나 이상의 방법을
지정하는 데 사용되는 속성입니다. 연결된 어휘
URL은 https://www.w3.org/2018/credentials#confidenceMethod이어야 합니다
MUST.
renderMethod
자격 증명을 시각, 청각, 촉각 또는 기타 형식으로 렌더링하기 위한
하나 이상의 방법을 지정하는 데 사용되는 속성입니다. 연결된 어휘 URL은
https://www.w3.org/2018/credentials#renderMethod이어야 합니다
MUST.
이 명세에서 정의된 확장 지점과 이 섹션에서 정의된 예약된 확장 지점과
연결된 명세의 비공식 목록은 Verifiable Credential Extensions에서 찾을 수
있습니다.
디렉터리에서 예약된 확장 지점을 참조하는 항목은 실험적인 것으로 취급하는 것이 좋습니다
SHOULD.
개념적으로 정렬된 디지털 자격 증명 형식이 이 섹션에서 제공하는 규칙에 따라
적합 문서로 변환될 수 있다면, 그것들은
"W3C Verifiable
Credentials
생태계와 호환된다"고 간주됩니다. 명세 작성자는
Verifiable Credentials 생태계와의 호환성을 가능하게 하는 변환을 문서화할 때
다음 규칙을 따르도록 권고받습니다. 변환 명세는 —
이 데이터 모델로의 변환이 단방향 전용인지 또는 왕복 가능한지를 식별해야 합니다
MUST.
이 명세의 데이터 모델로 지정된 변환 알고리즘이
적합 문서를 생성함을 입증하는 테스트 스위트를
제공하는 것이 좋습니다 SHOULD.
변환된 적합 문서에 사용된 모든 의미가 Linked
Data의 모범 사례를 따르도록 보장하는 것이 좋습니다 SHOULD. 추가 지침은
섹션 4.1 시작하기, 섹션
5.2 확장성 및 Linked Data Best Practices [LD-BP]를
참조하십시오.
참고: 무엇이 검증 가능한 자격 증명을 구성하는가?
독자는 디지털 자격 증명이 적합 문서이고,
이 명세의 각 요구 사항에 설명된 것처럼 적어도 하나의 보안 메커니즘을 사용하는 경우에만
W3C Verifiable Credentials 생태계와 호환되는 것으로
간주된다는 점을 유의해야 합니다. 일부 커뮤니티가
적합 문서가 아닌 일부 디지털 자격 증명 형식을
“검증 가능한 자격 증명”이라고 부를 수 있지만, 그렇게 한다고 해서 해당 디지털 자격 증명이
이 명세에 적합해지는 것은 아닙니다.
5.12 검증 가능한 자격 증명 그래프
검증 가능한 자격 증명을 표현할 때
(예: 프레젠테이션에서), 한
검증 가능한 자격 증명의 데이터가 다른
검증 가능한 자격 증명의 동일한 데이터로
오인되지 않도록 보장하는 것이 중요합니다. 예를 들어, 두 개의
검증 가능한 자격 증명이 있고,
각각 다음 형식의 객체를 포함한다고 할 때: {"type": "Person", "name": "Jane
Doe"}, 한 객체가 다른 객체와 같은 사람을 설명하는지 알 수 없습니다.
다시 말해, 동일한 엔터티 및/또는 속성에 대해 논의하고 있음을 확인하지 않고
두 검증 가능한 자격 증명 간에 데이터를 병합하면
손상된 데이터 집합으로 이어질 수 있습니다.
이러한 그래프를 사용하면 JSON-LD 처리를 수행할 때 구체적인 효과가 있으며,
한 그래프의 그래프 노드 식별자를 다른 그래프의 식별자와 적절히 분리합니다.
입력을 애플리케이션별 JSON-LD 문서로 제한하는 구현자도
한 검증 가능한 자격 증명의 데이터를
다른 자격 증명의 데이터와 병합할 때, 예를 들어 두
검증 가능한 자격 증명 모두에서
credentialSubject.id가 동일하지만 해당 객체가 이전 단락에서 설명한
"Jane Doe" 형식의 객체를 포함할 수 있는 경우, 이를 염두에 두어야 합니다.
유사한 속성을 가진 것처럼 보이지만 URL과 같은 전역 식별자를 사용하는
id 속성을 포함하지 않는 객체는 병합하지 않는 것이 중요합니다.
5.13 보안 메커니즘
명세
섹션 4.12 보안 메커니즘에서 설명한 것처럼,
구현자가 적합 문서를 보호할 때 사용할 수 있는
여러 전략이 있습니다. 유용성과 상호운용성을 극대화하기 위해,
적합 문서를 보호하는 새로운 방법을 작성하고자 하는
명세 작성자에게 이 섹션의 지침이 제공됩니다.
보안 메커니즘 명세는 적합 문서에 대한 콘텐츠 무결성 보호를 제공하는
규범 알고리즘을 문서화해야 합니다 MUST. 이
알고리즘은 일반적인 성격일 수 있으며 MAY,
적합 문서 이외의 데이터를 보호하는 데도 사용될 수 있습니다
MAY.
보안 메커니즘 명세는 proof 또는 JOSE/COSE 헤더 매개변수와 서명 같은
보안 메커니즘 정보를 포함하지 않고, 보호된
적합 문서의 정보를
분리된 상태로 반환하는 검증 알고리즘을 제공해야 합니다 MUST.
검증 알고리즘은 보안 메커니즘의 세부 정보와 같이 도움이 될 수 있는 추가 정보를
반환할 수 있습니다 MAY(예: 유효성 확인 중 또는 디버깅 목적).
검증 알고리즘은 미디어 타입(문자열inputMediaType) 및 입력 데이터(바이트 시퀀스 또는 맵inputData)를 받는
인터페이스를 제공해야 합니다 MUST.
보안 메커니즘 명세는 이 문서에 지정된 것 외에도 알고리즘과 인터페이스를 제공할 수 있습니다
MAY. 검증 알고리즘은 적어도 다음
항목을 가진 검증 결과를 반환합니다:
Section 3. 핵심 데이터
모델,
4.
기본 개념 및 5. 고급 개념에서 설명한 데이터 모델은 검증 가능한
자격 증명 또는 검증 가능한 프레젠테이션의 정준 구조적
표현입니다.
모든 구문은 특정 형식으로 표현된 해당 데이터 모델의 표현입니다. 이
절에서는 검증 가능한 자격 증명과 검증
가능한 프레젠테이션의 기본 미디어 타입인
application/vc 및 application/vp에 대해 데이터 모델이 JSON-LD로
직렬화되는 방식을 지정합니다. 구문적
매핑은 JSON-LD에 대해서만 제공되지만, 애플리케이션과 서비스는
application/vc 또는 application/vp로 다시 매핑될 수 있는
다른 데이터 표현 구문(예: XML, YAML 또는 CBOR)을 사용할 수 있습니다. 검증 및 유효성 확인
요구 사항은 데이터 모델의 관점에서 정의되므로,
모든 직렬화 구문은 처리, 유효성 확인 또는 비교를 위해
결정론적으로 데이터 모델로 변환되어야 합니다.
이 명세에서 속성 값의 예상 차수와, 해당 값을 담는 결과
데이터 타입은 속성에 따라 달라질 수 있습니다.
존재하는 경우, 다음 속성은 단일 값으로 표현됩니다: id
(Section 4.4 식별자), issuer (Section 4.7 발급자) 및
validFrom/validUntil (Section 4.9 유효
기간). 그 밖의 모든 속성은,
존재하는 경우, 단일 값 또는 값의 배열로 표현됩니다.
JSON-LD는
Linked Data를 직렬화하는 데 사용되는 JSON 기반 형식입니다.
Linked
Data는 Resource Description Framework (RDF) [RDF11-CONCEPTS]를 사용하여 모델링됩니다.
RDF는 명제의 그래프를 모델링하는 기술입니다. 각 명제는
단일 주체→속성→값(또는
엔터티→속성→값) 관계이며, 이 명세에서는 이를
클레임이라고
합니다. JSON-LD는 관용적인 JSON을 사용하여 RDF를 표현할 수 있게 하는 기술로,
JSON에 익숙한 개발자가 RDF를 JSON으로 소비하는 애플리케이션을 작성할 수 있게 합니다.
자세한 내용은
JSON-LD와 RDF의 관계를 참조하십시오.
주목할 만한 JSON-LD 기능
일반적으로 이 문서에서 설명하는 데이터 모델과 구문은 개발자가
검증 가능한 자격 증명을
대부분 JSON 문서처럼 다룰 수 있게 하며,
예제를 약간 수정하여 소프트웨어 시스템에 복사해 붙여 넣을 수 있게 합니다.
이 접근 방식의 설계 목표는 낮은 진입 장벽을 제공하면서도 이기종
소프트웨어 시스템 간의 전역 상호 운용성을 보장하는 것입니다. 이 절에서는
이를 가능하게 하기 위해 사용되는 JSON-LD 기능 중 일부를 설명합니다. 이러한 기능은
대부분의 개발자에게는 눈에 띄지 않을 수 있지만, 그 세부 사항은 구현자에게
관심의 대상일 수 있습니다. 이 명세에서 사용하는
JSON-LD
1.1의 가장 주목할 만한 기능은 다음과 같습니다.
@id 및 @type 키워드는 각각
id 및 type으로 별칭 처리되어, 개발자가
이 명세를 관용적인 JSON으로 사용할 수 있게 합니다.
정수, 날짜, 측정 단위, URL과 같은 데이터 타입은
자동으로 타입이 지정되어, 이를 필요로 하는 사용 사례에 대해 더 강한
타입 보장을 제공합니다.
verifiableCredential속성은
JSON-LD 1.1 그래프
컨테이너로 정의됩니다. 이는 서로 다른 엔터티가 주장한 데이터 집합을
분리하는 데 사용되는 명명된
그래프의 생성을 필요로 합니다. 이는 예를 들어, 각 발급자가 제공한 데이터 그래프와
보유자가 제시하는
검증 가능한 자격 증명의 데이터 그래프 사이에
적절한 암호학적 분리를 보장하여, 각 그래프에 대한 정보의 출처가
보존되도록 합니다.
JSON-LD
1.1의
@protected 속성 기능은 이 명세에서 정의한 용어가 재정의될 수 없도록
보장하는 데 사용됩니다. 이는 동일한 @context 선언이 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 맨 위에 있는 한,
데이터 모델 사용자가 이해하는 모든 용어에 대해
JSON-LD
1.1 프로세서를 사용하는지 여부와 관계없이 상호 운용성이
보장된다는 의미입니다.
JSON-LD에 대한 제한
상호 운용성을 높이기 위해 이 명세는 데이터 모델의 JSON-LD 표현 사용을
제한합니다. application/vc 또는 application/vp 미디어 타입을 사용하는
데이터 모델의 모든 표현에는 JSON-LD 압축 문서
형식이 MUST 사용되어야 합니다.
Section
6.3 타입별 자격 증명 처리에서 자세히 설명하듯이, 일부 소프트웨어 애플리케이션은
일반화된 JSON-LD 처리를 수행하지 않을 수 있습니다. 적합 문서의 작성자는
@context 값의 JSON-LD 키워드가, 예를 들어
@base 또는 @vocab 키워드 중 하나 또는 둘 다를 설정하는 방식으로,
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 값에 전역적으로 영향을 주도록 사용되면
상호 운용성이 감소할 수 있음을 유의해야 합니다. 예를 들어,
이러한 값을 설정하면, 타입별
자격 증명 처리를 수행하며 @base 및/또는 @vocab 값이
@context 값에 표현될 것으로 예상하지 않는 구현에서,
잘못 구현된 JSON Schema의 @context 값 테스트에 실패를 유발할 수 있습니다.
상호 운용성을 높이기 위해 적합 문서 작성자는
타입별
자격 증명 처리를 수행할 때 쉽게 감지되지 않는 JSON-LD 기능을 사용하지 않을 것을
권장받습니다. 이러한 기능에는 다음이 포함됩니다.
@context 값 안에서 문서 용어 및 값 처리를 전역적으로 수정하는
JSON-LD 키워드를 인라인으로 선언하는 것(예: @base 또는
@vocab 설정)
이전 컨텍스트의 선언을 재정의하는 JSON-LD 컨텍스트 사용(예:
@vocab 재설정)
@context 속성 안에서 JSON-LD 컨텍스트를 인라인으로 선언하는 것
JSON-LD 용어와 타입에 대해 전체 URL(예:
https://www.w3.org/2018/credentials#VerifiableCredential 또는
https://vocab.example/myvocab#SomeNewType)을, JSON-LD
@context 매핑(예:
https://www.w3.org/ns/credentials/v2)에 명시적으로 정의된
그러한 값의 짧은 형식(예:
VerifiableCredential 또는 SomeNewType) 대신 사용하는 것
이 명세는 @vocab 사용에 대해 주의를 주지만, 이 기능에는
실험, 개발, 현지화된 배포를 용이하게 하는 것과 같은 합법적인 사용 사례가 있습니다.
애플리케이션 개발자가 프로덕션에서 @vocab을 사용하려는 경우, 이는
용어 충돌을 줄이고 의미론적 상호 운용성의 이점을 활용하기 위해 권장되지 않지만,
@vocab을 사용하면 "정의되지 않은 용어" 오류 보고가 비활성화되고,
이후 사용은 이전의 모든 @vocab 선언을 재정의한다는 점을 이해해야 합니다.
@vocab의 값이 달라지면 문서에 포함된 정보의 의미가 바뀔 수 있으므로,
이러한 변경이 개발 중인 애플리케이션에 영향을 미치는지와 그 방식을
이해하는 것이 중요합니다.
목록과 배열
JSON-LD
1.1을 사용할 때 목록, 배열, 심지어 목록의 목록도 가능합니다.
목록과 배열을 필요로 하는 사용 사례에서 RDF 의미론을 원하는 사람은
JSON-LD 1.1의 목록에 대한 지침을
따를 것을 권장합니다.
일반적으로 JSON 배열은 순서가 있지만, JSON-LD 배열은 해당 배열이 @list
키워드를 사용하지 않는 한 순서가 없습니다.
참고: 배열 순서는 중요하지 않을 수 있음
타입별 자격 증명
처리를 수행하여 이 데이터 모델을 사용할 수는 있지만,
그렇게 하면서 배열을 사용하는 사람은 위의 지침을 따르지 않는 한 배열 내 항목의 순서가
JSON-LD에서 보장되지 않는다는 점을 알아야 합니다. 이는 예기치 않은 동작으로 이어질 수 있습니다.
JSON 구조나 순서가 애플리케이션에 중요하다면, 사용 사례에 특화된
@context를 통해 그러한 요소를 @json으로 표시할 것을 권장합니다.
그러한 선언의 예가 아래에 나와 있습니다.
위에 표시된 컨텍스트가 아래 예제에서 사용될 때, @context 속성에
https://website.example/matrix/v1 컨텍스트를 포함함으로써,
credentialSubject.matrix의 값은 JSON 의미론을 유지합니다. 2차원 행렬의
모든 요소의 정확한 순서가 보존됩니다.
이 명세에서 데이터 모델을 표현하는 데 사용되는 구문은 미디어 타입으로 식별되는 것이
SHOULD 되며, 검증
가능한 자격 증명과 함께 미디어 타입을
정의하거나 사용할 때는 이 절에 설명된 관례를 따르는 것이 SHOULD 됩니다.
핵심 데이터 모델과 관련된 두 가지 미디어 타입이 있으며, 이는 Section C. IANA 고려
사항에 나열되어 있습니다:
application/vc 및 application/vp.
application/vc 및 application/vp 미디어 타입은
특정 보안 메커니즘을 의미하지 않지만, 보안 메커니즘과 함께 사용되도록
의도되어 있습니다. 이러한 미디어 타입의 무결성을 보호하려면 보안 메커니즘이 적용되어야 합니다.
콘텐츠를 전달하는 데 사용된 미디어 타입과 관계없이 콘텐츠의 보안을 가정하지 마십시오.
미디어 타입 정밀도
이 절은 비규범적입니다.
때때로 개발자나 시스템은 낮은 정밀도의 미디어 타입을 사용하여
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 전달할 수 있습니다. 낮은 정밀도의 미디어 타입을 사용하는
이유에는
다음이 포함됩니다.
파일 확장자를 사용할 수 없고 미디어 타입을 판별할 수 없을 때, 웹 서버가
기본값으로 text/plain 또는 application/octet-stream을 사용합니다.
개발자가 파일 내용보다 덜 구체적인 미디어 타입으로 이어지는 파일 확장자를 추가합니다.
예를 들어, .json은
application/json 미디어 타입이 될 수 있고 .jsonld는
application/ld+json 미디어 타입이 될 수 있습니다.
프로토콜이 특정 트랜잭션에 대해 덜 정밀한 미디어 타입을 요구합니다. 예를 들어,
application/vp 대신 application/json을 요구하는 경우입니다.
구현자는, 사용된 미디어 타입이 해당 프로토콜에서 허용 가능하다면, 페이로드에서
의도된 미디어 타입을 판별할 수 있는 경우 오류를 발생시키지 않을 것을 권장받습니다.
예를 들어, 애플리케이션이 application/vc 미디어 타입과 관련된 규칙을
따르는 페이로드만 허용하지만, 페이로드가 대신 application/json 또는
application/ld+json으로 태그되어 있다면, 애플리케이션은 페이로드가
더 높은 정밀도의 미디어 타입에도 부합하는지 판별하기 위해 다음 단계를 수행할 수 있습니다.
페이로드를 JSON 문서로 파싱합니다.
@context 속성의 첫 번째 요소가
https://www.w3.org/ns/credentials/v2와 일치하는지 확인합니다.
JSON 문서에 최상위 type 속성이 있고 그 안에
VerifiablePresentation 요소가 포함되어 있으면 application/vp
미디어 타입으로 가정합니다. 페이로드가 적합한
검증 가능한 프레젠테이션을 표현하는지 확인하기 위해
이 명세에 따라 추가 후속 검사가 여전히 수행될 것으로 예상됩니다.
JSON 문서에 최상위 type 속성이 있고 그 안에
VerifiableCredential 요소가 포함되어 있으면 application/vc
미디어 타입으로 가정합니다. 페이로드가 적합한
검증 가능한 자격 증명을 표현하는지 확인하기 위해
이 명세에 따라 추가 후속 검사가 여전히 수행될 것으로 예상됩니다.
가능하면 구현자는 이 명세에서 정의한 모든 페이로드에 대해 가장 정밀한(가장 높은
정밀도의) 미디어 타입을 사용할 것을 권장받습니다.
또한 구현자는 더 낮은 정밀도의 미디어 타입으로 태그된 페이로드가
더 높은 정밀도의 타입으로 태그하기 위해 필요한 규칙을 충족하지 않는다는 뜻은 아니라는
점을 인식해야 합니다. 마찬가지로, 더 높은 정밀도의 미디어 타입으로 태그된 페이로드가
그 미디어 타입과 관련된 요구 사항을 충족한다는 뜻도 아닙니다. 페이로드의 수신자는
관련 미디어 타입과 관계없이, 페이로드가 주어진 시스템에서 사용되기 위한 요구 사항에
부합하는지 확인하기 위해 적절한 검사를 수행할 것으로 예상됩니다.
JSON은 다양한 종류의 정보를 표현하는 데 사용될 수 있으므로, 특정 JSON 문서의
소비자는 그것을 다른 가능한 표현들과 구분하고 맥락화하는 정보를 가지고 있어야만
작성자의 의도를 올바르게 해석할 수 있습니다. 이러한 해석을 돕는 정보는 JSON 문서의
완전히 외부에 있을 수도 있고, 문서 내부에서 링크될 수도 있습니다. 압축된 JSON-LD 문서는
@context 속성을 포함하며, 이는 클레임을 표현하기 위한 맥락 정보를 내부적으로 표현하거나
링크합니다. 이러한 기능은 JSON-LD 문서를 한 컨텍스트에서 다른 컨텍스트로 변환하는
일반화된 프로세서를 작성할 수 있게 하지만, 소비자가 이미 자신이 기대하는 컨텍스트와
형태를 사용하는 JSON-LD 문서를 받는 경우에는 이러한 처리가 필요하지 않습니다.
발급자와 같은
JSON-LD 문서 작성자는
검증 가능한 자격 증명에 대해,
상호 운용성을 촉진하기 위해 적절한 JSON-LD 컨텍스트를 제공하고 이러한 규칙을 따라야 합니다.
아래 텍스트는 소비자가 JSON-LD 문서가 자신의 애플리케이션이 이미 이해하는
컨텍스트와 형태로 표현되었는지 확인하여, 그 내용을 소비하기 위해 별도로 변환할 필요가
없도록 하는 방법을 이해하는 데 도움이 됩니다. 특히, 이것이 소비자가 어떤 컨텍스트도
전혀 이해할 필요가 없다는 뜻은 아닙니다. 오히려 소비 애플리케이션은 선택된
컨텍스트 집합과 문서 형태만 이해하면 되고 다른 것들은 이해할 필요가 없습니다.
발급자는 일반화된 프로세서를 사용하지 않는 소비자를 돕기 위해, 다른 JSON 형식 데이터와
마찬가지로 컨텍스트와 자신의 검증 가능한 자격 증명에
대한 정보를 게시할 수 있습니다.
일반
JSON-LD 처리는
JSON-LD 소프트웨어 라이브러리를 사용하여 적합 문서에 대해 다양한
변환을 수행함으로써 처리하는
메커니즘으로 정의됩니다.
타입별 자격 증명 처리는 JSON-LD 소프트웨어 라이브러리를 필요로 하지 않는
적합 문서 처리용
더 가벼운 메커니즘으로 정의됩니다. 검증 가능한 자격 증명의 일부 소비자는
특정 타입의 자격 증명만 소비하면 됩니다. 이러한 소비자는 일반화된 처리 대신
타입별 자격 증명 처리를 사용할 수 있습니다. 타입별 자격 증명 처리가 바람직할 수 있는
시나리오에는 다음이 포함되지만 이에 국한되지는 않습니다.
적합 문서에 보안 메커니즘을 적용하기 전,
또는 보안 메커니즘으로 보호된 적합 문서를 검증한 후,
데이터 무결성을 보장하기 위한 경우.
Section
4.11 데이터 스키마에서 설명한 대로 JSON Schema 유효성 확인을
수행하는 경우.
@context 속성과 관련된 모든 값이 예상된 순서에 있는지, 각 파일에 대해
컨텍스트 파일의 내용이 알려진 양호한 암호학적 해시와 일치하는지, 그리고 도메인 전문가가
그 내용이 의도한 사용 사례에 적합하다고 판단했는지 확인하십시오.
JSON Schema와 함께 정적 컨텍스트 파일을 사용하는 것은 위 규칙을 구현하는 한 가지
허용 가능한 접근 방식입니다. 이는 타입별 자격 증명 처리를 수행할 때
적절한 용어 식별, 타입 지정 및 순서를 보장할 수 있습니다.
위 규칙은 @context 메커니즘을 통해 리터럴 JSON 키를 URI로 매핑하는
두 처리 메커니즘 간의 의미론적 상호 운용성을 보장합니다.
일반 JSON-LD 처리는 이전에 보지 못한
@context 값을 그 알고리즘에서 사용하여 모든 용어가 올바르게 지정되었는지
검증할 수 있지만, 타입별 자격 증명 처리만 수행하는
구현은
구현이 미리 이해하도록 설계된 특정 @context 값만 받아들여,
JSON-LD API를 호출하지 않고도 동일한 의미론을 얻습니다. 다시 말해,
데이터 교환이 일어나는 컨텍스트는 두 처리 메커니즘 모두에서 @context를 사용하여
동일한 적합 문서 의미론으로 이어지는 방식으로
명시적으로 표현됩니다.
구현자는 이 절의 알고리즘이 이 명세에 대한 적합성을 테스트하기 위해
구현에서 사용하는 최소한의 검사 집합만 포함한다는 점을 유의해야 합니다.
구현은 개발자가 잠재적 문제를 디버그하는 데 도움이 되는 유용한 경고를 보고하는
추가 검사를 제공할 것으로 예상됩니다.
마찬가지로, 구현은 유해한 콘텐츠를 차단하기 위해 새로운 유형의 오류가 보고될 수 있는
추가 검사를 제공할 가능성이 높습니다.
이러한 추가 검사 중 어느 것이든 이 명세의 향후 버전에 통합될 수 있습니다.
verifyProof 함수가 바이트 시퀀스를 기대하는 경우,
알고리즘에 inputMediaType 및 inputData를 제공합니다.
verifyProof 함수가
맵을
기대하는 경우, inputMediaType 및 inputData가 주어진
JSON 바이트를
Infra 값으로 파싱한 결과를 제공합니다. result를
verifyProof 함수 호출의 결과로 설정합니다. 호출이 성공하면
result는
status, document, mediaType,
controller,
controlledIdentifierDocument, warnings 및 errors
속성을 포함합니다.
result.status가 true로 설정되어 있으면,
result.document가 적합
문서인지 확인합니다. 그렇지 않은 경우,
result.status를 false로 설정하고,
result에서 document 속성을 제거한 다음,
적어도 하나의 MALFORMED_VALUE_ERROR를
result.errors에 추가합니다. 디버깅 과정을 돕기 위해
다른 경고와 오류가 포함될 MAY 있습니다.
result를 반환합니다.
보안 메커니즘의 상태를 검증하고 입력 문서가 적합 문서인지 검증하는 단계는,
구현이 동일한 잘못된 입력에 대해 오류를 반환하는 한 위에 제공된 순서와
다른 순서로 수행될 MAY 있습니다.
구현은 위에서 설명한 것과 다른 오류를 생성할 MAY 있습니다.
7.2 문제 세부 정보
구현이 문서를 처리하는 동안 이상을 감지하면,
ProblemDetails 객체를 사용하여 다른 소프트웨어 시스템에
문제를 보고할 수 있습니다. 이러한 객체의 인터페이스는 데이터를 인코딩하기 위해
[RFC9457]를 따릅니다.
ProblemDetails 객체는 다음 속성으로 구성됩니다.
type
type속성은 존재해야 MUST 하며, 그 값은
문제의 타입을 식별하는 URL이어야
MUST 합니다.
title
title속성은 문제에 대한 짧지만 구체적인
사람이 읽을 수 있는 문자열을 제공하는 것이 SHOULD 됩니다.
detail
detail속성은 문제에 대한
더 긴 사람이 읽을 수 있는 문자열을 제공하는 것이 SHOULD 됩니다.
개인정보 보호 솔루션은 사용 사례에 따라 다릅니다.
예를 들어, 많은 사람은 주류를 구매할 때 익명을 유지하기를 선호할 것입니다.
이는 규제가 구매자가 특정 연령 이상인지 확인하는 것만 요구하기 때문입니다.
반대로 의료 전문가가 환자를 위해 작성한 처방전을 조제할 때는,
약국이 처방자와 환자 모두를 더 강하게 식별해야 할 법적 의무가 있습니다.
모든 사용 사례에 맞는 단일 개인정보 보호 접근 방식은 없습니다.
참고: 일부 사용 사례에서는 연령 증명이 충분하지 않을 수 있음
주류를 구매할 때 익명을 유지하려는 사람들도 상인이 적절히 확신할 수 있도록
사진이 포함된 신분증을 제공해야 할 수 있습니다. 상인은 이름이나 특정 연령을 초과했다는
사실 이외의 세부 정보를 알 필요가 없을 수 있지만, 많은 경우 단순한 연령 증명만으로는
규제를 충족하기에 충분하지 않을 수 있습니다.
검증 가능한 자격 증명 데이터 모델은 전체 개인정보 보호 스펙트럼을 지원하려고 노력하며,
특정 거래에 대해 어느 정도의 익명성이 올바른지에 대한 철학적 입장을 취하지 않습니다.
다음 절들은 개인정보 보호에 적대적인 특정 시나리오를 피하고자 하는 구현자에게
지침을 제공합니다.
8.2 소프트웨어 신뢰 경계
이 절은 비규범적입니다.
이 명세에서 설명하는 생태계에는
다양한 신뢰 관계가 존재합니다. 웹 브라우저를 사용하는 개인은 웹 브라우저,
즉 사용자 에이전트가
자신의 개인 정보를 데이터 브로커에게 업로드하지 않음으로써 그 신뢰를 보존할 것을 신뢰합니다.
마찬가지로, 이 명세에서 설명하는 생태계의 역할을 수행하는 엔터티는
각 역할을 대신해 동작하는 소프트웨어를 신뢰합니다.
예는 다음과 같습니다.
발급자의
사용자 에이전트
(발급자 소프트웨어), 예를 들어 온라인 교육 플랫폼은 발급자가 교육 프로그램을
완료했다고 주장하는 개인에게만
검증 가능한 자격 증명을 발급할 것으로 예상됩니다.
보유자의
사용자 에이전트
(보유자 소프트웨어), 예를 들어 디지털 지갑은 보유자가
해당 정보 공개에 동의할 때만
검증자에게 정보를 공개할 것으로 예상됩니다.
위의 예는 완전한 목록이 아니며, 이러한 역할의 사용자들은 자신의 목표를 달성하기 위해
사용하는 소프트웨어에 대해 다양한 다른 기대를 가질 수도 있습니다.
요컨대, 사용자는 소프트웨어가 자신의 최선의 이익에 따라 동작하기를 기대합니다.
이러한 기대를 위반하면 신뢰가 손상되며, 더 신뢰할 수 있는 대안으로 소프트웨어가
대체될 수 있습니다. 구현자는 사용자 신뢰를 보존하는 소프트웨어를 만들 것을 강력히
권장받습니다. 또한 사용자 또는 신뢰할 수 있는 제3자가 소프트웨어가 자신의 최선의 이익에
부합하게 동작하는지 확인할 수 있도록 하는 감사 기능을 포함할 것을 권장받습니다.
독자는 단일 검증자와 여러 보유자에게 서비스를
제공하는 웹사이트와 같은 일부 소프트웨어가 양쪽 역할 모두에 대해
사용자 에이전트로 동작할 수 있지만,
항상 모든 당사자의 최선의 이익에 동시에 부합하도록 동작할 수는 없음을 유의해야 합니다.
예를 들어, 어떤 웹사이트가 여러 보유자 사이에서 사기성
검증 가능한 자격 증명 사용 시도를 감지한다고
가정해 보십시오. 이 경우, 그 웹사이트는 그러한 이상을
검증자에게 보고할 수 있으며,
이는 모든 보유자의 최선의 이익에는 부합하지 않는 것으로 간주될 수 있지만,
검증자와 그러한 위반을 저지르지 않는
모든 보유자의 최선의 이익에는
부합할 수 있습니다. 소프트웨어가 이러한 방식으로 동작할 때는,
웹사이트 이용 정책과 같은 메커니즘을 통해 그 소프트웨어가 누구의 최선의 이익을 위해
동작하는지 명확히 하는 것이 필수적입니다.
8.3 개인 식별
정보
이 절은 비규범적입니다.
credential.credentialSubject 속성에 저장된
검증 가능한 자격 증명과 관련된 데이터는
검증자와 공유될 때 개인정보 침해에 취약합니다.
정부 발급 식별자, 배송 주소 또는 전체 이름과 같은 개인 식별 데이터는
엔터티를 판별하고 추적하며
상관시키는 데 쉽게 사용될 수 있습니다. 생년월일과 우편번호의 조합처럼
개인 식별 정보로 보이지 않는 정보조차도 강력한 상관 및 재식별 능력을 가집니다.
보유자가 사용하는 소프트웨어의 구현자는
이러한 종류의 특성을 가진 데이터를 공유할 때
보유자에게 경고할 것을 강력히 권고받습니다.
발급자는 가능할 때 개인정보 보호형 검증
가능한 자격 증명을 제공할 것을 강력히 권고받습니다.
예를 들어,
검증자가 어떤 엔터티가 적어도 18세인지 판단하려 할 때
사용할 수 있도록, dateOfBirth검증
가능한 자격 증명 대신
ageOver검증 가능한 자격 증명을 발급하는 방식입니다.
검증 가능한 자격 증명은 종종 개인 식별
정보(PII)를 포함하므로, 구현자는 검증 가능한 자격 증명을 저장하고
전송하는 동안 해당 데이터에 접근해서는 안 되는 사람들로부터 데이터를 보호하는
메커니즘을 사용할 것을 강력히 권고받습니다. 고려할 수 있는 메커니즘에는
전송 중 데이터 암호화를 위한 Transport Layer Security (TLS) 또는 다른 수단,
그리고 저장 상태의 검증 가능한 자격 증명의 데이터를 보호하기 위한
암호화 또는 접근 제어 메커니즘이 포함됩니다.
일반적으로 개인은 검증 가능한 자격 증명이,
대부분의 물리적 자격 증명처럼, 공유될 때 개인 식별 정보를 유출할 것이라고
가정할 것을 권고받습니다. 이러한 유출에 대응하기 위해
검증 가능한 자격 증명과 그
보안 메커니즘은 상관을 방지하도록 신중하게 설계되어야 합니다.
개인 식별 정보 유출로부터 보호하도록 특별히 설계된
검증 가능한 자격 증명을 사용할 수 있습니다.
개인과 구현자는 개인 식별 정보를 보호하도록 설계되지 않은 자격 증명 타입보다
이러한 자격 증명 타입을 선택할 것을 권장받습니다.
8.4 식별자 기반 상관
이 절은 비규범적입니다.
검증 가능한 자격 증명은 개인을 상관시키는 데
사용될 수 있는 장기 식별자를 포함할 수 있습니다. 이러한 식별자에는
주체
식별자, 이메일 주소, 정부 발급 식별자, 조직 발급 식별자, 주소,
의료 활력 징후 및 기타 많은 장기 식별자가 포함됩니다.
보유자용 소프트웨어의 구현자는
검증 가능한 자격 증명에서
개인을 상관시키는 데 사용될 수 있는 식별자를 감지하고, 이 정보를 공유하기 전에
보유자에게 경고할 것을 권장받습니다.
이 절의 나머지 부분은 장기 식별자 사용과 관련된 지침을 자세히 설명합니다.
검증 가능한 자격 증명의 주체는 Section 4.4 식별자에 정의되고
credentialSubject.id 속성과 같은 곳에서 사용되는
id 속성을 사용하여 식별됩니다. 주체를 식별하는 데 사용되는 식별자는
식별자가 장기적이거나 둘 이상의 웹 도메인에서 사용될 때 더 큰 상관 위험을 만듭니다.
이 범주에 속하는 다른 유형의 식별자에는 이메일 주소, 정부 발급 식별자,
조직 발급 식별자가 있습니다.
마찬가지로, 예제 3에서처럼
자격 증명 식별자를 공개하면 여러
검증자, 또는 발급자와
검증자가 공모하여
보유자를 상관시킬 수 있는 상황으로 이어질 수 있습니다.
상관을 줄이려는 보유자는
검증 가능한 자격 증명을
발급자로부터 사용할 때,
검증 가능한 프레젠테이션에서
상관 식별자를 선택적으로 공개하는 것을 지원하는 발급자를 사용할 것을 권장받습니다.
이러한 접근 방식은 보유자가 식별자를 생성할 것을 기대하며,
블라인드 서명과 같은 기술을 통해
발급자로부터도 식별자를 숨길 수 있게 할 수 있습니다.
동시에 식별자는 여전히 검증 가능한 자격 증명에 내장되고 서명된 상태로 유지됩니다.
보안 메커니즘 명세 작성자는 선택적으로 공개될 수 없는
상관 식별자의 사용을 피하도록 기술을 설계하여 식별자 기반 상관을 가능하게 하지
않도록 할 것을 권고받습니다.
검증 가능한 자격 증명 시스템에서 강력한 반상관 속성이 필요한 경우,
식별자는 다음 기준 중 하나 이상을 충족해야 하는 것이 필수적입니다.
선택적으로 공개 가능함
단일 출처에 바인딩됨
단일 사용
사용되지 않으며 대신 단기 단일 사용 bearer 토큰으로 대체됨.
8.5 서명 기반 상관
이 절은 비규범적입니다.
검증 가능한 자격 증명의 내용은
보안 메커니즘을 사용하여 보호됩니다.
보안 메커니즘을 나타내는 값은 여러 세션 또는 도메인에서 동일하게 유지될 때
더 큰 상관 위험을 초래합니다. 이러한 값의 예는 다음과 같습니다.
Section
4. 기본 개념 및 Section 5. 고급
개념에서 설명한 것과 같은 여러 확장 지점은,
상대적으로 적은 수의 발급자가 특정 확장 타입 또는 타입 조합을 사용하는 경우,
의도치 않게 또는 바람직하지 않게 상관 메커니즘으로 작용할 수 있습니다.
예를 들어, 특정 국민국가에 고유한 암호학적 방법, 특정 관할권에 특화된
취소 형식, 또는 특정 지역에서 사용하는 자격 증명 타입을 사용하는 것은
보유자가
검증자에게 정보를 선택적으로 공개할 때 기대할 수 있는
가명성을 줄이는 메커니즘으로 작용할 수 있습니다.
발급자는 가명 사용을 목적으로 하는
검증 가능한 자격 증명을 발급할 때,
보유자의 가명성을 줄일 수 있는
확장 타입을 제한함으로써 메타데이터 기반 상관 위험을 최소화할 것을 권장받습니다.
전 세계적으로 채택된 자격 증명 타입, 확장 및 기술 프로파일이 가장 바람직하며,
그다음은 국가적 사용이 있는 것, 지역적 사용만 있는 것이 가장 덜 바람직합니다.
8.7 기기 추적 및
핑거프린팅
이 절은 비규범적입니다.
인터넷과 웹에서 개인을 추적하고 상관시키는
검증 가능한 자격 증명 외부의
메커니즘이 존재합니다. 이러한 메커니즘에는 인터넷 프로토콜(IP) 주소 추적,
웹 브라우저 핑거프린팅, evercookies, 광고 네트워크 추적기,
모바일 네트워크 위치 정보 및 애플리케이션 내 Global Positioning System (GPS) API가 포함됩니다.
검증 가능한 자격 증명을 사용하는 것이
이러한 다른 추적 기술의 사용을 막을 수는 없습니다. 오히려 이러한 기술을
검증 가능한 자격 증명과 함께 사용하면
새로운 상관 가능한 정보가 드러날 수 있습니다. 예를 들어,
생년월일과 GPS 위치가 결합되면 여러 웹사이트에서 개인을 강하게 상관시킬 수 있습니다.
개인정보를 존중하는 시스템은 다른 추적 기술과
검증 가능한 자격 증명의
결합을 방지하는 것을 목표로 해야 합니다. 경우에 따라,
보유자를 대신해
검증 가능한 자격 증명을 전송하는 기기에서
추적 기술을 비활성화해야 할 수 있습니다.
Oblivious HTTP 프로토콜 [RFC9458]은 구현자가
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션과 관련된 외부 리소스를
가져올 때 사용을 고려할 수 있는 한 가지 메커니즘입니다.
Oblivious HTTP는 클라이언트가 원본 서버에 여러 요청을 할 수 있게 하면서,
해당 서버가 그 요청들을 해당 클라이언트에 연결하거나 심지어 단일 클라이언트에서 온 것으로
식별할 수 없도록 하며, 메시지를 전달하는 데 사용되는 노드에는 제한된 신뢰만 부여합니다.
Oblivious HTTP는 기기 추적과 핑거프린팅 가능성을 줄일 수 있는 개인정보 보호 메커니즘 중 하나입니다.
아래는 Oblivious HTTP가 생태계 참여자에게 이점을 제공할 수 있는 구체적인 예입니다.
디지털 지갑을 사용하는 보유자는 자신의 디지털 지갑에 저장된
검증 가능한 자격 증명 내부의 외부 링크에
접근할 때 제3자에게 추적될 가능성을 줄일 수 있습니다.
예를 들어, 디지털 지갑은 링크된 이미지를 가져와 렌더링하거나,
외부로 링크된 취소 목록을 가져와 검증 가능한 자격 증명의 유효성을 확인할 수
있습니다.
발급자는 의도한 목적에 필요한 최소한의 정보 집합으로
검증 가능한 자격 증명에 포함되는 정보를 제한할 것을 권장받습니다.
이는 수신자가 필요한 것보다 더 많은 개인 식별 정보(PII)를 공개하지 않고도
다양한 상황에서 이를 사용할 수 있도록 하기 위한 것입니다. PII를
검증 가능한 자격 증명에 넣지 않는 한 가지 방법은
검증자의 요구를 충족하면서
주체에 대해 지나치게 구체적인 정보를 제공하지 않는
추상 속성을 사용하는 것입니다.
예를 들어, 이 문서는 더 민감한 PII를 나타내는 특정 생년월일 대신
ageOver속성을 사용합니다.
특정 시장의 소매업자가 구매자에게 특정 연령 이상일 것을 일반적으로 요구하는 경우,
그 시장에서 신뢰받는 발급자는 고객의 생일에 대한
클레임을 포함하는
검증 가능한 자격 증명을 제공하기보다,
주체가 그 요구 사항을 충족했다는
검증 가능한 자격 증명을 제공하도록 선택할 수 있습니다.
이러한 관행은 개별 고객이 필요한 것보다 더 많은 PII를 공개하지 않고 구매할 수 있게 합니다.
8.9 데이터
최소화 원칙
이 절은 비규범적입니다.
한 맥락에서 공개된 정보가 다른 맥락으로 유출될 때 개인정보 침해가 발생합니다.
그러한 침해를 방지하기 위해 인정된 모범 사례 중 하나는
검증자가 특정 거래에 절대적으로 필요한
최소한의 정보만 요청하고 수신하도록 제한하는 것입니다. 미국의 Health Insurance Portability and Accountability
Act (HIPAA) 및 유럽연합의 General Data Protection Regulation
(GDPR)을 포함한 여러 관할권의 규정은 이러한 데이터 최소화 접근 방식을 의무화합니다.
검증 가능한 자격 증명에서, 발급자에게 데이터 최소화란
검증 가능한 자격 증명의 내용을
예상되는 사용을 위해 잠재적 검증자가 요구하는 최소한으로 제한하는 것을 의미합니다.
검증자에게
데이터 최소화란 서비스 접근을 위해 요청하거나 요구하는 정보의 범위를 제한하는 것을 의미합니다.
예를 들어, 운전자의 ID 번호, 키, 몸무게, 생일 및 집 주소를
검증 가능한 자격 증명으로 표현한 운전면허증은
사람이 특정 연령 이상임을 확인하는 데 필요한 것보다 더 많은 정보를 포함합니다.
발급자가 정보를 원자화하거나
선택적 공개를 허용하는
보안 메커니즘을 사용하는 것은 모범 사례로 간주됩니다. 예를 들어,
운전면허증의 발급자는 운전면허증에 나타나는 모든 속성을 포함하는
검증 가능한 자격 증명을 발급하고,
보유자가 각 속성을 선택적으로 공개할 수 있게 할 수 있습니다.
또한 더 추상적인 검증 가능한 자격 증명(예:
ageOver 속성만 포함하는 검증 가능한 자격 증명)을 발급할 수도 있습니다.
가능한 한 가지 적응 방식은 발급자가
검증 가능한 자격 증명의 가명 사용을 촉진하는
단일 사용 bearer 자격 증명을 가져오기 위한 보안 HTTP 엔드포인트를 제공하는 것입니다.
이를 비현실적이거나 안전하지 않다고 판단하는 구현자는 증명 시점에
발급자에 대한 의존성을 제거하고,
발급자에 의한
시간적 상관 위험을 줄이는 선택적 공개 방식을 고려할 수 있습니다.
검증자는 특정 거래가 발생하는 데 엄격히 필요한 정보만
요청할 것을 강력히 권고받습니다. 이는 적어도 두 가지 이유에서 중요합니다.
특정 거래에 필요한 정보만 요청함으로써
주체 및/또는
보유자의
개인정보 보호를 향상시킵니다.
보유자가 사용하는 소프트웨어의 구현자는
검증자가 요청하는 정보를 공개하여,
보유자가 거래에 필요하지 않은 특정 정보를
공유하지 않도록 거절할 수 있게 할 것을 권장받습니다. 또한
보유자가 사용하는 소프트웨어의 구현자는
검증자와 공유된 정보의 로그에
보유자가 접근할 수 있게 하여,
특정 거래에 필요한 것보다 더 많은 정보를 공유하도록 강요받았거나 정보 과잉 요청을
당했다고 믿는 경우 보유자가 이 정보를 당국에 제공할 수 있도록 할 것을 권고받습니다.
참고: 최소 공개도 여전히 고유 식별로 이어질 수 있음
최소 공개 원칙을 실천할 수는 있지만, 단일 세션 또는 여러 세션에 걸쳐
특정 사용 사례에서 개인의 강한 식별을 피하는 것은 불가능할 수 있습니다.
이 문서의 작성자들은 실제 시나리오에서 이 원칙을 충족하는 것이 얼마나 어려운지
아무리 강조해도 지나치지 않습니다.
8.10 Bearer 자격 증명
이 절은 비규범적입니다.
bearer 자격 증명은 콘서트 티켓과 같이
그 보유자에게 민감한 정보를 공개할 필요 없이 특정 리소스에 대한
권리를 부여하는 개인정보 보호 강화 정보입니다. 저위험 시나리오에서 엔터티는
여러 보유자가 동일한
검증 가능한 자격 증명을 제시하는 것이 문제가 아니거나
큰 경제적 또는 평판 손실로 이어지지 않는 경우 bearer 자격 증명을 자주 사용합니다.
bearer 자격 증명은 개인정보 보호를 강화하지만,
발급자는 여전히
bearer
자격 증명의 보유자가 기대하는 것보다 더 많은 정보를 의도치 않게 공개하지
않도록 설계에 주의해야 합니다. 예를 들어,
동일한 bearer 자격 증명을 여러 사이트에서
반복 사용하면 해당 사이트들이 공모하여
보유자를 불법적으로 추적하거나 상관시킬 수 있습니다.
마찬가지로, 생년월일과 우편번호처럼 식별 정보가 아닌 것처럼 보이는 정보도
동일한 bearer 자격 증명 또는 세션에서 함께 사용될 때
개인을 통계적으로 식별하는 데 사용될 수 있습니다.
보유자는 자신의 소프트웨어가 민감한 정보를 포함하는
bearer 자격 증명이 발급되었거나 요청되었음을 감지하거나,
하나 이상의 세션에서 둘 이상의 bearer
자격 증명의 조합이 상관 위험을 야기함을 감지하는 경우 경고를 받아야 합니다.
모든 상관 위험을 감지하는 것은 불가능할 수 있지만, 일부는 분명히 감지 가능할 수 있습니다.
검증자는
보유자를
불법적으로 상관시키는 데 사용될 수 있는 정보를 담고 있다고 알려진
bearer
자격 증명을 요청하지 말아야 합니다.
8.11 유효성 확인 중 상관
이 절은 비규범적입니다.
검증 가능한 자격 증명을 처리할 때,
검증자는 해당 클레임에 의존하기 전에 관련
클레임을 평가합니다. 이 평가는 유효성 확인을 수행하는
검증자의 요구 사항을 충족하는 한 원하는 방식으로 수행될 수 있습니다.
많은 검증자는 Appendix A. 유효성 확인에 나열된 검사와
다음과 같은 다양한 특정 비즈니스 프로세스 검사를 수행할 것입니다.
이러한 검사를 수행하는 과정은 정보 유출을 초래하여
보유자의 개인정보 침해로 이어질 수 있습니다.
예를 들어, 잘못 구성된 취소 목록을 확인하는 것과 같은 단순한 작업이
특정 비즈니스가 보유자와 상호작용하고 있을 가능성이 높다는 사실을
발급자에게 알릴 수 있습니다. 이는
발급자들이 공모하여 개인을 본인 모르게 상관시킬 수 있게 합니다.
발급자는
검증 과정에서 개인정보 침해로 이어질 수 있는,
자격 증명마다 고유한
자격 증명 취소 목록과 같은 메커니즘을
사용하지 않을 것을 강력히 권고받습니다.
보유자에게 소프트웨어를 제공하는 조직은
자격 증명이
검증 과정에서 개인정보 침해로 이어질 수 있는 정보를 포함하는 경우 경고해야 합니다.
검증자는 개인정보 침해를 발생시키거나 수준 이하의 개인정보 보호 관행을
가능하게 하는 자격 증명을 거부하는 것을 고려할 것을 강력히 권고받습니다.
귀하가 제어하는 기기에 검증 가능한 자격 증명을
로컬로 저장하고, 귀하의 기대를 넘어 정보를 업로드하거나 분석하지 않는 소프트웨어.
위의 완화책에 더해, 시민 사회와 규제 기관이 공급업체 분석 및 감사에 참여하면,
개인의 최선의 이익에 부합하지 않는 관행으로 영향을 받는 개인을 위해
법적 보호가 제정되고 집행되도록 보장하는 데 도움이 될 수 있습니다.
8.13 자격 증명의 집계
이 절은 비규범적입니다.
동일한 주체에 대한 두 가지 정보가 있으면,
그 두 정보 조각이 서로 다른 채널을 통해 전달되더라도,
그 두 조각의 조합보다 주체에 대해 더 많은 것을 드러내는 경우가 많습니다.
검증 가능한 자격 증명을 집계하는 것은 개인정보 보호 위험을 초래하며,
생태계의 모든 참여자는 데이터 집계의 위험을 인식해야 합니다.
예를 들어, 이메일 주소에 대한 것과 보유자가 21세를 초과했다는 것을 나타내는 것, 두 개의
bearer 자격 증명이
여러 세션에 걸쳐 동일한 검증자에게 제공된다고 가정해 보십시오.
이제 정보의 검증자는 해당 개인에 대한 연령 관련("21세 초과") 정보와 함께
고유 식별자(이메일 주소)를 갖게 됩니다. 이제
보유자에 대한 프로파일을 만들고,
시간이 지남에 따라 유출되는 정보를 계속 추가해 구축하는 것이 쉬워집니다.
이러한 자격 증명의 집계는 여러 사이트가 서로 공모하여 수행할 수도 있으며,
개인정보 침해로 이어질 수 있습니다.
기술적 관점에서 정보 집계를 방지하는 것은 어려운 개인정보 보호 문제입니다.
영지식 증명과 같은 새로운 암호학적 기술이 집계 및 상관 문제의 해결책으로
제안되고 있지만, 장기 식별자와 브라우저 추적 기술의 존재는
가장 현대적인 암호학적 기술조차 무력화합니다.
상관 또는 집계의 개인정보 보호 영향에 대한 해결책은 기술적 성격보다
정책 주도적인 성격을 띠는 경향이 있습니다. 따라서
보유자가 자신의 정보 집계를 피하고자 한다면,
자신이 전송하는 검증 가능한 프레젠테이션에서 이를 표현해야 하며,
자신이 검증 가능한 프레젠테이션을 전송하는
보유자와 검증자도 이를 표현해야 합니다.
8.14 사용 패턴
이 절은 비규범적입니다.
관련된 모든 사람이 개인정보 보호를 보장하기 위해 최선을 다하더라도,
검증 가능한 자격 증명을 사용하면 잠재적으로
재식별과 개인정보 보호의 상실로 이어질 수 있습니다. 이 상관은 다음 중 어느 하나가 발생할 때
일어날 수 있습니다.
동일한 검증 가능한 자격 증명이 서로 다른
검증자에게 제시되고, 해당 검증자들이 공모하거나,
제3자가 두 검증자의 거래 기록에 접근할 수 있습니다.
관찰력이 있는 당사자는
검증 가능한 자격 증명을 제시한 개인이
두 서비스에서 동일한 사람이라고 추론할 수 있습니다. 즉,
같은 사람이 두 계정을 모두 제어한다는 뜻입니다.
자격 증명의 기반 정보는
여러 서비스에서 개인을 식별하는 데 사용될 수 있습니다. 이 경우, 다른 출처의 정보
(보유자가 직접 제공한 정보 포함)를 사용하여,
검증자는
자격 증명 내부의 정보를 사용해
개인을 기존 프로파일과 상관시킬 수 있습니다. 예를 들어,
보유자가 우편번호, 나이, 성별을 포함하는
자격 증명을 제시하면,
검증자는 해당
자격 증명의 주체를
기존 프로파일과 상관시킬 수 있습니다. 자세한 내용은 [DEMOGRAPHICS]를 참조하십시오.
자격 증명의 식별자를 중앙화된 취소 서버에 전달합니다.
중앙화된 서버는 상호작용 전반에서 해당
자격 증명의
사용을 상관시킬 수 있습니다. 예를 들어,
자격 증명이 이러한 방식으로
연령을 증명하는 데 사용되면, 중앙화된 서비스는 해당
자격 증명이
제시된 모든 곳(모든 주류 상점, 바, 성인용품점, 복권 판매점 등)을 알 수 있습니다.
안타깝게도 이러한 완화 기술은 때때로만 실용적이거나 필요한 사용과
호환될 수 있습니다. 때로는 상관이 요구 사항입니다.
예를 들어, 일부 처방약 모니터링 프로그램에서는 처방 사용을 모니터링하는 것이
요구 사항입니다. 집행 기관은 개인이 통제 물질에 대해 여러 처방을 받기 위해
시스템을 속이지 않는다는 것을 확인할 수 있어야 합니다. 처방 사용을 상관시켜야 하는
이러한 법적 또는 규제상 필요는 개인의 개인정보 보호 우려보다 우선합니다.
검증 가능한 자격 증명은 서비스 전반에서
개인을 의도적으로 상관시키는 데도 사용됩니다. 예를 들어, 공통 페르소나를 사용하여
여러 서비스에 로그인하는 경우, 각 서비스의 모든 활동은 의도적으로 동일한 개인에게
연결됩니다. 이러한 각 서비스가 예상된 방식으로 상관을 사용하는 한, 이는
개인정보 보호 문제가 아닙니다.
법적 절차는 발급자, 보유자, 및 검증자에게
법 집행 기관과 같은 당국에 사적 정보를 공개하도록 강제할 수 있습니다.
또한 동일한 사적 정보가 소프트웨어 버그나 보안 실패를 통해 권한 없는 당사자에게
우발적으로 공개될 수도 있습니다. 법적 절차와 준수 체계를 작성하는 사람은
관련 주체의 사적 정보가 의도적으로 또는 우발적으로
제3자에게 공개될 때 이를 통지하도록 요구하는 지침을 작성할 것을 권고받습니다.
소프트웨어 서비스 제공자는 그러한 사적 정보가 제3자와 공유될 수 있는 알려진 상황과
그러한 제3자의 신원에 대해 투명할 것을 권고받습니다.
8.16 잘못된 당사자와
정보 공유
이 절은 비규범적입니다.
보유자가
검증자와 정보를 공유하기로 선택할 때,
검증자가 악의적으로 행동하여
보유자에게 해를 끼칠 수 있는 정보를
요청하는 경우가 있을 수 있습니다. 예를 들어,
검증자가 은행 계좌 번호를 요청하고, 이를 다른 정보와 함께 사용해
보유자 또는 은행을 사기칠 수 있습니다.
발급자는
보유자가 실수로
자격 증명을
잘못된 검증자에게 전송하더라도 상황이 치명적이지 않도록,
가능한 많은 정보를 토큰화하기 위해 노력해야 합니다.
예를 들어, 개인의 은행 잔액을 확인하기 위해 은행 계좌 번호를 포함하는 대신,
검증자가 잔액이 특정 금액 이상인지 확인할 수 있게 하는
토큰을 제공합니다. 이 경우, 은행은 잔액 확인 토큰을 포함하는
검증 가능한 자격 증명을
보유자에게 발급할 수 있습니다.
보유자는 그 후
검증 가능한 자격 증명을
검증 가능한 프레젠테이션에 포함하고,
디지털 서명을 사용하여 토큰을 신용 확인 기관에 바인딩할 수 있습니다.
검증자는 그런 다음
검증 가능한 프레젠테이션을 자신의
디지털 서명으로 감싸고, 계좌 잔액을 동적으로 확인하기 위해 발급자에게 다시 전달할 수 있습니다.
이 접근 방식을 사용하면 보유자가 계좌 잔액 토큰을
잘못된 당사자와 공유하더라도, 공격자는 은행 계좌 번호나 계좌의 정확한 값을 알아낼 수 없습니다.
또한 카운터 서명의 유효 기간을 고려할 때, 공격자는 몇 분 동안만 토큰에 접근할 수 있습니다.
8.17 데이터 절도
이 절은 비규범적입니다.
검증 가능한 자격 증명 및
검증 가능한 프레젠테이션에 표현된 데이터는,
신뢰받는 제3자(예: 발급자) 또는
개인(예: 보유자 또는 주체)이 만든 진정한 진술을
포함하므로 가치가 있습니다. 이 데이터의 저장과 접근성은 악의적 행위자를 위한
민감한 데이터의 허니팟을 의도치 않게 만들 수 있습니다. 이러한 적대자는 종종
그러한 민감한 정보 저장소를 악용하여, 금전적 이익을 위해 데이터를 획득하고 교환하려 합니다.
발급자는
보유자에게
검증 가능한 자격 증명을 발급하고,
그 자격 증명의 상태 및 취소를 관리하는 데 필요한 최소한의 데이터만 보유할 것을
권고받습니다. 마찬가지로,
발급자는 개인 식별 정보(PII) 또는 기타 민감한 데이터를 포함하는
공개적으로 접근 가능한 자격 증명을 만들지 않도록 권고받습니다.
소프트웨어 구현자는 강력한 동의 및 접근 제어 조치를 사용하여
검증 가능한 자격 증명을 보호하고,
권한 없는 엔터티가 접근할 수 없도록 보장할 것을 권고받습니다.
보유자는 전송 중과 저장 중에 데이터를 적절히 암호화하고,
암호학적 비밀과 같은 민감한 자료를 하드웨어 또는 기타 장치에서 쉽게 추출할 수 없는 방식으로
보호하는 구현을 사용할 것을 권고받습니다. 또한
보유자는 데이터에 대한 공격 가능성이나 공격이 성공했을 때
대규모 절도에 포함될 가능성을 줄이기 위해, 중앙화된 시스템에서 벗어나
자신이 제어하는 기기에서만 데이터를 저장하고 조작할 것을 제안받습니다.
또한 보유자는 자신의 자격 증명과 프레젠테이션에 대한 접근을
엄격히 제어하여, 명시적 권한이 있는 사람에게만 접근을 허용할 것을 권장받습니다.
검증자는 특정 거래에 필요한 데이터만 요청하고,
특정 거래의 필요를 넘어서는 데이터를 보유하지 않을 것을 권고받습니다.
규제 기관은 더 나은 개인정보 보호 메커니즘을 사용하여 유사한 집행 및 감사 기능을
달성할 수 있도록 기존 감사 요구 사항을 재고할 것을 권고받습니다.
예를 들어, 개인 식별 정보의 수집과 장기 보존을 고집하는 감사 중심 규정은
동일한 정보가 나중에 손상되어 공격자가 접근할 경우 개인과 조직에 피해를 줄 수 있습니다.
이 명세에서 설명하는 기술은 보유자가
자신과 타인에 대한 속성을 더 쉽게 증명할 수 있게 하여,
검증자의 장기 데이터 보존 필요성을 줄입니다.
대안에는 정보가 수집되고 확인되었다는 로그를 보관하는 것과,
준수 체계가 예상대로 동작하는지 보장하기 위한 무작위 테스트가 포함됩니다.
8.18 클레임 발급 빈도
이 절은 비규범적입니다.
Section 8.14 사용 패턴에서 자세히 설명했듯이,
사용 패턴은 특정 유형의 행동과 상관될 수 있습니다. 이러한 상관은
보유자가
발급자의 인지 없이
검증 가능한 자격 증명을 사용할 때 부분적으로 완화됩니다.
그러나 발급자는 자신의
검증 가능한 자격 증명을
단기 유효하고 자동 갱신되도록 만들어 이 보호를 무력화할 수 있습니다.
예를 들어, ageOver검증 가능한 자격 증명은 바에 입장하는 데 도움이 됩니다.
발급자가 매우 짧은 유효 기간과 자동 갱신
메커니즘을 가진 이러한
검증 가능한 자격 증명을 발급하면,
발급자는
보유자의
행동을 보유자에게 부정적인 영향을 미치는 방식으로
상관시킬 수 있습니다.
보유자에게 소프트웨어를 제공하는 조직은
보유자가 짧은 수명의 자격 증명을 반복적으로 사용하여 행동 상관이 발생할 수 있는 경우
경고해야 합니다. 발급자는 사용 패턴을 상관시킬 수 있게 하는
자격 증명을
발급하지 않아야 합니다.
8.19 단일 사용 자격 증명 선호
이 절은 비규범적입니다.
이상적인 개인정보 보호 시스템은 검증자와의 상호작용에 필요한 정보만
보유자가 공개하도록 요구할 것입니다.
그런 다음 검증자는 공개 요구 사항이 충족되었음을 기록하고
공개된 모든 민감한 정보를 폐기합니다. 많은 경우, 규제 부담과 같은 경쟁 우선순위 때문에
이러한 이상적인 시스템이 사용되지 못합니다. 다른 경우에는 장기 식별자가 단일 사용을
방해합니다. 모든 검증 가능한 자격 증명 생태계의 설계자는
가능할 때마다 단일 사용 검증 가능한 자격 증명을 선호함으로써
가능한 한 개인정보를 존중하도록 만들기 위해 노력해야 합니다.
단일 사용 검증 가능한 자격 증명을 사용하면
여러 이점이 있습니다. 첫 번째 이점은
검증자가
검증 가능한 자격 증명의 데이터가 최신임을 확신할 수 있다는 점입니다.
두 번째 이점은 보유자에게 있습니다.
검증 가능한 자격 증명에 장기 식별자가 없다면,
검증 가능한 자격 증명 자체가 온라인에서 자신을
추적하거나 상관시키는 데 사용될 수 없다는 것을 알기 때문입니다. 마지막으로,
공격자가 훔칠 것이 없으므로 전체 생태계가 더 안전하게 운영될 수 있습니다.
8.20 비공개 브라우징
이 절은 비규범적입니다.
이상적인 비공개 브라우징 시나리오에서는 PII가 전혀 드러나지 않습니다. 많은
자격 증명이 PII를 포함하므로,
보유자에게 소프트웨어를 제공하는 조직은
보유자가 비공개 브라우징 모드에서
자격 증명과
프레젠테이션을 사용할 경우
이 정보가 드러날 가능성에 대해 경고해야 합니다.
각 브라우저 공급업체가 비공개 브라우징을 다르게 처리하고, 일부 브라우저에는
이 기능이 없을 수 있으므로, 구현자가 개인정보 보호를 제공하기 위해
비공개 브라우징 모드에 의존하지 않는 것이 중요합니다. 대신, 구현자는
개인정보 보호 보장을 제공하기 위해 소프트웨어가 직접 사용할 수 있는 도구에
의존할 것을 권고받습니다.
8.21 발급자 협력이
개인정보 보호에 미치는 영향
이 절은 비규범적입니다.
검증 가능한 자격 증명은
발급자에 대한 높은 수준의 신뢰에 의존합니다.
보유자가 가능한 개인정보 보호 기능을 활용할 수 있는 정도는
그러한 기능에 대해 발급자가 제공하는
지원에 크게 좌우되는 경우가 많습니다. 많은 경우, 영지식 증명, 데이터 최소화 기술,
bearer 자격 증명, 추상 클레임 및 서명 기반 상관 방지 기능을 사용하는 개인정보 보호는
발급자의 적극적 지원을 필요로 하며,
발급자는 이러한 기능을 자신이 발급하는
검증 가능한 자격 증명에 통합해야 합니다.
보유자는
보유자와
주체의 개인정보 보호를 보존하는 데 도움이 되는
검증 가능한 자격 증명 기능을 제공하기 위해
발급자의
참여에 의존할 뿐만 아니라, 발급자가 이러한 개인정보 보호 기능을 고의로 훼손하지 않기를
신뢰한다는 점을 유의하는 것이 중요합니다. 예를 들어,
발급자가 서명 기반 상관을 방지하는 서명 방식을 사용하여
검증 가능한 자격 증명에 서명할 수 있습니다.
이는 서명 값이 검증자들 사이에서 공유될 때
보유자가 그 서명 값에 의해 상관되는 것을 방지합니다.
그러나 발급자가
발급된 각 자격 증명에 대해 고유한 키를 생성하면,
검증자가 그렇게 할 수 없더라도,
발급자는 해당
자격 증명의
프레젠테이션을 추적할 수 있을 수 있습니다.
앞서 설명한 개인정보 보호 기능 외에도, 발급자가 제공할 수 있는
기능과 관련하여, 발급자는
자격 증명을 발급할 때
사용하는 식별자와 클레임 타입과 관련하여 자신이 유출하는 데이터를 인식해야 합니다.
한 예로, 발급자가 운전면허증을 발급하면서
자신의 관할 위치와 주체의 거주지를 모두 드러내는 경우가 있습니다.
검증자는 실제로는
자격 증명에 대한 메타데이터, 예를 들어 어떤 발급자가 자격 증명을 발급했는지,
그리고 발급자가 유출했을 수 있는 부수적 정보,
예를 들어 주체의 집 주소에 관심이 있으면서도,
주체가
운전 면허를 받았는지 확인하기 위해 자격 증명을 요청함으로써 이를 이용할 수 있습니다.
이러한 유출을 완화하기 위해 발급자는 특정 위치 정보 또는 기타 민감한 메타데이터를
가리기 위해 공통 식별자를 사용할 수 있습니다. 예를 들어, 카운티, 도시, 마을 또는
기타 더 작은 지방자치단체 수준 대신 주 또는 국가 수준의 공유
발급자 식별자를 사용할 수 있습니다.
또한, 검증자는 정확한
발급자를 공개할 필요 없이,
발급자가 신뢰된 엔터티 집합에 존재한다는
증명을 제공함으로써 개인정보를 보존하기 위해
보유자
증명 메커니즘을 사용할 수 있습니다.
9. 보안 고려 사항
이 절은 비규범적입니다.
발급자, 보유자, 및 검증자는 이 명세에서
설명하는 데이터를 처리할 때 여러 가지 보안 고려 사항을 알고 있어야 합니다.
이 절의 영향을 무시하거나 이해하지 못하면 보안 취약점이 발생할 수 있습니다.
이 절은 광범위한 보안 고려 사항을 강조하지만, 이는 부분적인 목록입니다.
이 명세에서 설명하는 기술을 사용하는 미션 크리티컬 시스템의 구현자는
포괄적인 지침을 얻기 위해 보안 및 암호학 전문가와 상담할 것을 강력히 권장받습니다.
9.1 암호 스위트 및
라이브러리
이 절은 비규범적입니다.
암호학은 이 명세에서 설명하는 데이터 모델의 일부 측면을 보호할 수 있습니다.
구현자는 자격 증명 및
프레젠테이션을 만들고 처리하는 데 사용되는
암호 스위트와 라이브러리를 이해하는 것이 중요합니다. 암호 시스템을 구현하고 감사하는 데는
일반적으로 상당한 경험이 필요합니다. 효과적인
레드팀 활동도
보안 검토에서 편향을 제거하는 데 도움이 될 수 있습니다.
암호 스위트와 라이브러리에는 수명이 있으며, 결국 새로운 공격과 기술 발전에
취약해집니다. 프로덕션 품질 시스템은 이를 고려해야 하며, 만료되었거나 손상된
암호 스위트와 라이브러리를 쉽고 선제적으로 업그레이드하고, 기존
자격 증명을 무효화하고 교체할 수 있는 메커니즘이
존재하도록 보장해야 합니다. 자격 증명을
처리하는 시스템의 장기적 실행 가능성을 보장하기 위해 정기적인 모니터링이 중요합니다.
[NIST-SP-800-57-Part-1]는
개인 서명 키와 공개 검증 키가 제한된 암호 사용 기간을
가져야 한다고 강력히 권고합니다. 여기서 암호 사용 기간은
"특정 키가 정당한 엔터티에 의해 사용되도록 승인된 기간 또는 주어진 시스템의 키가
유효하게 유지되는 기간"입니다. [NIST-SP-800-57-Part-1]는
다양한 조건에서 서로 다른 키 타입에 대한 암호 사용 기간에 관한 광범위한 지침을 제공하고,
개인 서명 키에 대해 1년에서 3년의 암호 사용 기간을 권장합니다.
이 명세의 Section 5.3
관련 리소스의 무결성은 외부 리소스 콘텐츠의 무결성을 보장하기 위한
선택적 메커니즘을 제공합니다. 이 메커니즘은
검증 가능한 자격 증명의 보안에 영향을 미치지 않는
외부 리소스에는 필요하지 않습니다. 그러나 콘텐츠 변경이 잠재적으로 보안 취약점을
초래할 수 있는 외부 리소스에서는 이 메커니즘의 구현이 매우 중요합니다.
구현자는 보호되지 않은 외부 기계 판독 가능 콘텐츠 URL과 관련된 잠재적인 보안 위험을
인식해야 합니다. 이러한 취약점은 애플리케이션에 대한 성공적인 공격으로 이어질 수 있습니다.
외부 리소스의 변경이 보안을 손상시킬 수 있는 경우, 구현자는 이 명세에 설명된
콘텐츠 무결성 보호 메커니즘을 사용함으로써 이점을 얻을 수 있습니다.
9.4 서명되지 않은 클레임
이 절은 비규범적입니다.
이 명세는 서명이나 증명 없이 자격 증명을 만들 수 있게 합니다.
이러한 자격 증명 클래스는 웹 페이지에서 양식을 작성하는 것과
유사하게 중간 저장 또는 자기 주장 정보에 유용한 경우가 많습니다. 구현자는 이러한
자격 증명 타입이
작성자가 알려져 있지 않거나 신뢰할 수 없기 때문에
검증
가능하지 않다는 점을 알아야 합니다.
9.5
중간자(MITM), 재전송 및 복제 공격
이 절은 비규범적입니다.
데이터 모델은 본질적으로
중간자(MITM),
재전송, 및
스푸핑 공격을 방지하지 않습니다.
온라인 및 오프라인 사용 사례 모두 이러한 공격에 취약할 수 있으며, 이 경우 공격자는
전송 또는 저장 중에 검증 가능한 자격 증명 데이터를 가로채고,
수정하고, 재사용하거나 복제합니다.
요청을 검증 가능한 프레젠테이션에 대한 응답과
연결하는 토큰 바인딩 [RFC8471]과
같은 다른 접근 방식도 프로토콜을 보호하는 데 도움이 될 수 있습니다.
보호되지 않은 프로토콜은 모두 중간자 공격에 취약합니다.
9.5.2 재전송 공격
검증자는
검증 가능한 프레젠테이션이 사용될 수 있는
횟수를 제한하고자 할 수 있습니다. 예를 들어, 행사 티켓을 나타내는 동일한
검증 가능한 자격 증명을
여러 개인이 제시해 행사 입장이 허용될 수 있으며, 이는 해당 티켓의
발급자 관점에서 티켓의 목적을
훼손합니다. 이러한 재전송 공격을 방지하기 위해,
검증자는 보유자가 자신의
검증 가능한 프레젠테이션에 추가 보안 조치를
포함하도록 요구합니다. 예는 다음과 같습니다.
검증자는 보유자가
검증 가능한 프레젠테이션 내부의
클레임을 제시할 권한이 있음을 아는 데 이해관계가 있을 수 있습니다.
데이터 모델은 검증 가능한 자격 증명에 필요한 구조와
데이터 요소를 개략적으로 설명하지만, 제시된 자격 증명의
권한을 확인하는 메커니즘은 포함하지 않습니다. 이 문제를 해결하기 위해,
구현자는 검증 가능한 자격 증명을 강력한 인증 메커니즘에
바인딩하거나, 제어 증명을 가능하게 하기 위해
검증 가능한 프레젠테이션에
추가 속성을 사용하는 등의 보완 방법을 탐색해야 할 수 있습니다.
9.6 종속 클레임 묶기
이 절은 비규범적입니다.
발급자가
자격 증명 안의 정보를 원자화하거나 선택적 공개를 허용하는
서명 방식을 사용하는 것은 모범 사례로 간주됩니다. 정보를 원자화할 때,
발급자가 이를 안전하게 수행하지 않으면,
보유자는
서로 다른 자격 증명의
클레임을
발급자가
의도하지 않은 방식으로 함께 묶을 수 있습니다.
어떤 대학이 한 개인에게 두 개의 검증 가능한 자격 증명을
발급한다고 생각해 보십시오.
각 자격 증명에는 결합될 때 특정 "학과"에서 그 사람의
"역할"을 나타내는 두 속성이 포함됩니다. 예를 들어, 한
자격 증명
쌍은 "Department of Computing"의 "Staff Member"를 지정할 수 있고,
다른 쌍은 "Department of Economics"의 "Post Graduate Student"를 나타낼 수 있습니다.
이러한 검증 가능한 자격 증명을
원자화하면 대학은 해당 개인에게 네 개의 별도
자격 증명을 발급하게 됩니다. 각
자격 증명은
"Staff Member", "Post Graduate Student", "Department of Computing", 또는
"Department of Economics"라는 단일 지정을 포함합니다. 그러면
보유자는
"Staff Member"와 "Department of Economics" 검증
가능한 자격 증명을
검증자에게 제시할 수 있으며, 둘을 함께 보면 거짓
클레임이 됩니다.
9.7 고도로 동적인 정보
이 절은 비규범적입니다.
검증 가능한 자격 증명이 고도로 동적인 정보를 포함할 때,
유효 기간에 대한 신중한 고려가 매우 중요해집니다. 의도된 사용 범위를 넘어서는
유효 기간을 가진 검증 가능한 자격 증명을 발급하면
악의적 행위자가 악용할 수 있는 잠재적 보안 취약점이 생깁니다.
검증 가능한 자격 증명이 표현하는 정보가
사용될 것으로 예상되는 기간보다 짧은 유효 기간은
보유자 및 검증자에게 부담을 줍니다.
따라서 사용 사례와 검증 가능한 자격 증명에 포함된 정보의 예상 수명에
적절한 검증 가능한 자격 증명의 유효 기간을 설정하는 것이 중요합니다.
9.8 기기 도난 및 사칭
이 절은 비규범적입니다.
검증 가능한 자격 증명을 기기에 저장하는 것은
기기를 분실하거나 도난당한 경우 위험을 초래합니다. 이러한 기기를 손에 넣은 공격자는
잠재적으로 피해자의 검증 가능한 자격 증명을 사용하는 시스템에
무단 접근할 수 있습니다. 이러한 유형의 공격을 완화하는 방법에는 다음이 포함됩니다.
또한 사칭 사례는 엔터티가 자신의 행위를 부인하려는
상황을 포함하여 다양한 형태로 나타날 수 있습니다.
검증 가능한 자격 증명 영역에서 신뢰와 보안을
높이는 것은 사칭을 피하는 것 이상을 의미합니다. 여기에는 부인 방지 메커니즘을
구현하는 것도 포함됩니다. 이러한 메커니즘은
엔터티가
자신의 행위 또는 거래에 대해 책임을 지도록 확고히 하여 책임성을 강화하고
악의적 행동을 억제합니다. 부인 방지의 달성은 다면적인 작업으로,
보안 메커니즘, 소유 증명 및 신뢰와 신뢰성을
촉진하도록 설계된 다양한 프로토콜의 인증 방식 등 여러 기술을 포괄합니다.
9.9 허용 가능한 사용
이 절은 비규범적입니다.
엔터티의 행위 —
예를 들어 프레젠테이션 — 와
그 행위의 의도된 목적 사이의 정렬을 보장하는 것은 필수적입니다. 이는
검증 가능한 자격 증명을 사용할
권한을 갖고, 자격 증명을 지정된 범위와 목적에 부합하는 방식으로
사용하는 것을 포함합니다. 이 맥락에서 두 가지 중요한 측면은
무단 사용과 부적절한 사용입니다.
9.9.1 무단 사용
의도된 목적을 벗어나 검증 가능한 자격 증명 및 검증 가능한 프레젠테이션을 사용하는 엔터티는
무단 활동을 하는 것입니다. 무단 사용의 한 유형은 기밀성 위반입니다. 어떤
보유자가 자신의 나이와 거주 상태를 확인하기 위해
검증 가능한 프레젠테이션을
검증자와 공유한다고 생각해 보십시오. 그 후
검증자가
데이터를 데이터 브로커에게 판매하는 것처럼 적절한 동의 없이
보유자의 데이터를 사용한다면, 이는 데이터의 무단 사용에 해당하며,
보유자가 해당 거래에서 가질 수 있는
개인정보 보호 기대를 위반하는 것입니다.
마찬가지로, 발급자는 termsOfUse
속성을 사용하여 보유자가
자격 증명을 언제 어떻게 사용하도록 허용되고 기대되는지
지정할 수 있습니다. termsOfUse에 정의된 범위 밖에서
자격 증명을 사용하는
보유자는
무단으로 간주됩니다.
참고: 디지털 권리 관리는 범위 밖임
보유자가
프레젠테이션 이후 자신의 데이터에 대한
승인된 사용을 어떻게 주장하고 집행할 수 있는지를 결정하려면 추가 연구가 필요합니다.
9.9.2 부적절한 사용
유효한 암호학적 서명과 성공적인 상태 검사는
자격 증명의 신뢰성을 의미하지만,
모든 자격 증명이 모든 맥락에서 서로 대체 가능하다는 뜻은 아닙니다.
검증자는 또한 관련
클레임을 유효성 확인하고,
보유자가
자격 증명을
제시하는 목적과 함께 클레임의 출처와 성격을 고려하는 것이
중요합니다.
예를 들어, 공인된 의료 진단이 필요한 시나리오에서는 필요한 데이터를 담고 있는
자기 주장 자격 증명이 권위 있는 의료 출처의 유효성을
갖추고 있지 않기 때문에 충분하지 않을 수 있습니다. 적절한
자격 증명 사용을 보장하기 위해, 이해관계자는
의도된 적용의 특정 맥락 안에서
자격 증명의 관련성과 권위를
평가해야 합니다.
9.10 코드 주입
이 절은 비규범적입니다.
검증 가능한 자격 증명의 데이터에는 주입 가능한 코드나
스크립팅 언어의 코드가 포함될 수 있습니다. 검증 가능한 자격 증명의 작성자는
필요한 경우가 아니고 관련 위험을 가능한 한 최대한 완화한 후가 아니라면
이러한 포함을 피하는 것이 좋습니다.
예를 들어, 여러 언어 또는 주석을 포함하는 단일 자연어 문자열은 올바른 표시를 위해
추가 구조나 마크업을 필요로 하는 경우가 많습니다. HTML과 같은 마크업 언어는
서로 다른 언어의 텍스트 범위에 레이블을 붙이거나
양방향 텍스트를
제대로 표시하는 데 필요한 문자열 내부 마크업을 제공할 수 있습니다.
또한 rdf:HTML 데이터 타입을 사용하여 이러한 값을 JSON-LD에서
정확하게 인코딩할 수도 있습니다.
정보를 HTML로 인코딩할 수 있음에도 불구하고, 구현자는 다음 이유로 그렇게 하지 않을 것을
강력히 권고받습니다.
어떤 버전의 HTML 처리기가 필요하며, 이는 언어와 기본 방향 정보를 처리하는 부담을 증가시킵니다.
이 데이터 모델을 사용할 때 보안 공격 표면을 증가시킵니다.
HTML을 순진하게 처리하면 데이터 생성 과정의 어느 시점에서 공격자가 주입한
script 태그가 실행될 수 있기 때문입니다.
구현자가 특정 사용 사례를 해결하기 위해 HTML 또는 실행 가능한 스크립트를 포함할 수 있는
다른 마크업 언어를 사용해야 한다고 느끼는 경우, 공격자가 해당 마크업을 사용해
마크업 소비자에 대해 주입 공격을 수행할 수 있는 방식을 분석할 것을 권고받습니다.
이 분석 이후에는 네트워크에 접근할 수 없는 샌드박스에서 HTML 렌더링 엔진을 실행하는 것과 같이
식별된 공격에 대한 완화책을 선제적으로 배포해야 합니다.
10. 접근성 고려 사항
이 절은 비규범적입니다.
구현자는 이 명세에서 설명하는 데이터를 처리할 때 여러 접근성 고려 사항을
알고 있어야 합니다. 어떤 웹 표준이나 프로토콜을 구현할 때와 마찬가지로,
접근성 문제를 무시하면 이 정보를 인구의 상당 부분이 사용할 수 없게 됩니다.
능력에 관계없이 모든 사람이 이 데이터를 사용할 수 있도록 [WCAG21]와 같은
접근성 지침과 표준을 따르는 것이 중요합니다.
이는 역사적으로 보조 기술에 문제를 일으켜 온 암호학을 사용하는 시스템을
구축할 때 특히 중요합니다.
이 절은 이 데이터 모델을 사용할 때 고려해야 하는 일반적인 접근성 고려 사항을
자세히 설명합니다.
10.1 데이터 우선 접근 방식
이 절은 비규범적입니다.
정부 신분증과 같이 오늘날 사용되는 많은 물리적
자격 증명은 작은 글자, 작고 고해상도 이미지에 대한 의존,
시각 장애가 있는 사람을 위한 어포던스 부재 등을 포함하되 이에 국한되지 않는
낮은 접근성 특성을 가집니다.
이 데이터 모델을 사용하여 검증 가능한 자격 증명을 만들 때,
데이터 모델 설계자는 데이터 우선 접근 방식을 사용할 것을 제안받습니다.
예를 들어, 자격 증명을 묘사하기 위해 데이터 또는 그래픽 이미지를
선택할 수 있다면, 설계자는 기관 이름이나 전문
자격 증명과 같은
이미지의 모든 요소를, 이 정보를 전달하기 위해 보는 사람의 이미지 해석에 의존하는 대신
기계 판독 가능한 방식으로 표현해야 합니다. 데이터 우선 접근 방식을 사용하는 것이
선호되는 이유는 다양한 능력을 가진 사람들을 위한 서로 다른 인터페이스를 구축하는
기초 요소를 제공하기 때문입니다.
11. 국제화
고려 사항
이 절은 비규범적입니다.
구현자는 이 명세에서 설명하는 데이터를 게시할 때 여러 국제화 고려 사항을
인식할 것을 권고받습니다.
어떤 웹 표준이나 프로토콜 구현에서와 마찬가지로, 국제화를 무시하면
서로 다른 언어와 사회 전반에서 데이터를 생산하고 소비하기 어렵게 되어,
명세의 적용 가능성이 제한되고 표준으로서의 가치가 크게 줄어듭니다.
구현자는 W3C Internationalization Activity가
게시한 Strings on the Web: Language and Direction Metadata 문서
[STRING-META]를
읽을 것을 강력히 권고받습니다. 이 문서는 국제화를 지원하기 위해 텍스트에 대한
신뢰할 수 있는 메타데이터를 제공해야 할 필요성을 자세히 설명합니다. 국제화
고려 사항에 관한 최신 정보는 Verifiable Credentials Implementation Guidelines
[VC-IMP-GUIDE] 문서도
읽을 것을 구현자에게 권고합니다.
이 절은 이 데이터 모델을 사용할 때 고려해야 할 일반적인 국제화 고려 사항을
개괄하며, 구현자가 읽는 데 관심이 있을 수 있는
Strings on the Web: Language and Direction Metadata
문서 [STRING-META]의
특정 부분을 강조하기 위한 것입니다.
11.1 언어와 기본 방향
데이터 게시자는 Strings on the Web: Language and Direction
Metadata 문서 [STRING-META]의
Cross-Syntax Expression 절을 읽어,
언어와 기본
방향 정보를
[JSON-LD11], [JSON],
및 CBOR [RFC7049]와 같은
여러 표현 구문에서 표현할 수 있도록 할 것을 강력히 권장받습니다.
일반적인 설계 패턴은 언어가 태그되어 있고 선택적으로 특정 기본 방향이
지정된 텍스트 문자열을 표현할 때 다음 마크업 템플릿을 사용하는 것입니다.
문자열 값 대신 언어 값 객체가 사용되는 경우, 그 객체는 값이 문자열인
@value 속성을 포함해야 MUST 하며,
[BCP47]에 정의된
올바른 형식의 Language-Tag를 포함하는 문자열 값을 가진
@language 속성을 포함하는 것이 SHOULD 되며,
[JSON-LD11]의 @direction 속성에 의해
정의된 기본 방향 문자열
값을 가진
@direction 속성을 포함할 수 MAY 있습니다.
언어 값 객체는 @value, @language, 및 @direction 이외의
다른 키를 포함해서는 안 됩니다 MUST
NOT.
위의 설계 패턴을 사용하여, 다음 예제는 텍스트 방향을 지정하지 않고
영어로 책 제목을 표현합니다.
"title": [
{
"@value": "HTML and CSS: Designing and Creating Websites",
"@language": "en"
},
{
"@value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"@language": "ar",
"@direction": "rtl"
}
]
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://achievement.example/multilingual/v2"
],
"type": [ "VerifiableCredential", "ExampleAchievementCredential" ],
"issuer": {
"id": "did:example:2g55q912ec3476eba2l9812ecbfe",
"type": "Profile"
},
"validFrom": "2024-03-14T22:32:52Z",
"validUntil": "2025-01-01T00:00:00Z",
"credentialSubject": {
"type": [ "AchievementSubject" ],
"achievement": {
"id": "urn:uuid:9a652678-4616-475d-af12-aca21cfbe06d",
"type": [ "Achievement" ],
"name": {
"en": "Successful installation of the Example application",
"es": "Instalación exitosa de la aplicación Example"
},
"criteria": {
"narrative": {
"es": "Instaló exitosamente de la aplicación Example.",
"en": "Successfully installed the Example application."
}
}
}
}
}
11.2 기본
언어와 방향 제공
각 자연어 문자열 속성 값의 언어와 기본 방향은
각 속성 값에 대한 언어 값 구조를 통해 또는 전체 자격 증명 안의 모든 값에 대한
기본 언어 및 기본 방향을 통해 제공되는 것이 SHOULD 됩니다.
값별 언어 값 구조를 사용하는 것이 선호됩니다. 문서 기본값을 사용하면
하위 처리기가 JSON-LD 확장 기반 변환을 수행해야 하는 요구 사항이 생길 수 있으며,
이는 그렇지 않으면 선택 사항이기 때문입니다. 자세한 내용은 [JSON-LD11] 명세의
문자열 국제화 절을 참조하십시오. 연결된 언어가 없는 자연어 문자열 값은
언어 값이 undefined
(언어 태그 "und")인 것처럼 처리되는 것이 SHOULD 됩니다.
연결된 기본 방향이 없는 자연어 문자열 값은 방향 값이
"auto"인 것처럼 처리되는 것이 SHOULD 됩니다.
A. 유효성 확인
이 절은 비규범적입니다.
이 명세는 검증 가능한 자격 증명 또는
검증 가능한 프레젠테이션의
유효성 확인 과정에 대한 적합성 기준을 제공하지 않지만,
독자는 이 데이터 모델의 정보가 검증자가
유효성 확인 과정에서 어떻게 사용할 것으로
예상되는지 궁금할 수 있습니다. 이 절은 이 명세의 속성을
검증자가 사용하는 예상 방식과 관련하여
워킹 그룹에서 나눈 대화 중 일부를 담고 있습니다.
검증자가 특정 타입의
검증 가능한 자격 증명을 요청할 때,
그 타입과 관련된 필수 및 선택
클레임의 집합이 있습니다.
필수 클레임이 포함되지 않으면
검증자의
검증 가능한 자격 증명 유효성 확인은 실패하며,
특정 타입과 관련이 없는 모든 클레임은 무시됩니다.
다시 말해, 검증자는 자신이 받은
검증 가능한 자격 증명에 대해 입력 유효성 확인을 수행하고,
자격 증명 타입 명세에 따라 잘못된 형식의 입력을 거부합니다.
issuer속성과 관련된 메타데이터는
Section 7.1 검증에 정의된
검증 알고리즘을 통해
검증자가 사용할 수 있습니다.
이 메타데이터에는 각 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 보호하기 위해
보안 메커니즘이 사용한 검증 방법의 검증된 컨트롤러 식별이 포함되며,
그 컨트롤러는 일반적으로 각각의 issuer 또는 holder입니다.
일부 생태계는 발급자와
검증 방법의 컨트롤러 사이에 더 복잡한 관계를 가질 수 있으며, 위에 설명된 매핑에
더하여 또는 그 대신 검증된 발급자 목록을 사용할 수 있습니다.
holder속성의 값으로 식별되는
보유자에 관한 관련 메타데이터는
종종 검증자가 사용할 수 있거나 검색할 수 있습니다.
예를 들어, 보유자는
검증 가능한 프레젠테이션을 보호하는 데 사용되는
검증 자료를 포함하는 정보를 게시할 수 있습니다.
이 메타데이터는 검증 가능한 프레젠테이션의 증명을 검사할 때
사용됩니다.
일부 암호학적 식별자는 식별자 자체에 필요한 모든 메타데이터를 포함합니다.
이 경우 추가 메타데이터는 필요하지 않습니다. 다른 식별자는 그러한 메타데이터가
보유자의 추가 조치 없이
검증자가 사용하도록 자동 게시되는 검증 가능한 데이터 레지스트리를
사용합니다.
유효성 확인은 검증자가 특정 검증 가능한 자격 증명 사용의 적절성을
평가하기 위해 비즈니스 규칙을 적용하는 과정입니다.
검증자는 주어진
검증 가능한 프레젠테이션을 복잡한 비즈니스 규칙에
따라 유효성 확인해야 할 수 있습니다. 예를 들어, 검증자는
보유자가 검증
가능한 자격 증명의
주체와
같은 엔터티라는 확신이 필요할 수 있습니다. 이러한 상황에서 다음 요소들은
검증자에게, 포함된
검증 가능한 자격 증명에서
해당 식별자와 관련해 표현된 클레임이 실제로 현재 제시자에 관한 것이라는
합리적인 확신을 제공할 수 있습니다.
검증 가능한 프레젠테이션의
holder 속성 안의 식별자와 credentialSubject 배열 안의
하나 이상의 객체에 있는 하나 이상의 식별자 속성이 동일합니다.
그 공통 식별자는 해당 검증 가능한 프레젠테이션의 무결성을 검증하는 데
사용되는 검증 자료를 발견하거나 파생하는 데 사용될 수 있습니다.
A.5 발급일
이 절은 비규범적입니다.
validFrom은
검증자가 예상하는 범위 안에 있을 것으로 기대됩니다.
예를 들어, 검증자는
검증 가능한 자격 증명의
유효 기간 시작 시점이 미래가 아닌지 확인할 수 있습니다.
A.6 증명(서명)
이 절은 비규범적입니다.
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 정보가 변조되지 않았음을
증명하는 데 사용되는 보안 메커니즘을
암호학적 증명이라고 합니다. 암호학적 증명에는 디지털 서명과 영지식 증명을
포함하되 이에 국한되지 않는 여러 타입이 있습니다. 일반적으로 암호학적 증명을
검증할 때, 구현은 다음을 보장할 것으로 예상됩니다.
암호학적 증명 검증 알고리즘을 데이터에 적용했을 때
허용된 암호학적 증명이 결과로 나옵니다.
일반적으로 디지털 서명을 검증할 때, 구현은 다음을 보장할 것으로 예상됩니다.
서명과 연결된 검증 자료에 관한 충분히 최신의
메타데이터를 사용할 수 있습니다. 예를 들어,
검증 자료가 암호학적 공개 키인 경우,
메타데이터에는 유효 기간, 컨트롤러, 또는 암호학적 공개 키의 인증이나 암호화와 같은
승인된 목적과 관련된 속성이
포함될 수 있습니다.
공개 키가 정지, 취소 또는 만료되지 않았습니다.
디지털 서명이 검증됩니다.
보안 메커니즘이 정의한 모든 추가 요구 사항이 충족됩니다.
A.7 유효 기간
이 절은 비규범적입니다.
검증자는 validFrom 및
validUntil 속성이 특정 범위 안에 있을 것으로 기대합니다. 예를 들어,
검증자는
검증 가능한 자격 증명의 유효 기간 종료 시점이
과거가 아닌지 확인할 수 있습니다. 일부 자격 증명은 원래 유효 기간이 만료된 후에도
부차적 목적에 유용할 수 있으므로, validFrom 및
validUntil 속성을 사용하여 표현되는 유효 기간은 항상
검증 이후에 수행되는 유효성 확인의 구성 요소로 간주됩니다.
credentialSchema 속성을 사용할 수 있는 경우,
검증 가능한 자격 증명의 스키마는
검증자가 해당
검증 가능한 자격 증명에 대한
credentialSchematype 정의와
검증자 자신의 스키마 평가 기준에 따라 평가할 것으로
예상됩니다. 예를 들어, credentialSchema의 type
값이 [VC-JSON-SCHEMA]인 경우,
검증자는 자격 증명의 데이터가 주어진 JSON Schema에
대해 유효한지 확인할 수 있습니다.
A.10 목적 적합성
이 절은 비규범적입니다.
목적 적합성은 검증 가능한 자격 증명 안의 사용자 정의
속성이
검증자의 목적에 적합한지에 관한 것입니다.
예를 들어, 검증자가
주체가 21세보다 많은지 판단해야 하는 경우,
특정 birthdate속성에 의존하거나, ageOver와 같은
더 추상적인 속성에 의존할 수
있습니다.
발급자는 해당
클레임을 할 수 있는 존재로
검증자에게
신뢰됩니다. 예를 들어, 프랜차이즈 패스트푸드점 지점은 프랜차이즈 본사가 제시한
할인 쿠폰 클레임을 신뢰합니다.
검증 가능한 자격 증명 안에서
발급자가 표현한 정책 정보는
보유자와
검증자가 그 정책을 무시하는 책임을 받아들이지 않는 한
존중되어야 합니다.
A.11 "인공
지능" 및 "기계 학습"
이 절은 비규범적입니다.
오늘날 일반적으로 "인공 지능" 및/또는 "기계 학습"이라고 불리는 것을 사용하는
시스템은 인간의 수행 수준을 충족하거나 초과하는 수준으로 복잡한 작업을 수행할 수
있을지도 모릅니다. 여기에는 검증 가능한 자격 증명의
획득과 사용과 같은 작업이 포함될 수 있습니다. 예를 들어 오늘날
CAPTCHA에서 흔히 수행되는 것처럼,
이러한 작업을 사용해 인간과 자동화된 "봇" 활동을 구분하는 것은 그로 인해
적절하거나 허용 가능한 보호를 더 이상 제공하지 못할 수 있습니다.
검증 가능한 자격 증명을 사용하거나
그 내용에 대해 유효성 확인을 수행하는 보안 아키텍처의 구현자는, 오늘날 일반적으로
"인공 지능"이라고 불리는 것과 같은 기계 기반 행위자가 다른 시스템과의 상호작용에
사용하기 위해 합법적으로 검증 가능한 자격 증명을 보유할 수 있음을
고려할 것을 권고받습니다. 구현자는 또한 위협 행위자가 이러한 "인공 지능"
시스템을 검증 가능한 자격 증명과 결합하여
자신들의 시스템과 상호작용할 때 인간으로 가장할 수 있는 방식도 고려할 수 있습니다.
그러한 시스템에는 소셜 미디어, 선거, 에너지 분배, 공급망 및 자율주행차 시스템과 같은
전 세계 인프라가 포함될 수 있으나 이에 국한되지는 않습니다.
B. 컨텍스트,
어휘, 타입 및 자격 증명 스키마
B.1 기본 컨텍스트
구현은 https://www.w3.org/ns/credentials/v2에 위치한 기본 컨텍스트 값을
이미 검색된 것으로 취급해야 MUST 합니다.
다음 값은 기본 컨텍스트 파일의 16진수로 인코딩된 SHA2-256 다이제스트 값입니다.
59955ced6697d61e03f2b2556febe5308ab16842846f5b586d7f1f7adec92734.
최신 Unix 명령 인터페이스 줄에서 다음 명령을 실행하여 위의 암호학적
다이제스트를 확인할 수 있습니다.
curl -s https://www.w3.org/ns/credentials/v2 | openssl dgst -sha256.
애플리케이션에서 사용하는 모든 JSON-LD 컨텍스트 URL은 종단 간 보안을
보장하기 위해 동일한 메커니즘 또는 기능적으로 동등한 메커니즘을 사용하는 것이
강력히 권고됩니다. 구현은 리소스의 암호학적 해시 값이 예상 해시 값과
일치하지 않는 경우 오류를 발생시킬 것으로 예상됩니다.
위의 기본 컨텍스트뿐만 아니라 @context 속성 안의 다른 컨텍스트와 값을,
JSON-LD 확장 또는
RDF로의 변환과 같은 작업 중에 적용하는 구현은 오류 없이 이를 수행할 것으로
예상됩니다. 이러한 작업이 수행되어 오류가 발생하는 경우,
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션은 검증 실패가
되어야 MUST 합니다.
참고: 해시 값 변경이 감지되면 정오표를 참조하십시오
이 명세에서 암호학적 해시 값이 연결된 파일이 변경될 가능성은 극히 낮습니다.
그러나 명세에서 중요한 정오표가 발견되고 생태계 안정성을 보장하기 위해
수정이 필요한 경우, 암호학적 해시 값이 변경될 수 있습니다. 따라서 해당 파일의
HTTP 캐시 시간은 무한대로 설정되지 않으며, 구현자는 암호학적 해시 값 변경이
감지되면 정오표를 확인할 것을 권고받습니다.
JSON-LD 컨텍스트와 같이 외부 URL에 대한 링크에 의미가 의존하는 자격 증명 안의
콘텐츠. 이는 로컬 정적 사본 또는 파일의 암호학적 다이제스트를 사용하여
보호할 수 있습니다. 자세한 내용은 Section
5.3 관련 리소스의 무결성을 참조하십시오.
검증자는 URL을 통해 링크된 리소스와 같이
자격 증명 내부에서 참조되는 다른 데이터가 기본적으로
암호학적으로 보호되지 않는다는 점을 경고받습니다. 영구적으로 캐시된 파일 및/또는
암호학적 해시를 사용하여, 검증 가능한 자격 증명의
보안에 중요한 모든 URL에 동일한 종류의 보호가 제공되도록 하는 것이 모범 사례로
간주됩니다. 궁극적으로 링크된 외부 콘텐츠의 암호학적 다이제스트를 알면
검증자가
그 콘텐츠가 발급자 또는 보유자가 의도한 것과
동일한지 확인할 수 있습니다.
B.2 어휘
RDF 어휘 처리에 의존하는 구현은 JSON-LD 직렬화를 로드할 때 기본 컨텍스트에서
사용되는 다음 어휘 URL이 궁극적으로 다음 파일로 해석되도록 보장해야 MUST
하며, 이 파일들은 규범적입니다. 어휘 파일의 의미상 동등한 다른 직렬화는
구현에서 사용될 MAY 있습니다. 각 JSON-LD 문서에는
개발자가 각 파일의 내용이 올바른지 확인할 수 있도록 암호학적 해시가 제공됩니다.
위에 나열된 암호학적 다이제스트는 최신 UNIX 계열 OS 명령줄 인터페이스에서
다음과 같은 명령을 실행하여 확인할 수 있으며,
<DOCUMENT_URL>을 적절한 값으로 대체합니다.
curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256
참고: schema.org는 정기적으로 변경되지만 안정적인 것으로 간주됩니다
구현자와 문서 작성자는 schema.org에 대한 암호학적 다이제스트가
제공되지 않는다는 점에 유의할 수 있습니다. 이는 schema.org 어휘가
정기적으로 변경되기 때문입니다. 제공된 다이제스트는 게시 후 몇 주 안에
최신 상태가 아니게 됩니다. 워킹 그룹은 이 우려를 논의했고, 이 명세에서 사용되는
schema.org의 어휘 용어가 수년 동안 안정적이었으며 의미가 변경될
가능성이 매우 낮다고 결론지었습니다.
이 명세에서는 그러한 정의의 이점을 얻는 처리기 및 다른 명세를 위해 다음 기본 클래스를
정의합니다.
type 속성은 그것이 나타나는
검증 가능한 자격 증명의 타입을 고유하게
식별하는 데 사용됩니다. 즉, 검증 가능한 자격 증명이 포함하는
클레임 집합을 나타냅니다. 이 속성과 그 값 집합 안의
VerifiableCredential 값은 필수입니다.
이 검증 가능한 자격 증명의
고유한 하위 타입을 나타내는 추가 값을 하나 포함하는 것이 좋은 관행이지만,
배열에서 생략하거나 추가 타입 값을 포함하는 것도 허용됩니다. 많은 검증자는
특정 하위 타입의 검증 가능한 자격 증명을 요청하므로,
하위 타입 값을 생략하면 검증자가 보유자에게 어떤
검증 가능한 자격 증명을 요구하는지
알리는 것이 더 어려워질 수 있습니다. 검증 가능한 자격 증명에 여러 하위 타입이 있는 경우,
type 속성에 모두 나열하는 것이 타당합니다.
검증 가능한 자격 증명의
[JSON-LD11] 표현에서
type 속성을 사용하면 기계가 의미를 검사할 수 있기 때문에
검증 가능한 자격 증명의
의미를 강제할 수 있습니다. [JSON-LD11]에서 이 기술은 클레임 집합의
범주화를 설명할 뿐만 아니라, 그래프 안 속성들의 하위 그래프 구조와 의미도 전달합니다.
[JSON-LD11]에서 이는 그래프 안
노드의 타입을 나타내므로, 검증 가능한 자격 증명의 일부
[JSON-LD11] 표현은
검증 가능한 자격 증명 안의 많은 객체에서
type 속성을 사용합니다.
[JSON-LD11]
관점에서 @context 속성의 주된 목적은
검증 가능한 자격 증명 안 데이터의 의미와
데이터의 용어 정의를 기계 판독 가능한 방식으로 전달하는 것입니다.
@context 속성은 검증 가능한 자격 증명 및 검증 가능한 프레젠테이션의 속성에 대한
전역적으로 고유한 URL을 짧은 별칭 이름으로 매핑하여,
[JSON-LD11] 표현을
사람이 읽기 더 쉽게 만듭니다. [JSON-LD11] 관점에서 이 매핑은
자격 증명 안의 데이터가 기계 판독 가능한 데이터 네트워크에서
모델링될 수 있게 하며, 검증 가능한 자격 증명 또는
검증 가능한 프레젠테이션 안의 데이터가 더 큰
기계 판독 가능한 데이터 그래프와 어떻게 관련되는지를 강화합니다.
이는 당사자들이 조율할 수 없는 생태계에서 데이터의 의미를 다른 데이터와 어떻게
관련시킬지 기계에 알려주는 데 유용합니다. 이 속성은 집합의 첫 번째 값이
https://www.w3.org/ns/credentials/v2인 상태로 필수입니다.
@context 속성은 데이터를 그래프 데이터 모델에 매핑하는 데 사용되고,
[JSON-LD11]의
type 속성은 그래프 안의 노드를 설명하는 데 사용되므로,
두 속성을 함께 사용할 때 type 속성은 더욱 중요해집니다. 예를 들어,
[JSON-LD11]를 사용하여
해석된 @context 리소스 안에 type 속성이 포함되어 있지 않으면,
검증 가능한 자격 증명의
생성 및 소비 중에 클레임이 삭제되거나 그 무결성이 더 이상 보호되지 않을 수 있습니다.
또는 검증 가능한 자격 증명의 생성 또는 소비 중에
오류가 발생할 수 있습니다. 이는 구현의 설계 선택에 따라 달라지며,
오늘날 구현에서는 두 경로가 모두 사용되므로,
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의
[JSON-LD11] 표현을 사용할 때 이러한 속성에
주의하는 것이 중요합니다.
credentialSchema 속성의 주된 목적은
검증 가능한 자격 증명의
구조와 나타나는 각 속성 값의 데이터 타입을 정의하는 것입니다.
credentialSchema는 검증 가능한 자격 증명 안 클레임 집합의
내용과 구조를 정의하는 데 유용한 반면,
[JSON-LD11]와
검증 가능한 자격 증명 안의
@context는 데이터의 의미와 용어 정의를 전달하는 데만 사용하는 것이 가장 좋으며,
검증 가능한 자격 증명의 구조를 정의하는 데도
사용할 수 있습니다.
검증 가능한 자격 증명의
내용을 암시하기 위해 일부 [JSON-LD11] 기능을 사용할 수는 있지만,
일반적으로 데이터 모델의 데이터 타입을 제한하기 위해 @context를 사용하는 것은
제안되지 않습니다. 예를 들어, "@type": "@json"은 의미를 개방형으로
남겨두고 엄격하게 정의하지 않는 데 유용합니다. 구현자가
자격 증명 안 클레임의 데이터 타입을
제한하려고 하는 경우 이는 위험할 수 있으며, 사용하지 않을 것으로 예상됩니다.
credentialSchema 및 @context 속성이 함께 사용되는 경우,
생산자와 소비자 모두 검증 가능한 자격 증명 및
검증 가능한 프레젠테이션의 예상 내용과
데이터 타입에 대해 더 큰 확신을 가질 수 있습니다.
C. IANA 고려 사항
이 절은 비규범적입니다.
이 절은 검토, 승인 및 IANA 등록을 위해 Internet Engineering Steering Group
(IESG)에 제출될 것입니다.
C.1 application/vc
이 명세는 검증 가능한 자격 증명 형식을 따르는 문서를
식별하기 위해 특별히 application/vc 미디어 타입을 등록합니다.
자격 증명은 유효한
JSON-LD 문서일 것으로
예상됩니다.
application/vc 미디어 타입으로 제공되는
검증 가능한 자격 증명은 외부 컨텍스트에 대한
참조를 포함하여 모든 JSON-LD
1.1 컨텍스트 정보를
문서 본문 안에 포함할 것으로 예상됩니다.
http://www.w3.org/ns/json-ld#context HTTP Link Header를 통해 링크된 컨텍스트
(JSON-LD
1.1의 Section
6.1
참조)는 무시됩니다.
C.2 application/vp
이 명세는 검증 가능한 프레젠테이션 형식을 따르는 문서를
식별하기 위해 특별히 application/vp 미디어 타입을 등록합니다.
프레젠테이션은 유효한
JSON-LD 문서일 것으로
예상됩니다. application/vp 미디어 타입으로 제공되는
검증 가능한 프레젠테이션은 외부 컨텍스트에 대한
참조를 포함하여 모든 JSON-LD
1.1 컨텍스트 정보를 문서 본문 안에 포함할 것으로 예상됩니다.
http://www.w3.org/ns/json-ld#context HTTP Link Header를 통해 링크된 컨텍스트
([JSON-LD11]의
Section 6.1 참조)는
무시됩니다.
날짜-시간 세부 사항에 대해 RFC3339를 가리키던 이전 규범적 참조를,
예제와 라이브러리에서의 날짜-시간 사용을 더 정확하게 반영하는 XMLSCHEMA11-2에
설명된 날짜-시간 세부 사항을 규범적으로 참조하도록 업데이트함.
데이터 모델의 credentialStatus 및 refreshService 절의
id 속성에서 역참조할 수 없는 URL을 허용하도록 요구 사항을 완화함.
v1.0 명세가 권고안으로 게시된 이후 만들어진 BBS+와 같은 새로운 영지식 증명 스킴의
적합성을 가능하게 하기 위해 영지식 증명 절의 규범적 진술을 완화함.
참조된 명세의 최신 버전을 가리키도록 모든 참조를 업데이트함. 사용할 수 없게 된
논문에 대한 깨진 링크를 논문을 사용할 수 있는 업데이트된 위치로 수정함.
SVG 다이어그램의 접근성을 향상함.
issuer, issuanceDate, credentialStatus, 날짜,
죽은 링크 및 사소한 구문 오류와 관련된 몇몇 예제의 편집상 버그를 수정함.
감사의 말을 문서 상태 절에서 감사의 말 부록으로 이동함.
F. 감사의 말
이 절은 비규범적입니다.
워킹 그룹은 이 문서의 내용에 기여했을 뿐만 아니라,
다양한 의견의 바다 속에서 변경, 토론 및 합의를 이끌어 낸 이 표준 커뮤니티에서의
헌신적인 노력에 대해 다음 개인들에게 감사를 표합니다: David Chadwick, Dave Longley, Ted Thibodeau Jr.,
Brent Zundel, Ivan Herman, Joe Andrieu, and Gabe Cohen.
이 명세에 대한 작업은 Christopher Allen, Shannon Appelcline, Kiara Robles,
Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, Drummond Reed, Joe
Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase, Andrew Hughes,
Will Abramson, Erica Connell, Eric Schuh, Zaïda Rivai, and Shigeya Suzuki가 지원한
Rebooting the Web of Trust 커뮤니티의 도움을 받았습니다.
Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul이 지원한
Internet Identity Workshop의 참가자들도 이 명세에 대해 교육하고, 토론하며, 개선하도록 설계된
수많은 작업 세션을 통해 이 작업의 정제에 기여했습니다.
워킹 그룹은 또한 여러 W3C 표준화 주기 동안 그룹을 전문적으로 관리하고
꾸준히 이끌어 준 워킹 그룹 의장 Dan Burnett, Matt Stone,
Brent Zundel, Wayne Chang, and Kristina Yasuda와 W3C Staff
Contacts인 Kazuyuki Ashimura and Ivan Herman에게 감사를 표합니다. 또한 이 명세에 통합된
여러 작업 항목의 인큐베이션을 감독한 W3C Credentials
Community Group의 의장 Christopher Allen,
Joe Andrieu, Kim Hamilton Duffy, Heather Vescent, Wayne Chang, Mike Prorock,
Harrison Tang, Kimberly Wilson Linson, and Will Abramson에게도 감사를 표합니다.
이 명세에 대한 작업의 일부는 미국 국토안보부 과학기술국의
계약 HSHQDC-17-C-00019, 70RSAT20T00000010/P00001, 70RSAT20T00000029,
70RSAT21T00000016/P00001, 70RSAT23T00000005, 70RSAT23C00000030,
70RSAT23R00000006, 70RSAT24T00000014, 70RSAT22T00000001 및 National
Science Foundation의 NSF 22-572에 의해 자금을 지원받았습니다. 이 명세의 내용은
반드시 미국 정부의 입장이나 정책을 반영하는 것은 아니며, 공식적인 지지를 추론해서는
안 됩니다.
워킹 그룹은 명세를 검토하고 피드백을 제공한 다음 개인들에게 감사를 표합니다
(이름이 제공되지 않은 경우 이름 또는 Github 핸들의 알파벳순):
Abhishek Mahadevan Raju,
Adam C. Migus,
Addison Phillips,
Adrian Gropper,
Aisp-GitHub,
Alen Horvat,
Alexander Mühle,
AlexAndrei98,
Allen Brown,
Amy Guy,
Andor Kesselman,
Andres Paglayan,
Andres Uribe,
Andrew Hughes,
Andrew Jones,
Andrew Whitehead,
Andy Miller,
Anil John,
Anthony Camilleri,
Anthony Nadalin,
Benjamin Collins,
Benjamin Goering,
Benjamin Young,
Bert Van Nuffelen,
Bohdan Andriyiv,
Brent Zundel,
Brian Richter,
Bruno Zimmermann,
caribouW3,
cdr,
Chaoxinhu,
Charles "Chaals" McCathieNevile,
Charles E. Lehner,
Chris Abernethy,
Chris Buchanan,
Christian Lundkvist,
Christine Lemmer-Webber,
Christoph Lange,
Christopher Allen,
Christopher Lemmer Webber,
ckennedy422,
Clare Nelson,
confiks,
Dan Brickley,
Daniel Buchner,
Daniel Burnett,
Daniel Hardman,
Darrell O'Donnell,
Dave Longley,
David Ammouial,
David Chadwick,
David Ezell,
David Hyland-Wood,
David I. Lehn,
David Janes,
David Waite,
Denis Ah-Kang,
Denisthemalice,
Devin Rousso,
Dmitri Zagidulin,
Dominique Hazael-Massieux,
Drummond Reed,
Emmanuel,
enuoCM,
Eric Elliott,
Eric Korb,
Eric Prud'hommeaux,
etaleo,
Evstifeev Roman,
Fabricio Gregorio,
Filip Kolarik,
Gabe Cohen,
Ganesh Annan,
George Aristy,
glauserr,
Golda Velez,
Grace Huang,
Grant Noble,
Greg Bernstein,
Gregg Kellogg,
Heather Vescent,
Henry Andrews,
Henry Story,
Ian B. Jacobs,
Ilan,
Isaac Henderson,
isaackps,
Iso5786,
Ivan Herman,
Jace Hensley,
Jack Tanner,
James Schoening,
Janina Sajka,
Jan Forster Cognizone,
Jeff Burdges,
Jeffrey Yasskin,
Jim Masloski,
Jim St.Clair,
Joe Andrieu,
Joel Gustafson,
Joel Thorstensson,
John Tibbetts,
Jonathan Holt,
José San Juan,
Juan Caballero,
Julien Fraichot,
Justin Richer,
Kaan Uzdoğan,
Kaliya Young,
Kazuyuki Ashimura,
Ken Ebert,
Kendall Weihe,
Kerri Lemoie,
Kevin Dean,
Kevin Griffin,
Kim Hamilton Duffy,
Konstantin Tsabolov,
Kristijan Sedlak,
Kristina Yasuda,
Kyle Den Hartog,
Lal Chandran,
Lance,
Lautaro Dragan,
Leonard Rosenthol,
Liam Missin,
Liam Quin,
Line Kofoed,
Lionel Wolberger,
Logan Porter,
Lovesh Harchandani,
Lukas J. Han,
Mahmoud Alkhraishi,
Maik Riechert,
Manu Sporny,
Marcel Jackisch,
Mark Foster,
Mark Harrison,
Mark Moir,
Markus Sabadello,
Martin Thomson,
Marty Reed,
Matt Peterson,
Matt Stone,
Matthew Peterson,
Matthieu Bosquet,
Matti Taimela,
Melvin Carvalho,
Michael B. Jones,
Michael Herman,
Michael Lodder,
Michael Richardson,
Mike Prorock,
Mike Varley,
Mircea Nistor,
MIZUKI Sonoko / Igarashi,
nage,
Nate Otto,
Nathan George,
Niclas Mietz,
Niko Lockenvitz,
Nikos Fotiou,
Nis Jespersen,
Oliver Terbu,
Pat McBennett,
Patrick St-Louis,
Paul Bastian,
Paul F. Dietrich,
Paulo Jorge Q. Ferreira,
Pelle Braendgaard,
Pete Rowley,
Phil Archer,
Phillip Long,
Pierre-Antoine Champin,
Rajesh Rathnam,
Ralph Swick,
Renato Iannella,
Reto Gmür,
Reza Soltani,
Richard Bergquist,
Richard Ishida,
Richard Varn,
Rieks Joosten,
RorschachRev,
Ryan Grant,
Samuel Müller,
Samuel Smith,
Sarven Capadisli,
Sebastian Crane,
Sebastian Elfors,
Shawn Butterfield,
Shigeya Suzuki,
Sho Nakatani,
Shuji Kamitsuna,
Snorre Lothar von Gohren Edwin,
Sten Reijers,
Stephen Curran,
Steve Huguenin,
Steve McCown,
Steven Rowat,
Taro,
tcibm,
Ted Thibodeau Jr.,
Tim Bouma,
Timo Glastra,
Tobias Käfer,
Tobias Looker,
Tom Jones,
Torsten Lodderstedt,
Tzviya Siegman,
Victor Dods,
Vincent Kelleher,
Vladimir Alexiev,
Víctor Herraiz Posada,
Wayne Chang,
whatisthejava,
Will Abramson,
William Entriken, and
Yancy Ribbens.
