검증가능한 크리덴셜 데이터 모델(Verifiable Credentials Data Model v2.0)

요약

검증가능한 크리덴셜은 운전면허증이나 학위 증명서와 같이 발급자가 제기한 클레임 집합을 표현하는 특정한 방식이다. 이 규격은 검증가능한 크리덴셜의 확장 가능한 데이터 모델, 이를 변조로부터 보호하는 방법, 그리고 발급자, 보유자, 검증자로 구성된 이러한 크리덴셜의 교환을 위한 3자 생태계를 설명한다. 이 문서는 또한 이 규격에서 설명하는 기술을 사용하는 생태계를 위한 보안, 프라이버시, 국제화, 접근성에 관한 다양한 고려사항을 다룬다.

이 절은 문서 뒷부분의 5. 고급 개념 절을 위한 준비로서 이 규격의 기본 개념 몇 가지를 소개한다.

이 부분은 비규범적입니다.

이 규격은 새로운 유형의 검증가능한 크리덴셜을 손쉽게 프로토타이핑할 수 있도록 설계되었다. 개발자는 아래 템플릿을 복사하여 일반적인 검증가능한 크리덴셜 도구에 붙여넣어 프로토타입 크리덴셜의 발급, 보유, 검증을 시작할 수 있다.

개발자는 아래의 MyPrototypeCredential을 자신이 만들고자 하는 크리덴셜의 타입으로 바꾼다. 검증가능한 크리덴셜은 주체에 대해 이야기하므로, credentialSubject 객체의 각 속성-값 쌍은 크리덴셜 주체의 특정 속성을 표현한다. 개발자가 이러한 속성-값 조합을 여러 개 추가하고 나면, 수정된 객체를 적합 발급자 구현에 보낼 수 있고, 그러면 검증가능한 크리덴셜이 개발자를 위해 생성된다. 프로토타이핑 관점에서 개발자가 해야 할 일은 이것이 전부이다.

예시 1: 프로토타입 검증가능한 크리덴셜을 만들기 위한 템플릿

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiableCredential", "MyPrototypeCredential"],
  "credentialSubject": {
    "mySubjectProperty": "mySubjectValue"
  }
}

모든 크리덴셜 속성을 안정화한 후에는, 다른 개발자와의 상호 운용성을 위해 안정적인 URL에 어휘 파일과 컨텍스트 파일을 생성하여 게시할 것을 권한다. 그러면 위의 https://www.w3.org/ns/credentials/examples/v2 URL은 사용 사례에 특화된 컨텍스트의 URL로 대체된다. 이 과정은 5.2 확장성 절에서 다룬다. 또는 개발자는 자신의 사용 사례에 맞는 기존 어휘 파일과 컨텍스트 파일을 재사용할 수도 있다. 재사용 가능한 자원은 Verifiable Credential Extensions에서 찾아볼 수 있다.

검증가능한 크리덴셜은 하나 이상의 주체의 속성과 크리덴셜 자체의 속성을 표현하는 데 사용된다. 이 규격은 검증가능한 크리덴셜에 대해 다음 속성들을 정의한다.

@context: 4.3 컨텍스트 절에서 정의한다.
id: 4.4 식별자 절에서 정의한다.
type: 4.5 타입 절에서 정의한다.
name: 4.6 이름과 설명 절에서 정의한다.
description: 4.6 이름과 설명 절에서 정의한다.
issuer: 4.7 발급자 절에서 정의한다.
credentialSubject: 4.8 크리덴셜 주체 절에서 정의한다.
validFrom: 4.9 유효 기간 절에서 정의한다.
validUntil: 4.9 유효 기간 절에서 정의한다.
status: 4.10 상태 절에서 정의한다.
credentialSchema: 4.11 데이터 스키마 절에서 정의한다.
refreshService: 5.4 갱신 절에서 정의한다.
termsOfUse: 5.5 사용 조건 절에서 정의한다.
evidence: 5.6 증거 절에서 정의한다.

검증가능한 크리덴셜은 5.2 확장성 절에서 정의하는 확장 메커니즘을 통해 추가 속성을 갖도록 확장될 수 있다.

두 소프트웨어 시스템이 데이터를 교환해야 할 때, 두 시스템 모두가 이해하는 용어를 사용해야 한다. 두 사람이 같은 언어를 사용하여 효과적으로 소통하는 경우를 생각해 보자. 여기서 "이름"이나 "웹사이트" 같은 그들이 쓰는 단어는 각 개인에게 동일한 것을 의미한다. 이를 대화의 컨텍스트라고 부르기도 한다. 이 규격은 소프트웨어 시스템에서도 유사한 결과를 얻기 위해, 소통이 이루어질 컨텍스트를 확립함으로써 유사한 개념을 사용한다.

검증가능한 크리덴셜과 검증가능한 프레젠테이션을 처리하는 소프트웨어 시스템은 각 용어에 대해 URL을 사용하여 용어를 식별한다. 그러나 그러한 URL은 길고 사람에게 친숙하지 않을 수 있는 반면, 짧고 사람에게 친숙한 별칭이 더 유용할 수 있다. 이 규격은 @context 속성을 사용하여 짧은 별칭을 URL에 대응시킨다.

검증가능한 크리덴셜과 검증가능한 프레젠테이션은 @context 속성을 포함해야 한다. 애플리케이션 개발자는 자신의 애플리케이션이 사용하는 모든 JSON-LD 컨텍스트를, 최소한 그것이 애플리케이션에서 사용하는 용어의 의미에 영향을 미치는 범위까지는 이해해야 한다. 이를 위한 한 가지 메커니즘은 Verifiable Credential Data Integrity 1.0 규격의 Validating Contexts 절에서 설명한다. 이 규격을 기반으로 하는 다른 규격은 5.3 관련 자원의 무결성 절에서 설명하는 relatedResource 기능이나 그와 실질적으로 동등한 메커니즘을 사용하여 JSON-LD 컨텍스트가 무결성 보호되도록 요구할 수 있다.

@context: @context 속성의 값은 첫 번째 항목이 값 https://www.w3.org/ns/credentials/v2를 가진 URL인 순서 있는 집합이어야 한다. 순서 있는 집합의 후속 항목은 URL과 객체의 임의의 조합으로 구성되어야 하며, 각각은 JSON-LD 컨텍스트로 처리 가능해야 한다.

예시 2: @context 속성의 사용

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

위 예시는 기본 컨텍스트 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을 파일럿이나 운영 시스템 등 다른 어떤 목적으로도 사용하지 않을 것으로 기대된다.

참고: @context에 대한 자세한 내용은 JSON-LD를 참조한다.

@context 속성은 JSON-LD 1.1 규격의 Section 3.1: The Context에서 더 자세히 설명한다.

이 문서에 명시된 종류의 객체를 처리하는 소프트웨어 시스템은 제공된 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션이 의도한 사용 사례에 적합한지 판단하는 데 타입 정보를 사용한다. 이 규격은 객체의 타입 정보를 표현하기 위해 type 속성을 정의한다. 이 타입 정보는 부록 A. 유효성 검사에서 설명하는 대로 유효성 검사 과정에서 사용될 수 있다.

검증가능한 크리덴셜과 검증가능한 프레젠테이션은 연관된 값을 가진 type 속성을 포함해야 한다.

type: type 속성의 값은 하나 이상의 용어와 절대 URL 문자열이어야 한다. 값이 두 개 이상 제공되는 경우 순서는 중요하지 않다.

이 규격과 관련하여, 다음 표는 타입이 명시되어야 하는 객체들을 나열한다.

객체	타입
검증가능한 크리덴셜 객체	`VerifiableCredential`, 그리고 선택적으로 더 구체적인 검증가능한 크리덴셜 타입. 예를 들어 `"type": ["VerifiableCredential", "OpenBadgeCredential"]`
검증가능한 프레젠테이션 객체	`VerifiablePresentation`, 그리고 선택적으로 더 구체적인 검증가능한 프레젠테이션 타입. 예를 들어 `"type": "VerifiablePresentation"`
credentialStatus 객체	유효한 크리덴셜 상태 타입. 예를 들어 `"type": "BitstringStatusListEntry"`
termsOfUse 객체	유효한 사용 조건 타입. 예를 들어 `"type": "TrustFrameworkPolicy"`
evidence 객체	유효한 증거 타입. 예를 들어 `"type": "Evidence"`
refreshService 객체	유효한 refreshService 타입. 예를 들어 `"type": "VerifiableCredentialRefreshService2021"`
credentialSchema 객체	유효한 credentialSchema 타입. 예를 들어 `"type": "JsonSchema"`

참고: 검증가능한 크리덴셜 데이터 모델은 JSON-LD에 기반한다

검증가능한 크리덴셜 데이터 모델의 타입 체계는 JSON-LD 1.1의 것과 동일하며, Section 3.5: Specifying the Type와 Section 9: JSON-LD Grammar에서 자세히 설명한다. JSON-LD 컨텍스트를 사용할 때 (5.2 확장성 절 참조), 이 규격은 JSON-LD 문서를 더 쉽게 이해할 수 있도록 @type 키워드를 type의 별칭으로 지정한다. 애플리케이션 개발자와 문서 작성자는 JSON-LD 타입 체계의 세부 사항을 이해할 필요가 없지만, 상호 운용 가능한 확장성을 지원하려는 이 규격의 구현자는 이해할 필요가 있다.

모든 크리덴셜, 프레젠테이션, 그리고 캡슐화된 객체는 소프트웨어 시스템이 이 추가 정보를 더 쉽게 감지하고 처리할 수 있도록 (예컨대 ExampleDegreeCredential처럼) 더 좁은 범위의 추가 타입을 명시하거나 그와 연관되는 것이 좋다.

credentialSubject 객체와 연관되거나 그 안에 깊이 중첩된 객체처럼 이 규격이 정의하는 캡슐화된 객체를 처리할 때, 소프트웨어 시스템은 계층 구조에서 더 상위의 캡슐화 객체에 명시된 타입 정보를 사용하는 것이 좋다. 구체적으로, 크리덴셜과 같은 캡슐화 객체는 검증자가 캡슐화 객체의 타입을 근거로 연관 객체의 내용을 신속히 판단할 수 있도록 연관된 객체 타입을 전달하는 것이 좋다.

예를 들어 type이 ExampleDegreeCredential인 크리덴셜 객체는 credentialSubject 속성과 연관된 객체에 다음의 식별자가 담겨 있음을 검증자에게 알린다.

id 속성의 주체.
type 속성의 학위 종류.
name 속성의 학위명.

이를 통해 구현자는 검증을 위해 type 속성과 연관된 값에 의존할 수 있다. 객체 타입과 그와 연관된 값은 최소한 사람이 읽을 수 있는 규격에 문서화되어 그 타입의 URL에서 확인할 수 있을 것으로 기대된다. 예를 들어 BitstringStatusList 타입의 사람이 읽을 수 있는 정의는 https://www.w3.org/ns/credentials/status/#BitstringStatusList에서 확인할 수 있다. 또한 동일한 URL에서 HTTP 콘텐츠 협상을 통해 기계가 읽을 수 있는 버전을 제공할 것을 제안한다.

참고: 새로운 크리덴셜 타입을 만들려면 구현 가이드를 참조한다

새로운 유형의 검증가능한 크리덴셜을 만드는 방법을 설명하는 것은 이 규격의 범위를 벗어난다. 이에 관심 있는 독자는 Verifiable Credentials Implementation Guidelines 1.0의 Creating New Credential Types 절을 읽을 것을 권한다.

크리덴셜을 표시할 때, 발급자가 제공하는 텍스트로 그 크리덴셜에 이름과 그 목적에 대한 짧은 설명을 붙여 두면 도움이 될 수 있다. name과 description 속성이 이러한 목적에 쓰인다.

name: 크리덴셜의 이름을 표현하는 선택 속성이다. 존재하는 경우 name 속성의 값은 문자열이거나 11.1 언어와 기본 방향에서 설명하는 언어 값 객체이어야 한다. 이상적으로 크리덴셜의 이름은 간결하고 사람이 읽을 수 있으며, 개인이 자신이 보유한 여러 크리덴셜 중에서 특정 크리덴셜을 빠르게 구별할 수 있게 해 준다.
description: 크리덴셜에 대한 구체적인 세부 사항을 전달하는 선택 속성이다. 존재하는 경우 description 속성의 값은 문자열이거나 11.1 언어와 기본 방향에서 설명하는 언어 값 객체이어야 한다. 이상적으로 크리덴셜의 설명은 몇 문장을 넘지 않으며, 클레임 전체를 훑어보지 않고도 개인이 그 크리덴셜의 내용을 떠올릴 수 있을 만큼의 정보를 전달한다.

예시 5: name과 description 속성의 사용

이름과 설명은 서로 다른 언어로 내용을 표현하는 것도 지원한다. 언어와 기본 방향 정보를 가진 문자열을 표현하려면, @value, @language, @direction 속성을 담은 객체를 사용하여 각각 텍스트 값, 언어 태그, 기본 방향을 표현할 수 있다. 자세한 내용은 11.1 언어와 기본 방향을 참조한다.

참고: 단일 언어 문자열에는 @direction이 필요하지 않다

아래 예시의 @direction 속성은 연관된 단일 언어 문자열에는 필요하지 않다. 그 문자열들의 기본 방향이 @direction 값이 지정하는 방향과 같기 때문이다. 여기서 @direction 속성을 포함한 것은 설명을 명확히 하고 복사+붙여넣기+수정만으로 동작하는 결과를 얻을 수 있게 하기 위함이다. 구현자는 JSON-LD 1.1 규격의 String Internationalization 절을 읽을 것을 권한다.

예시 6: name과 description 속성의 사용

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": {
    "id": "https://university.example/issuers/565049",
    "name": [{
      "@value": "Example University",
      "@language": "en"
    }, {
      "@value": "Université Exemple",
      "@language": "fr"
    }, {
      "@value": "جامعة المثال",
      "@language": "ar",
      "@direction": "rtl"
    }],
    "description": [{
      "@value": "A public university focusing on teaching examples.",
      "@language": "en"
    }, {
      "@value": "Une université publique axée sur l'enseignement d'exemples.",
      "@language": "fr"
    }, {
      "@value": ".جامعة عامة تركز على أمثلة التدريس",
      "@language": "ar",
      "@direction": "rtl"
    }]
  },
  "validFrom": "2015-05-10T12:30:00Z",
  "name": [{
    "@value": "Example University Degree",
    "@language": "en"
  }, {
    "@value": "Exemple de Diplôme Universitaire",
    "@language": "fr"
  }, {
    "@value": "مثال الشهادة الجامعية",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "description": [{
    "@value": "2015 Bachelor of Science and Arts Degree",
    "@language": "en"
  }, {
    "@value": "2015 Licence de Sciences et d'Arts",
    "@language": "fr"
  }, {
    "@value": "2015 بكالوريوس العلوم والآداب",
    "@language": "ar",
    "@direction": "rtl"
  }],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": [{
        "@value": "Bachelor of Science and Arts Degree",
        "@language": "en"
      }, {
        "@value": "Licence de Sciences et d'Arts",
        "@language": "fr"
      }, {
        "@value": "بكالوريوس العلوم والآداب",
        "@language": "ar",
        "@direction": "rtl"
      }]
    }
  }
}

이 규격은 정지되었는지 폐기되었는지 등 검증가능한 크리덴셜의 상태와 관련된 정보를 발견하기 위해 credentialStatus 속성을 정의한다.

존재하는 경우 credentialStatus 속성과 연관된 값은 단일 객체이거나 하나 이상의 객체의 집합이다. 모든 객체에 대해 다음 속성이 정의된다.

id: id 속성은 선택 사항이다. 크리덴셜 상태 객체의 고유 식별자를 제공하는 데 사용할 수 있다. 존재하는 경우 4.4 식별자 절의 규범적 지침을 따라야 한다.
type: type 속성은 필수이다. 해당 객체가 표현하는 상태 정보의 타입을 표현하는 데 사용된다. 4.5 타입 절의 관련 규범적 지침을 따라야 한다.

크리덴셜 상태 정보의 정확한 내용은 구체적인 credentialStatus 타입 정의가 결정하며, 구현이 단순한지 또는 프라이버시를 강화하는지 같은 요인에 따라 달라진다. 그 값은 크리덴셜의 현재 상태를 판단하고 기계가 읽을 수 있는 정보를 URL에서 가져올 수 있는지 판단하기에 충분한 정보를 제공한다. 예를 들어 그 객체에는 크리덴셜이 정지 또는 폐기되었는지를 기록한 외부 문서로의 링크가 담길 수 있다.

예시 12: status 속성의 사용

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://university.example/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://university.example/credentials/status/3"
  }
}

크리덴셜은 폐기되었는지 정지되었는지 등 두 개 이상의 상태와 연관될 수 있다.

예시 13: status 속성에 여러 항목 사용하기

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://license.example/credentials/9837",
  "type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"],
  "issuer": "https://license.example/issuers/48",
  "validFrom": "2020-03-14T12:10:42Z",
  "credentialSubject": {
    "id": "did:example:f1c276e12ec21ebfeb1f712ebc6",
    "license": {
      "type": "ExampleDrivingLicense",
      "name": "License to Drive a Car"
    }
  },
  "credentialStatus": [{
    "id": "https://license.example/credentials/status/84#14278",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "14278",
    "statusListCredential": "https://license.example/credentials/status/84"
  }, {
    "id": "https://license.example/credentials/status/84#82938",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "suspension",
    "statusListIndex": "82938",
    "statusListCredential": "https://license.example/credentials/status/84"
  }]
}

구현자는 상태 항목이 여러 개인 크리덴셜에 서로 상충하는 정보가 담길 수 있다는 점에 주의해야 한다. 그러한 충돌을 조정하는 것은 유효성 검사 과정의 일부이며, 따라서 검증자의 비즈니스 로직에 속하므로 이 규격의 범위를 벗어난다.

상태 방식의 데이터 모델, 형식, 프로토콜을 정의하는 것은 이 규격의 범위를 벗어난다. Verifiable Credential Extensions 문서에는 검증가능한 크리덴셜 상태 확인을 구현하려는 구현자를 위해 사용 가능한 상태 방식들이 담겨 있다.

크리덴셜 상태 규격은 개인의 추적을 가능하게 해서는 안 된다. 예컨대 검증자가 특정 보유자나 주체에 관심을 보일 때 발급자가 (직접적으로든 간접적으로든) 통지받게 되는 것이 그러하다. 허용될 수 없는 방식으로는, 크리덴셜을 사용할 때마다 특정 개인의 상태를 확인하기 위해 그 크리덴셜의 발급자에게 접속하는 "폰 홈(phoning home)"과, 크리덴셜을 사용할 때마다 발급자에게 정보 요청이 발생하여 그 발급자가 특정 개인에 대한 검증자의 관심을 추론할 수 있게 되는 "가명성 축소(pseudonymity reduction)"가 있다.

데이터 스키마는 주어진 데이터 모음에 특정 구조를 강제할 때 유용하다. 이 규격이 고려하는 데이터 스키마에는 최소한 두 가지 유형이 있다.

데이터 검증 스키마. 크리덴셜이나 검증가능한 크리덴셜의 구조와 내용이 게시된 스키마에 부합함을 확립하는 데 사용된다.
데이터 인코딩 스키마. 검증가능한 크리덴셜의 내용을 영지식 증명에서 사용되는 형식과 같은 대체 표현 형식으로 대응시키는 데 사용된다.

데이터 스키마가 @context 속성과는 다른 목적에 쓰인다는 점을 이해하는 것이 중요하다. @context 속성은 데이터 구조나 데이터 구문을 강제하지도 않고, 대체 표현 형식으로의 임의의 인코딩을 정의할 수 있게 하지도 않는다.

이 규격은 데이터 스키마를 표현하기 위해 다음 속성을 정의하며, 발급자는 자신이 발급하는 검증가능한 크리덴셜에 이를 포함할 수 있다.

credentialSchema

credentialSchema 속성의 값은, 제공된 데이터가 제공된 스키마에 부합하는지 판단하기에 충분한 정보를 검증자에게 제공하는 하나 이상의 데이터 스키마이어야 한다. 각 credentialSchema는 자신의 type(예: JsonSchema)과, 스키마 파일을 식별하는 URL이어야 하는 id 속성을 명시해야 한다. 구체적인 타입 정의가 각 데이터 스키마의 정확한 내용을 결정한다.

스키마가 여러 개 존재하는 경우, 유효성은 연관된 각 type 속성이 제시하는 처리 규칙에 따라 결정된다.

참고: 크리덴셜 타입별 구문 검사가 가능하다

credentialSchema 속성을 사용하면 타입 정의에 주석을 달거나 그것을 어휘의 특정 버전에 고정할 수 있다. 검증가능한 크리덴셜의 작성자는 어떤 콘텐츠 무결성 보호 메커니즘으로 보호되는 credentialSchema를 사용하여 자신의 어휘의 정적 버전을 포함할 수 있다. credentialSchema 속성은 또한 크리덴셜에 대해 구문 검사를 수행하고 JSON Schema [VC-JSON-SCHEMA] 유효성 검사와 같은 검증 메커니즘을 사용할 수 있게 해 준다.

예시 14: credentialSchema 속성으로 JSON 스키마 유효성 검사 수행하기

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    },
    "alumniOf": {
      "name": "Example University"
    }
  },
  "credentialSchema": [{
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchema"
  },
  {
    "id": "https://example.org/examples/alumni.json",
    "type": "JsonSchema"
  }]
}

위 예시에서 발급자는 두 개의 credentialSchema 객체를 명시하고 있으며, 각각은 검증자가 검증가능한 크리덴셜이 올바른 형식인지 판단하는 데 사용할 수 있는 JSON Schema [VC-JSON-SCHEMA] 파일을 가리킨다.

이 규격은 두 부류의 보안 메커니즘을 인정한다. 봉투 증명을 사용하는 것과 내장 증명을 사용하는 것이다.

봉투 증명은 이 데이터 모델의 직렬화 결과를 감싼다. 그러한 권장 봉투 증명 메커니즘 하나가 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]에 정의되어 있다.

내장 증명은 증명이 데이터 모델의 직렬화 결과 안에 포함되는 메커니즘이다. 그러한 권장 내장 증명 메커니즘 하나가 Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY]에 정의되어 있다.

이 두 부류의 보안 메커니즘은 상호 배타적이지 않다. 5.13 보안 메커니즘 규격 절의 규칙에 따라 추가적인 보안 메커니즘 규격이 정의될 수도 있다.

예시 15: 내장 증명을 사용하는 검증가능한 크리덴셜

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "https://subject.example/subject/3921",
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "https://university.example/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }
}

위의 내장 증명은 proof 속성을 통해 원본 데이터에 디지털 서명을 덧붙여 원래의 크리덴셜을 보호한다. 그 결과 현대적인 프로그래밍 환경과 데이터베이스 시스템에서 다루기 쉬운 검증가능한 크리덴셜이 만들어진다.

예시 16: SD-JWT 형식의 봉투 증명을 사용하는 검증가능한 크리덴셜

eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ
.
eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz
ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6
Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT
AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm
S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0
JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh
Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck
E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy
VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm
5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC
QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2
lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq
d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU
NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5
IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF
VjeXluTDg0dCJ9fX0
.
M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38
MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX
~
WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG
UvY3JlZGVudGlhbHMvMTg3MiJd
~
WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi
wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d
~
WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX
BsZXMvZGVncmVlLmpzb24iXQ
~
WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN
nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd
~
WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

위의 봉투 증명은 원본 데이터를 디지털 서명 봉투에 캡슐화하여 원래의 크리덴셜을 보호하며, 그 결과 SD-JWT 형식을 이해하는 도구로 처리할 수 있는 검증가능한 크리덴셜이 만들어진다.

검증가능한 프레젠테이션은 여러 검증가능한 크리덴셜의 정보를 집계하는 데 사용할 수 있다.

검증가능한 프레젠테이션은 수명이 극히 짧고 검증자가 제공한 챌린지에 결속되는 것이 좋다. 이를 달성하는 세부 방법은 보안 메커니즘, 전송 프로토콜, 검증자 정책에 따라 달라진다. 특정 보안 메커니즘이나 내장 프로토콜이 추가 요구사항을 정의하지 않는 한, 검증자는 일반적으로 그 검증가능한 프레젠테이션이 제시된 검증가능한 크리덴셜과 상관관계가 있다고 가정할 수 없다.

검증가능한 프레젠테이션의 기본 그래프는 검증가능한 프레젠테이션 그래프라고도 한다.

검증가능한 프레젠테이션에 대해 다음 속성들이 정의된다.

id: id 속성은 선택 사항이다. 검증가능한 프레젠테이션의 고유 식별자를 제공하는 데 사용할 수 있다. 존재하는 경우 4.4 식별자 절의 규범적 지침을 따라야 한다.
type: type 속성은 존재해야 한다. 검증가능한 프레젠테이션의 타입을 표현하는 데 사용된다. 이 속성의 값 중 하나는 VerifiablePresentation이어야 하며, 추가 타입을 포함할 수 있다. 4.5 타입 절의 관련 규범적 지침을 따라야 한다.
verifiableCredential: verifiableCredential 속성은 존재할 수 있다. 그 값은 하나 이상의 검증가능한 크리덴셜 및/또는 봉투로 감싼 검증가능한 크리덴셜 객체이어야 한다(그 값이 숫자, 문자열, URL과 같이 객체가 아닌 값이어서는 안 된다). 이 객체들은 검증가능한 크리덴셜 그래프라 부르며, 보안 메커니즘으로 보호된 정보를 표현해야 한다. 자세한 내용은 5.12 검증가능한 크리덴셜 그래프 절을 참조한다.
holder: 검증가능한 프레젠테이션은 holder 속성을 포함할 수 있다. 존재하는 경우 그 값은 URL이거나 id 속성을 담은 객체 중 하나이어야 한다. holder의 URL이나 그 id는 역참조할 경우 검증가능한 프레젠테이션에 표현된 정보를 검증하는 데 사용할 수 있는, 보유자에 대한 기계가 읽을 수 있는 정보를 담은 문서를 반환하는 것이 권장된다. holder 속성이 없으면 보유자에 대한 정보는 보안 메커니즘을 통해 얻거나, 그 검증가능한 프레젠테이션의 유효성 검사와 무관하다.

아래 예시는 검증가능한 프레젠테이션을 보여준다.

예시 17: 프레젠테이션의 기본 구조

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{ ... }]
}

위에 나타난 verifiableCredential 속성의 내용은 이 규격이 설명하는 검증가능한 크리덴셜 그래프이다.

검증가능한 프레젠테이션이 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]와 같이 페이로드를 "봉투로 감싸는" 보안 메커니즘으로 보호된 하나 이상의 검증가능한 크리덴셜을 포함하는 것이 가능하다. 이는 verifiableCredential 속성을 type이 EnvelopedVerifiableCredential인 객체와 연관시켜 이룰 수 있다.

EnvelopedVerifiableCredential: 봉투로 감싼 검증가능한 크리덴셜을 담은 객체를 검증가능한 프레젠테이션의 verifiableCredential 속성과 연관시키는 데 사용된다. 그 객체의 @context 속성은 존재하고, 이 규격의 기본 컨텍스트와 같이, 이 규격이 제공하는 기본 컨텍스트가 정의하는 대로 최소한 id, type, EnvelopedVerifiableCredential 용어를 정의하는 컨텍스트를 포함해야 한다. 그 객체의 id 값은 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]와 같은 봉투 보안 방식을 사용하여 보호된 검증가능한 크리덴셜을 표현하는 data: URL [RFC2397]이어야 한다. 그 객체의 type 값은 EnvelopedVerifiableCredential이어야 한다.

아래 예시는 봉투로 감싼 검증가능한 크리덴셜을 담고 있는 검증가능한 프레젠테이션을 보여준다.

예시 18: 프레젠테이션의 기본 구조

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{
    "@context": "https://www.w3.org/ns/credentials/v2",
    "id": "data:application/vc+sd-jwt,QzVjV...RMjU",
    "type": "EnvelopedVerifiableCredential"
  }]
}

참고: 봉투로 감싼 내용을 RDF로 처리하기

구현자가 이 절에서 설명한 객체와 id 값이 표현하는, 봉투로 감싼 프레젠테이션을 RDF 환경에서 처리하고 RDF와 관련된 객체 간 연결을 만들고자 할 수 있다. 그렇게 하려는 요구와 그 메커니즘은 사용 사례에 따라 다르며, 따라서 구현에 따라 다를 것이다.

Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]와 같이 페이로드를 "봉투로 감싸는" 메커니즘으로 보호된 검증가능한 프레젠테이션을 표현하는 것이 가능하다. 이는 type이 EnvelopedVerifiablePresentation인 객체를 사용하여 이룰 수 있다.

EnvelopedVerifiablePresentation: 봉투로 감싼 검증가능한 프레젠테이션을 표현하는 데 사용된다. 그 객체의 @context 속성은 존재하고, 이 규격의 기본 컨텍스트와 같이, 이 규격이 제공하는 기본 컨텍스트가 정의하는 대로 최소한 id, type, EnvelopedVerifiablePresentation 용어를 정의하는 컨텍스트를 포함해야 한다. 그 객체의 id 값은 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]와 같은 봉투 보안 메커니즘을 사용하여 보호된 검증가능한 프레젠테이션을 표현하는 data: URL [RFC2397]이어야 한다. 그 객체의 type 값은 EnvelopedVerifiablePresentation이어야 한다.

아래 예시는 봉투로 감싼 검증가능한 프레젠테이션을 보여준다.

예시 19: 봉투로 감싼 검증가능한 프레젠테이션의 기본 구조

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ",
  "type": "EnvelopedVerifiablePresentation"
}

일부 영지식 암호 방식은 보유자가 어떤 검증가능한 크리덴셜의 모든 클레임을 드러내지 않고도 그 검증가능한 크리덴셜의 클레임을 보유하고 있음을 간접적으로 증명할 수 있게 해 준다. 이러한 방식에서는 검증가능한 크리덴셜로부터 제시 가능한 데이터를 파생시킬 수 있으며, 그 데이터는 검증자가 발급자를 신뢰한다면 그 값을 신뢰할 수 있도록 암호학적으로 주장된다.

일부 선택적 공개 방식은 검증가능한 크리덴셜로부터 파생된 클레임의 부분집합을 공유할 수 있다.

참고: 영지식 증명을 사용하는 프레젠테이션이 가능하다

검증가능한 크리덴셜을 직접 내장하는 대신 파생 데이터를 담는 ZKP 방식 검증가능한 프레젠테이션의 예시는 5.7 영지식 증명 절을 참조한다.

Pat이 overAge라는 속성을
가지며 그 값은 21이다 — Figure 11 Pat이 21세 이상임을 표현하는 기본 클레임.

보유자는 자기 자신을 포함하여 어떤 발급자의 검증가능한 크리덴셜이든 포함하기 위해 검증가능한 프레젠테이션에서 verifiableCredential 속성을 사용할 수 있다. 검증가능한 크리덴셜의 발급자가 보유자인 경우, 그 검증가능한 크리덴셜의 클레임은 자기 주장으로 간주된다. 그러한 자기 주장 클레임은 그것이 포함된 검증가능한 프레젠테이션을 보호하는 것과 동일한 메커니즘으로 보호되거나, 다른 검증가능한 크리덴셜에 사용할 수 있는 어떤 메커니즘으로든 보호될 수 있다.

이러한 자기 주장 클레임의 주체는 제한되지 않으므로, 이 클레임에는 보유자, 함께 포함된 다른 검증가능한 크리덴셜 중 하나, 또는 그 자기 주장 검증가능한 크리덴셜이 포함된 검증가능한 프레젠테이션 자체에 대한 진술이 담길 수 있다. 각 경우에 id 속성은 자기 주장이 아닌 검증가능한 크리덴셜에서와 마찬가지로, 그에 대한 클레임이 이루어지는 객체에서 특정 주체를 식별하는 데 사용된다.

검증가능한 프레젠테이션과 동일한 메커니즘으로만 보호되는 자기 주장 검증가능한 크리덴셜을 포함하는 검증가능한 프레젠테이션은 holder 속성을 포함해야 한다.

검증가능한 크리덴셜에 대해 정의된 모든 규범적 요구사항은 자기 주장 검증가능한 크리덴셜에도 적용된다.

검증가능한 프레젠테이션 안의 검증가능한 크리덴셜은 그 검증가능한 크리덴셜의 issuer 속성 값이 검증가능한 프레젠테이션의 holder 속성 값과 동일할 때 자기 주장으로 간주된다.

아래 예시는 검증가능한 프레젠테이션과 동일한 메커니즘으로 보호되는 자기 주장 검증가능한 크리덴셜을 내장한 검증가능한 프레젠테이션을 보여준다.

예시 20: 내장 Data Integrity 증명으로 보호되고 자기 주장 검증가능한 크리덴셜을 담은 검증가능한 프레젠테이션

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "favoriteCheese": "Gouda"
    },
    { ... }
  }],
  "proof": [{ ... }]
}

아래 예시는 그 검증가능한 프레젠테이션에 대한 클레임을 담고 있는 자기 주장 검증가능한 크리덴셜을 내장한 검증가능한 프레젠테이션을 보여준다. 이는 그 검증가능한 프레젠테이션과 동일한 메커니즘으로 보호된다.

예시 21: 내장 Data Integrity 증명으로 보호되고 그 검증가능한 프레젠테이션에 대한 자기 주장 검증가능한 크리덴셜을 담은 검증가능한 프레젠테이션

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
  "holder": "did:example:12345678",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "type": ["VerifiableCredential", "ExampleAssertCredential"],
    "issuer": "did:example:12345678",
    "credentialSubject": {
      "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
      "assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
    },
    "proof": { ... }
  }],
  "proof": { ... }
}

4. 기본 개념 절에서 소개한 개념을 바탕으로, 이 절은 검증가능한 크리덴셜에 관한 더 복잡한 주제를 다룬다.

This section is non-normative.

검증가능한 크리덴셜의 신뢰 모델은 다음 기대에 기반한다.

검증자는 자신이 받은 크리덴셜을 발급자가 검증 가능한 방식으로 발급했을 것을 기대한다. 이는 다음 중 하나를 충족함으로써 확립될 수 있다.
- 발급자가 발급자가 그 크리덴셜을 생성했음을 확립해 주는 보안 메커니즘으로 크리덴셜을 보호한다. 다시 말해 발급자가 검증가능한 크리덴셜을 발급한다.
- 발급자가 그 크리덴셜을 생성했고 그 크리덴셜이 전송 중이나 저장 중에 변조되지 않았음을 분명히 확립하는 방식으로 크리덴셜이 전송된다. 이 기대는 검증자의 위험 평가에 따라 완화될 수도 있다.
모든 엔티티는 검증가능한 데이터 레지스트리가 변조 감지가 가능하고, 어떤 데이터를 어떤 엔티티가 제어하는지에 대한 정확한 기록일 것을 기대한다. 이는 보통 그 레지스트리를 게시하는 방식으로 달성된다. 신뢰할 수 있는 게시자로부터의 P2P 프로토콜, 공개적으로 접근 가능하고 잘 알려진 웹사이트(콘텐츠 해시를 갖춘), 블록체인 등이 그 예이다. 엔티티가 자신에 대한 메타데이터를 게시할 때, 그 게시물은 해당 엔티티의 개인키로 보호함으로써 무결성을 보호할 수 있다.
보유자와 검증자는 발급자가 크리덴셜에서 주체에 대해 제기한 클레임을 지지할 것을, 그리고 더 이상 그 클레임을 지지하지 않게 되면 크리덴셜을 신속히 폐기할 것을 기대한다.
보유자가 발급자와 이미 신뢰 관계를 맺고 있기 때문에 그 발급자의 클레임을 보유자가 신뢰할 수도 있다. 예를 들어 고용주가 직원에게 재직 검증가능한 크리덴셜을 제공하거나, 정부가 시민에게 전자 여권을 발급할 수 있다.
기존 신뢰 관계가 없는 경우, 보유자는 제공되는 검증가능한 크리덴셜을 발급할 자격이 그 발급자에게 있는지 판단할 대역 외(out-of-band) 수단을 가질 수도 있다.

참고: 보유자가 발급자를 신뢰해야 하는 것은 아니다. 발급된 검증가능한 크리덴셜이 보유자가 아닌 주체에 대한 주장이거나 아무에 대한 것도 아닐 수 있고, 보유자가 그 진위에 대한 책임을 지지 않으면서 이 정보를 검증자에게 전달할 의사가 있을 수 있기 때문이다.
보유자는 크리덴셜 리포지토리가 크리덴셜을 안전하게 저장하고, 보유자(이후 이를 검증자에게 제시할 수 있다) 외의 누구에게도 크리덴셜을 내주지 않으며, 보관 중인 크리덴셜을 손상시키거나 잃어버리지 않을 것을 기대한다.

이 신뢰 모델은 다음을 보장한다는 점에서 다른 신뢰 모델과 구별된다.

발급자와 검증자는 크리덴셜 리포지토리에 대해 아무것도 알 필요가 없다.
발급자는 검증자에 대해 아무것도 알 필요가 없다.

검증자가 어떤 발급자를, 어떤 데이터나 목적에 대해 신뢰할지 결정하는 방법은 이 권고안의 범위를 벗어난다. 잘 알려진 조직과 같은 일부 발급자는 단지 그 평판 때문에 많은 검증자에게 신뢰받을 수 있다. 일부 발급자와 검증자는 회원 규칙에 따라 모든 구성원이 서로를 신뢰하는 커뮤니티의 구성원일 수 있다. 일부 검증자는 발급자를 심사하여 Electronic Signatures and Infrastructures (ESI); Trusted Lists [ETSI-TRUST-LISTS]나 Adobe Approved Trust List에 명시된 것과 같은 신뢰 목록에 등재하는 일을 맡은 특정 신뢰 서비스 제공자를 신뢰할 수도 있다.

발급자와 검증자 사이의 기대를 분리함으로써 더 유연하고 동적인 신뢰 모델이 만들어지며, 그 결과 시장 경쟁과 고객 선택권이 증대된다.

이 신뢰 모델이 워킹 그룹이 연구한 다양한 위협 모델과 어떻게 상호작용하는지에 대한 자세한 내용은 Verifiable Credentials Use Cases [VC-USE-CASES]를 참조한다.

참고: 이 신뢰 모델은 전통적인 인증 기관 체계와 다르다

이 규격이 상세히 기술하는 데이터 모델은 더 전통적인 인증 기관(CA) 신뢰 모델이 제공하는 것과 같은 이행적(transitive) 신뢰 모델을 함의하지 않는다. 검증가능한 크리덴셜 데이터 모델에서 검증자는 발급자를 직접 신뢰하거나 신뢰하지 않거나 둘 중 하나이다. 검증가능한 크리덴셜 데이터 모델을 사용하여 이행적 신뢰 모델을 구축하는 것이 가능하기는 하지만, 구현자는 인증 기관 체계가 취한 방식으로 신뢰를 광범위하게 위임할 때 발생하는 보안 취약점을 숙지할 것을 강력히 권한다.

검증가능한 크리덴셜에 외부 자원으로의 링크를 포함할 때, 그 검증가능한 크리덴셜이 발급된 이후 그 자원이 수정되었는지 아는 것이 바람직하다. 이는 원격으로 가져오는 외부 자원이 있는 경우뿐 아니라, 발급자나 검증자가 자원의 사본을 로컬에 캐시해 두었을 수 있는 경우에도 해당된다. 또한 검증가능한 크리덴셜에서 사용된 JSON-LD 컨텍스트의 내용이 발급자가 사용했을 때와 검증자가 사용할 때 동일한지 아는 것도 바람직할 수 있다.

무결성 보호를 관련 자원까지 확장하기 위해, 검증가능한 크리덴셜의 발급자는 relatedResource 속성을 포함할 수 있다.

relatedResource

relatedResource 속성의 값은 다음 형태의 객체 하나 이상이어야 한다.

속성	설명
`id`	자원의 식별자는 필수이며 4.4 식별자 절에서 정의한 형식을 따른다. 그 값은 관련 자원 객체 목록 안에서 고유해야 한다.
`mediaType`	IANA Media Types 레지스트리에 등재된 유효한 미디어 타입으로, 선택 사항이다.
`digestSRI`	Subresource Integrity 규격의 Section 3.5: The `integrity` attribute에 정의된 `hash-expression` ABNF 문법이 정의하는 하나 이상의 암호학적 다이제스트.
`digestMultibase`	Verifiable Credential Data Integrity 1.0 규격의 Section 2.6: Resource Integrity에 있는 `digestMultibase` 속성이 정의하는 하나 이상의 암호학적 다이제스트.

relatedResource와 연관된 각 객체는 최소한 digestSRI나 digestMultibase 값을 담고 있어야 한다.

mediaType이 명시된 경우, HTTP Semantics를 사용하여 id 속성이 식별하는 자원을 가져오는 구현은 다음과 같이 하는 것이 좋다.

Accept HTTP 헤더에 그 미디어 타입을 사용한다.
응답에 다른 미디어 타입을 가진 Content-Type HTTP 헤더가 포함되어 있으면 그 응답을 거부한다.

검증가능한 크리덴셜 안에서 id 속성을 담고 있는 객체는 digestSRI나 digestMultibase 속성을 추가하여 무결성 정보로 주석할 수 있으며, 이 둘 중 어느 것에든 추가로 선택적인 mediaType 속성이 함께 올 수 있다.

선택적 공개나 연결 불가능한 공개를 원하는 객체는 relatedResource 배열 안의 객체로 포함하지 않는 것이 좋다.

적합 문서 안의 relatedResource 객체의 id에 근거하여 자원을 사용하고, 그에 대응하는 암호학적 다이제스트가 relatedResource 객체 값에 나타나는 적합 검증자 구현은 가져온 자원의 다이제스트를 계산해야 한다. 발급자가 제공한 다이제스트가 가져온 자원에 대해 계산된 다이제스트와 일치하지 않으면, 그 적합 검증자 구현은 오류를 발생시켜야 한다.

구현자는 현재 통용되며 신뢰할 수 있는 해시 알고리즘을 선택하고 있는지 확인하기 위해 FIPS 180-4 Secure Hash Standard나 Commercial National Security Algorithm Suite 2.0과 같은 적절한 자료를 참고할 것을 강력히 권한다. 이 글을 쓰는 시점에 구현자가 사용할 최소 강도의 해시 알고리즘은 sha384로 보는 것이 좋다.

JSON-LD 컨텍스트를 참조하는 관련 자원 무결성 객체의 예시이다.

예시 25: digestSRI 속성의 사용 (base64로 인코딩된 SHA2-384)

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestSRI":
    "sha384-Ml/HrjlBCNWyAX91hr6LFV2Y3heB5Tcr6IeE4/Tje8YyzYBM8IhqjHWiWpr8+ZbYU"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestSRI":
    "sha384-MzNNbQTWCSUSi0bbz7dbua+RcENv7C6FvlmYJ1Y+I727HsPOHdzwELMYO9Mz68M26"
}]

예시 26: digestMultibase 속성의 사용 (base64-url-nopad로 인코딩된 SHA2-256)

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestMultibase": "uEiBZlVztZpfWHgPyslVv6-UwirFoQoRvW1htfx963sknNA"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestMultibase": "uEiBXOT-8adbvubm13Jy2uYgLCUQ2Cr_i6vRZyeWM8iedfA"
}]

시스템이 만료된 검증가능한 크리덴셜을 수동 또는 자동으로 갱신할 수 있게 하는 것은 유용하다. 검증가능한 크리덴셜의 유효 기간에 대한 자세한 내용은 A.7 유효 기간 절을 참조한다. 이 규격은 refreshService 속성을 정의하며, 이를 통해 발급자는 갱신 서비스로의 링크를 포함할 수 있다.

발급자는 갱신 서비스가 검증자나 보유자(또는 둘 다)를 위한 것이라면 그것을 검증가능한 크리덴셜 안의 요소로 포함할 수 있고, 보유자만을 위한 것이라면 검증가능한 프레젠테이션 안에 포함할 수 있다. 후자의 경우, 이를 통해 보유자는 검증자와 공유할 검증가능한 프레젠테이션을 만들기 전에 그 검증가능한 크리덴셜을 갱신할 수 있다. 전자의 경우, 갱신 서비스를 검증가능한 크리덴셜 안에 포함하면 보유자나 검증자가 이후 그 크리덴셜을 갱신할 수 있다.

갱신 서비스는 크리덴셜이 만료되었거나 발급자가 크리덴셜 상태 정보를 게시하지 않는 경우에만 사용될 것으로 기대된다. 발급자는 공개 정보를 담고 있지 않거나 갱신 서비스가 어떤 식으로도 보호되지 않는 검증가능한 크리덴셜에는 refreshService 속성을 넣지 않을 것을 권한다.

refreshService: refreshService 속성의 값은, 수신자가 검증가능한 크리덴셜을 갱신할 수 있도록 수신자의 소프트웨어에 충분한 정보를 제공하는 하나 이상의 갱신 서비스이어야 한다. 각 refreshService 값은 자신의 type을 명시해야 한다. 각 갱신 서비스의 정확한 내용은 구체적인 refreshService 타입 정의가 결정한다.

예시 27: 발급자의 refreshService 속성 사용

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/age/v1"
  ],
  "type": ["VerifiableCredential", "AgeVerificationCredential"],
  "issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks",
  "validFrom": "2024-04-03T00:00:00.000Z",
  "validUntil": "2024-12-15T00:00:00.000Z",
  "name": "Age Verification Credential",
  "credentialSubject": {
    "overAge": 21
  },
  "refreshService": {
    "type": "VerifiableCredentialRefreshService2021",
    "url": "https://registration.provider.example/flows/reissue-age-token",
    "refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg"
  }
}

위 예시에서 발급자는 검증가능한 크리덴셜을 갱신 서비스 url로 POST하여 사용할 수 있는 자동 refreshService를 명시한다. 이 특정 검증가능한 크리덴셜은 원래의 발급자 외에는 누구와도 공유되지 않도록 의도되었다는 점에 유의한다.

참고: 인증되지 않은 크리덴셜 갱신

검증자가 이용할 수 있도록 검증가능한 크리덴셜에 refreshService 속성을 넣으면 보유자로부터 통제권과 동의를 빼앗고, 그 검증가능한 크리덴셜이 보유자를 우회하여 검증자에게 직접 발급되도록 허용할 수 있다.

사용 조건은 발급자나 보유자가 검증가능한 크리덴셜이나 검증가능한 프레젠테이션이 어떤 조건 아래 발급되었는지 알리는 데 사용할 수 있다. 발급자는 자신의 사용 조건을 검증가능한 크리덴셜 안에 넣는다. 보유자는 자신의 사용 조건을 검증가능한 프레젠테이션 안에 넣는다. 이 규격은 사용 조건 정보를 표현하기 위해 termsOfUse 속성을 정의한다.

termsOfUse 속성의 값은 무엇보다도 검증자에게 다음의 일부 또는 전부를 알리는 데 사용될 수 있다.

검증가능한 크리덴셜을 발급할 때 사용된 절차나 정책. 예를 들어 그 절차나 정책을 찾을 수 있는 공개 위치("폰 홈" 프라이버시 문제를 피하기 위해)를 가리키는 포인터나, 그것을 정의하는 표준의 이름을 제공하는 방식이다.
이 검증가능한 크리덴셜을 검증자에게 제시하는 데 적용되는 발급자의 규칙과 정책. 예를 들어 그 규칙이나 정책을 찾을 수 있는 공개 위치("폰 홈" 프라이버시 문제를 피하기 위해)를 가리키는 포인터를 제공하는 방식이다.
발급자가 이 특정 검증가능한 크리덴셜을 발급할 때 그 권한의 근거가 된 엔티티의 신원

termsOfUse: termsOfUse 속성의 값은 작성자가 그 크리덴셜이나 프레젠테이션을 발급할 때 근거로 삼은 하나 이상의 사용 조건 정책을 명시해야 한다. 수신자(보유자나 검증자)가 명시된 사용 조건을 준수할 의사가 없다면, 그것은 자신의 책임으로 하는 것이며 명시된 사용 조건을 위반할 경우 법적 책임을 질 수 있다. 각 termsOfUse 값은 자신의 타입(예: TrustFrameworkPolicy)을 명시해야 하며, 자신의 인스턴스 id를 명시할 수 있다. 각 사용 조건의 정확한 내용은 구체적인 termsOfUse 타입 정의가 결정한다.

예시 28: 발급자의 termsOfUse 속성 사용

{
  {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/undefined-terms/v2"
    ],
    "id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b",
    "type": [
      "VerifiableCredential",
      "VerifiableAttestation",
      "VerifiableTrustModel",
      "VerifiableAuthorisationForTrustChain"
    ],
    "issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z",
    "validFrom": "2021-11-01T00:00:00Z",
    "validUntil": "2024-06-22T14:11:44Z",
    "credentialSubject": {
      "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde",
      "reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "permissionFor": [{
        "schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6",
        "types": [
          "VerifiableCredential",
          "VerifiableAttestation",
          "WorkCertificate"
        ],
        "jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR"
      }]
    },
    "termsOfUse": {
      "type": "TrustFrameworkPolicy",
      "trustFramework": "Employment&Life",
      "policyId": "https://policy.example/policies/125",
      "legalBasis": "professional qualifications directive"
    },
    "credentialStatus": {
      "id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8",
      "type": "EbsiAccreditationEntry"
    },
    "credentialSchema": {
      "id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH",
      "type": "JsonSchema"
    }
  }
}

위 예시에서 발급자는 그 검증가능한 크리덴셜이 발급된 법적 근거가 "Employment&Life" 신뢰 프레임워크를 사용하는 "professional qualifications directive"임을 주장하며, 해당 정책으로의 구체적인 링크를 함께 제시하고 있다.

이 기능은 정부가 발급한 검증가능한 크리덴셜이 민감한 데이터가 예상치 못하게 사용되는 것으로부터 시민을 보호하기 위해, 디지털 지갑에 그 사용을 유사한 정부 기관으로 제한하도록 지시하는 데 쓰일 것으로 기대된다. 마찬가지로 민간 산업이 발급하는 일부 검증가능한 크리덴셜은 사용을 조직 내부 부서로, 또는 업무 시간 중으로 제한할 것으로 기대된다. 구현자는 발전 중인 이 기능에 대해 Verifiable Credentials Implementation Guidelines [VC-IMP-GUIDE] 문서의 해당 절에서 더 읽어볼 것을 강력히 권한다.

발급자는 검증가능한 크리덴셜에 검증자를 위한 추가 뒷받침 정보를 제공하기 위해 증거를 포함할 수 있다. 검증자는 이를 사용하여 그 검증가능한 크리덴셜의 클레임을 어느 정도 신뢰할지 확립할 수 있다. 예를 들어 발급자는 크리덴셜을 발급하기 전에 주체가 제공한 물리적 문서를 확인하거나 일련의 배경 조사를 수행할 수 있다. 특정 시나리오에서 이 정보는 검증자가 주어진 크리덴셜을 신뢰하는 데 따르는 위험을 판단할 때 유용하다.

이 규격은 증거 정보를 표현하기 위해 evidence 속성을 정의한다.

evidence

존재하는 경우 evidence 속성의 값은 단일 객체이거나 하나 이상의 객체의 집합이어야 한다. 모든 증거 객체에 대해 다음 속성이 정의된다.

id: id 속성은 선택 사항이다. 증거 객체의 고유 식별자를 제공하는 데 사용할 수 있다. 존재하는 경우 4.4 식별자 절의 규범적 지침을 따라야 한다.
type: type 속성은 필수이다. 해당 객체가 표현하는 증거 정보의 타입을 표현하는 데 사용된다. 4.5 타입 절의 관련 규범적 지침을 따라야 한다.

참고: 증거 제공 전략은 구현 가이드를 참조한다

크리덴셜 및 크리덴셜이 아닌 데이터에 대한 첨부와 참조를 이 규격이 어떻게 지원할 수 있는지에 대한 정보는 5.3 관련 자원의 무결성 절을 참조한다.

예시 29: 기술 성취 크리덴셜을 뒷받침하는 증거의 예시

{
  "@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 to an externally hosted evidence file/artifact
      "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.",
      // digest hash of the mp4 video file
      "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
    }
  ]
}

위 evidence 예시에서 발급자는 그 크리덴셜의 주체가 해당 성취를 시연하는 영상을 보유하고 있음을 주장하고 있다.

참고: 증거는 보안 메커니즘과 목적이 다르다

evidence 속성은 사용된 보안 메커니즘과는 다른 정보를 제공한다. evidence 속성은 검증가능한 크리덴셜과 관련된 문서 증거와 같은 뒷받침 정보를 표현하는 데 사용된다. 반면 보안 메커니즘은 발급자의 진정성과 검증가능한 크리덴셜의 무결성에 관한, 기계가 검증할 수 있는 수학적 증명을 표현하는 데 사용된다. 보안 메커니즘에 대한 자세한 내용은 4.12 보안 메커니즘 절을 참조한다.

영지식 증명은 보유자가 어떤 값을 담고 있는 검증가능한 크리덴셜을 보유하고 있음을, 그 실제 값을 공개하지 않고도 증명할 수 있게 해 주는 보안 메커니즘이다. 예를 들어 생년월일을 드러내지 않고도 어떤 개인이 25세 이상임을 증명할 수 있다. 이 데이터 모델은 영지식 증명을 사용한 보호를 지원한다.

검증가능한 크리덴셜과 호환되며 영지식 증명 메커니즘이 가능하게 하는 기능에는 다음과 같은 것들이 있다.

보유자가 검증자에게 하는 검증가능한 크리덴셜 속성의 선택적 공개. 이를 통해 보유자는 검증자에게 그가 필요로 하는 정보만 정확히 제공하고 그 이상은 제공하지 않을 수 있다. 또한 제시 과정에서 발급자가 관여할 필요 없이 검증자의 데이터 스키마에 맞춘 파생 검증가능한 크리덴셜을 만들어낼 수 있다. 이는 보유자가 자신에게 발급된 검증가능한 크리덴셜을 사용하는 데 큰 유연성을 제공한다.
보유자가 검증자에게 하는 검증가능한 크리덴셜 속성의 연결 불가능한 공개. 블라인드 서명은 연결 불가능한 공개를 가능하게 하며, 이는 하나 이상의 검증자에게 여러 번 제시하는 동안 보유자의 상관관계가 드러나는 흔한 원인을 제거한다. 이를 통해 보유자는 제시할 때마다 서로 다른 서명 값을 공유할 수 있고, 그 결과 공유되는 데이터의 양이 줄어든다.
보유자나 주체의 상관관계를 지을 수 없는 식별. 이를 통해 보유자는 상관관계를 지을 수 있는 식별자를 공유하지 않고도 어떤 크리덴셜이 자신에게 발급되었음을, 주체는 어떤 크리덴셜이 자신에 대해 발급되었음을 증명할 수 있다. 이 역시 공유해야 할 데이터의 양을 줄인다. 이 기능은 또한 검증자에게 검증가능한 크리덴셜이나 주체의 식별자를 드러내지 않고, 여러 발급자의 여러 검증가능한 크리덴셜을 하나의 검증가능한 프레젠테이션으로 결합하는 데도 사용할 수 있다.

보안 메커니즘을 만드는 규격 작성자는, 서로 다른 검증자에게 여러 번 제시된 검증가능한 프레젠테이션에 걸쳐 검증자가 보유자의 상관관계를 지을 수 있게 하는 정보가 새어나가도록 설계해서는 안 된다.

모든 영지식 증명 메커니즘이 모든 기능을 지원하는 것은 아니다. 특정 영지식 증명 메커니즘이 제공하는 기능과 기법에 대한 구체적인 세부 사항은, 그것을 검증가능한 크리덴셜과 함께 사용하기 위한 규범적 요구사항과 더불어, 그 영지식 증명 메커니즘으로 검증가능한 크리덴셜을 보호하는 규격에서 찾을 수 있다. 그러한 규격의 예로는 Data Integrity BBS Cryptosuites v1.0을 참조한다.

대부분의 경우 보유자가 검증가능한 크리덴셜에 영지식 메커니즘을 활용하려면 발급자가 이러한 기능을 지원하는 방식으로 그 검증가능한 크리덴셜을 보호해야 한다는 점에 유의한다.

아래 다이어그램은 영지식 방식으로 검증가능한 크리덴셜을 발급하고 제시하는 데 이 데이터 모델이 어떻게 사용될 수 있는지 보여준다.

Verifiable
Credential 1 and Verifiable Credential 2 on the left map
to Derived Credential 1 and Derived Credential 2 inside a
Presentation on the right. Verifiable Credential 1
contains Context, Type, ID, Issuer, Issue Date, Expiration
Date, CredentialSubject, and Proof, where
CredentialSubject contains GivenName, FamilyName, and
Birthdate and Proof contains Signature, Proof of
Correctness, and Attributes. Verifiable Credential 2
contains Context, Type, ID, Issuer, Issue Date, Expiration
Date, CredentialSubject, and Proof, where
CredentialSubject contains University, which contains
Department, which contains DegreeAwarded, and Proof contains Signature, Proof of
Correctness, and Attributes. The Presentation diagram on
the right contains Context, Type, ID,
VerifiableCredential, and Proof, where
VerifiableCredential contains Derived Credential 1 and
Derived Credential 2 and Proof contains Common Link
Secret. Derived Credential 1 contains Context, Type, ID,
Issuer, Issue Date, CredentialSubject, and Proof, where
CredentialSubject contains AgeOver18 and Proof contains
Knowledge of Signature. Derived Credential 2 contains
Context, Type, ID, Issuer, Issue Date, CredentialSubject,
and Proof, where CredentialSubject contains Degree and
Proof contains Knowledge of Signature. A line links
Birthdate in Verifiable Credential 1 to AgeOver18 in
Derived Credential 1. A line links DegreeAwarded in
Verifiable Credential 2 to Degree in Derived Credential 2. — Figure 12 ZKP 프레젠테이션에서 크리덴셜과 파생 크리덴셜의 관계를 보여주는 시각적 예시.

Data Integrity BBS Cryptosuites v1.0의 연결 불가능한 선택적 공개 보안 메커니즘을 사용하는 검증가능한 크리덴셜과 검증가능한 프레젠테이션의 예시를 아래에 보인다.

예시 30: Data Integrity BBS 크립토스위트의 기본 증명을 사용하는 검증가능한 크리덴셜

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v3"
  ],
  "type": ["VerifiableCredential", "PermanentResidentCard"],
  "issuer": {
    "id": "did:web:credentials.utopia.example",
    "image": "data:image/png;base64,iVBORw0KGgo...YII="
  },
  "identifier": "83627465",
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "validFrom": "2024-08-01T00:00:00Z",
  "validUntil": "2029-12-01T00:00:00Z",
  "credentialSubject": {
    "type": ["PermanentResident", "Person"],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...Jggg==",
    "residentSince": "2015-01-01",
    "lprCategory": "C09",
    "lprNumber": "999-999-999",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:web:playground.alpha.chapi.io#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQjYs9O7wUb3KRSMaIRX7jmafVHYDPYBLD4ta85_qmuXTBU_t2Ir7pNujwRE6fERsBUEZRSjJjtI-hqOqDs3VvBvH6gd3o2KeUS2V_zpuphPpYQEkapOeQgRTak9lHKSTqEQqa4j2lyHqekEeGvzPlqcHQGFccGifvLUXtP59jCuGJ86HDA9HL5kDzUT6n4Gi50HlYYIzNqhbjIxlqOuxO2IgIppSTWjQGeer34-PmKnOzKX8m_9DHPhif7TUf5uTV4OQWdhb0SxHnJ-CPu_z9FJ5ACekBQhz6YWS0_CY6j_ibucXzeVfZwLv1W47pjbt-l1Vl5VggSn2xVt69Q0GD9mPKpOhkKV_hyOL7i6haf7bq-gOKAwWDZy9pc3N1ZXJtL2lzc3VhbmNlRGF0ZW8vZXhwaXJhdGlvbkRhdGU"
  }
}

위 예시는 발급자가 BBS 기반의 연결 불가능한 공개 방식을 적용하여 기본 증명(base proof)을 만든 검증가능한 크리덴셜이다. 보유자는 이후 그 기본 증명을 사용하여, 원래의 검증가능한 크리덴셜에서 특정 정보만 드러내는 파생 증명을 만들 수 있다.

예시 31: Data Integrity BBS 크립토스위트의 파생 크리덴셜과 증명을 사용하는 검증가능한 프레젠테이션

{
  @context: "https://www.w3.org/ns/credentials/v2"
  type: "VerifiablePresentation",
  verifiableCredential: {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v3"
    ],
    "type": ["VerifiableCredential", "PermanentResidentCard"],
    "issuer": {
      "id": "did:web:issuer.utopia.example",
      "image": "data:image/png;base64,iVBORw0KGgo...YII="
    },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "validFrom": "2024-08-01T00:00:00Z",
    "validUntil": "2029-12-01T00:00:00Z",
    "credentialSubject": {
      "type": ["PermanentResident", "Person"],
      "birthCountry": "Arcadia"
    },
    "proof": {
      type: "DataIntegrityProof",
      verificationMethod: "did:web:issuer.utopia.example#zUC75LjjCLGKRxSissX1nAebRDmY4Bv4T6MAbzgaap9Q8rAGf6SEjc2Hf4nH6bUPDwky3GWoYcUjMCcEqRRQfXEiNwfeDwNYLoeqk1J1W2Ye8vCdwv4fSd8AZ1yS6UoNzcsQoPS",
      cryptosuite: "bbs-2023",
      proofPurpose: "assertionMethod",
      proofValue: "u2V0DhVkCkLdnshxHtgeHJBBUGPBqcEooPp9ahgqs08RsoqW5EJFmsi70jqf2X368VcmfdJdYcYJwObPIg5dlyaoBm34N9BqcZ4RlTZvgwX79ivGnqLALC0EqKn2wOj5hRO76xUakfLGIcT4mE-G7CxA1FTs8sRCWy5p6FozelBYiZU2YlhUpJ7pBwelZ9wnlcbj4q-KyxAj5GU2iWp7-FxU-E624DmdT-yvCkAGRRrYej6lMwg7jB9uCHypOXXH2dVZ-jpf74YBaE4rMTxPFh60GN4o3S65F1fMsJbEMLdrXa8Vs6ZSlmveUcY1X7oPr1UIxo17ehVTCjOxWunYqrtLi9cVkYOD2s9XMk1oFVWBB3UY29axXQQXlZVfvTIUsfVc667mnlYbF7a-ko_SUfeY2n3s1DOAap5keeNU0v2KVPCbxA2WGz7UJy4xJv2a8olMOWPKjAEUruCx_dsbyicd-9KGwhYoUEO3HoAzmtI6qXVhMbJKxPrhtcp8hOdD9izVS5ed4CxHNaDGPSopF_MBwjxwPcpUufNNNdQwesrbtFJo0-P-1CrX_jSxKFMle2b3t24UbHRbZw7QnX4OG-SSVucem5jpMXTDFZ8PLFCqXX0zncJ_MQ-_u-liE-MwJu3ZemsXBp1JoB2twS0TqDVzSWR7bpFZKI9_07fKUAmQNSV_no9iAgYRLuPrnnsW1gQgCV-nNqzbcCOpzkHdCqro6nPSATq5Od3Einfc683gm5VGWxIldM0aBPytOymNz7PIZ6wkgcMABMe5Vw46B54ftW-TN5YZPDmCJ_kt7Mturn0OeQr9KJCu7S0I-SN14mL9KtGE1XDnIeR-C_YZhSA3vX4923v1l3vNFsKasqy9iEPHKM0hcogABAQCGAAECBAUGhAMJCgtYUnsiY2hhbGxlbmdlIjoiNGd2OFJyaERPdi1OSHByYlZNQlM1IiwiZG9tYWluIjoiaHR0cHM6Ly9wbGF5Z3JvdW5kLmFscGhhLmNoYXBpLmlvIn0"
    }
  }
}

위 검증가능한 프레젠테이션에는 앞 예시의 정보 중 연결 불가능한 부분집합을 담은 검증가능한 크리덴셜과, 그 정보가 기대한 발급자로부터 비롯되었고 이 특정 정보 교환에 결속되어 있음을 검증자가 검증하는 데 사용할 수 있는 파생 증명이 담겨 있다.

구현자는 시간 값을 표현하고 처리하는 일이 보기보다 단순하지 않으며, 즉각적으로 드러나지도 않고 세계 각 지역에서 일률적으로 지켜지지도 않는 여러 특이점이 있다는 점을 이해할 것을 강력히 권한다. 예를 들면 다음과 같다.

그레고리력이 아닌 역법이 여러 지역에서 활발히 사용된다.
일광 절약 시간제(서머타임)를 처리할 때는 1) 모든 지역이 이를 시행하지는 않고, 2) 반드시 같은 날 또는 같은 시각에 시작하거나 끝나지 않으며, 3) 조정의 크기나 방향이 비슷한 다른 지역과 항상 일치하지는 않는다는 점을 이해하는 것이 중요하다.
윤초는 모든 소프트웨어 시스템에서 고려되지 않을 수 있으며, 특히 윤초 도입 이전의 일시에 대해 그렇다. 윤초는 에포크로부터의 정확한 밀리초 오프셋에 의존하는 매우 민감한 시스템에 영향을 줄 수 있다. 그러나 대부분의 애플리케이션에서 영향을 받는 시점은 윤초 자체의 1초 구간뿐이라는 점에 유의한다. 즉 가장 최근 윤초 직후의 시점은, 해당 시스템이 윤초를 이해하든 그렇지 않든, 언제나 다음 날의 첫 순간(예: 2023-01-01T00:00:00Z)으로 표현될 수 있다.

이는 벽시계에 보이는 실제 시각이 어떤 지역에는 존재하지만 다른 지역에는 존재하지 않을 수 있음을 보여주는 몇 가지 예시일 뿐이다. 이런 이유로 구현자는 일광 절약 시간제의 영향을 받는 값보다 Z 시간대에 고정된 값처럼 더 보편적인 시간 값을 사용할 것을 강력히 권한다.

이 규격은 [XMLSCHEMA11-2] 규격이 처음 확립한 dateTimeStamp 구성을 사용하여, 보편적으로 인식되는 일시 조합의 수를 늘리고 시간 값이 잘못 해석될 여지를 줄이고자 한다. 서로 다른 시간대 사이의 오해를 줄이기 위해, 적합 문서에 표현되는 모든 시간 값은 dateTimeStamp 형식으로, 값 끝에 Z를 붙여 협정 세계시(UTC)로 나타내거나 UTC 기준 시간대 오프셋과 함께 명시하는 것이 좋다. 오프셋 없이 잘못 직렬화된 시간 값은 UTC로 해석해야 한다. 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이 되도록 재발급될 수 있는데, 이 경우 그 검증가능한 크리덴셜이 유효하지 않은 1시간의 공백이 생긴다.

dateTimeStamp 값의 유효성을 확인하려는 구현자는 아래 제공된 정규 표현식을 사용할 수 있으며, 이는 편의를 위해 [XMLSCHEMA11-2] 규격에서 그대로 옮겨온 것이다. 오해를 피하기 위해 밝히면, 규범적 정의는 [XMLSCHEMA11-2]의 정규 표현식이다. 구현자는 아래 정규 표현식을 통과하는 dateTimeStamp 값이 모두 유효한 시점인 것은 아니라는 점에 유의해야 한다. 예를 들어 아래 정규 표현식은 모든 달에 31일을 허용하므로 윤년과 윤초는 물론 존재하지 않는 곳의 날짜까지 허용한다. 그렇지만 dateTimeStamp 값을 생성하는 현대적인 시스템 라이브러리는 유효한 dateTimeStamp 값을 생성하는 데 대체로 오류가 없다. 아래에 보인 정규 표현식은(가독성을 위해 여기 포함된 공백을 제외하면) 현대적인 시스템에서 라이브러리가 생성한 일시를 처리할 때 대체로 충분하다.

예시 32: 유효한 XML Schema 1.1: Part 2 dateTimeStamp를 검출하는 정규 표현식

-?([1-9][0-9]{3,}|0[0-9]{3})
-(0[1-9]|1[0-2])
-(0[1-9]|[12][0-9]|3[01])
T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))

This section is non-normative.

검증가능한 크리덴셜은 주체를 신뢰할 수 있게 식별하는 수단으로 의도되었다. 역할 기반 접근 제어(RBAC)와 속성 기반 접근 제어(ABAC)가 주체에게 자원 접근을 인가하는 수단으로 이 식별에 의존한다는 점은 인정되지만, 이 규격은 RBAC나 ABAC에 대한 완전한 해법을 제공하지 않는다. 인가 프레임워크가 함께하지 않는 한, 인가는 이 규격의 적절한 용도가 아니다.

워킹 그룹은 이 규격을 만드는 과정에서 인가 사용 사례를 검토했으며, 그 작업을 이 규격 위에 구축되는 아키텍처 계층으로서 추진하고 있다.

이 규격은 확장점이 될 수 있는 여러 속성을 예약해 둔다. 일부 구현자가 이 속성들에 관심을 보였으나, 이를 이 규격에 포함하는 것은 시기상조로 판단되었다. 이 속성들 중 어느 것도 이 규격이 정의하지 않는다는 점에 유의하는 것이 중요하다. 따라서 구현자는 이 속성들의 사용이 실험적인 것으로 간주된다는 점에 주의해야 한다.

구현자는 이 속성들을 사용할 수 있지만, 이를 규범적으로 명세하는 과정에서 속성 자체나 그 의미가 바뀔 것으로 예상하는 것이 좋다. 구현자는 자신의 구현을 기술하는, 공개적으로 공표된 규격 없이 이 속성들을 사용하지 않는 것이 좋다.

다음 속성들이 사용되는 방식에 대한 충돌을 피하기 위해, 구현은 예약된 속성과 연관된 값에 type 속성을 명시해야 한다. type 정보 추가와 관련된 자세한 내용은 4.5 타입 절을 참조한다.

예약된 속성	설명
`confidenceMethod`	검증가능한 크리덴셜이나 검증가능한 프레젠테이션 안의, 또는 그 자체의 속성 값이 정확하다는 확신을 검증자가 높이는 데 사용할 수 있는 하나 이상의 방법을 명시하는 속성이다. 연관된 어휘 URL은 `https://www.w3.org/2018/credentials#confidenceMethod`이어야 한다.
`renderMethod`	크리덴셜을 시각적, 청각적, 촉각적, 또는 그 밖의 형식으로 렌더링하는 하나 이상의 방법을 명시하는 속성이다. 연관된 어휘 URL은 `https://www.w3.org/2018/credentials#renderMethod`이어야 한다.

이 규격이 정의하는 확장점 및 이 절이 정의하는 예약된 확장점과 연관된 규격들의 비공식 목록은 Verifiable Credential Extensions에서 찾을 수 있다. 그 디렉터리에서 예약된 확장점을 가리키는 항목은 실험적인 것으로 취급하는 것이 좋다.

이 문서가 제공하는 데이터 모델을 기본적으로 사용하지는 않지만 이 규격의 여러 개념과 부합하는 디지털 크리덴셜 형식이 다수 있다. 이 문서의 발행 시점 기준으로 그러한 디지털 크리덴셜 형식의 예로는 다음이 있다. JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs), JSON Advanced Electronic Signature (JAdES), ISO-18013-5:2021 (mDLs), AnonCreds, Gordian Envelopes, and Authentic Chained Data Containers (ACDCs).

개념적으로 부합하는 디지털 크리덴셜 형식이 이 절이 제공하는 규칙에 따라 적합 문서로 변환될 수 있다면, 그 형식은 "W3C 검증가능한 크리덴셜 생태계와 호환된다"고 간주된다. 규격 작성자는 검증가능한 크리덴셜 생태계와의 호환성을 가능하게 하는 변환을 문서화할 때 다음 규칙을 준수할 것을 권한다. 그 변환 규격은 —

이 데이터 모델로의 변환이 단방향인지 왕복 가능한지 식별해야 한다.
왕복 가능한 변환을 수행할 때 @context 값을 보존해야 한다.
이 규격이 기술하는 데이터 모델로 변환할 때 그 결과가 적합 문서이어야 한다.
입력 문서에 대해 등록된 미디어 타입을 명시해야 한다.
이 규격의 데이터 모델로의, 명시된 변환 알고리즘이 적합 문서를 만들어냄을 보여주는 테스트 스위트를 제공하는 것이 좋다.
변환된 적합 문서에서 사용되는 모든 의미론이 Linked Data의 모범 사례를 따르도록 보장하는 것이 좋다. 추가 지침은 4.1 시작하기 절, 5.2 확장성 절, 그리고 Linked Data Best Practices [LD-BP]를 참조한다.

참고: 무엇이 검증가능한 크리덴셜을 구성하는가?

독자는 디지털 크리덴셜이 W3C 검증가능한 크리덴셜 생태계와 호환된다고 간주되려면, 이 규격의 각 요구사항이 기술하는 대로 적합 문서이면서 최소한 하나의 보안 메커니즘을 사용해야 한다는 점에 유의해야 한다. 어떤 커뮤니티는 적합 문서가 아닌 일부 디지털 크리덴셜 형식을 "검증가능한 크리덴셜"이라 부를 수도 있으나, 그렇게 부른다고 해서 그 디지털 크리덴셜이 이 규격을 준수하게 되는 것은 아니다.

검증가능한 크리덴셜을 (예컨대 프레젠테이션에서) 표현할 때, 한 검증가능한 크리덴셜의 데이터가 다른 검증가능한 크리덴셜의 데이터와 같은 것으로 오인되지 않도록 하는 것이 중요하다. 예를 들어 각각 {"type": "Person", "name": "Jane Doe"} 형태의 객체를 담은 두 검증가능한 크리덴셜이 있다면, 한 객체가 다른 객체와 같은 사람을 기술하는지 알 수 없다. 다시 말해 두 검증가능한 크리덴셜이 같은 엔티티나 속성을 다루고 있는지 확인하지 않고 그 사이의 데이터를 병합하면 데이터 집합이 오염될 수 있다.

서로 다른 검증가능한 크리덴셜의 데이터가 실수로 뒤섞이지 않도록, 각 검증가능한 크리덴셜을 캡슐화하는 데 검증가능한 크리덴셜 그래프라는 개념이 사용된다. 단순한 검증가능한 크리덴셜의 경우, 즉 JSON-LD 문서가 연관된 증명을 가질 수도 있는 크리덴셜 하나만 담고 있는 경우, 이 그래프는 기본 그래프이다. 프레젠테이션의 경우, 그 프레젠테이션의 verifiableCredential 속성과 연관된 각 값은 VerifiableCredentialGraph 타입의 별도 명명된 그래프이며, 여기에는 단일 검증가능한 크리덴셜이나 봉투로 감싼 검증가능한 크리덴셜이 담긴다.

이 그래프를 사용하는 것은 JSON-LD 처리를 수행할 때 구체적인 효과가 있으며, 한 그래프의 그래프 노드 식별자를 다른 그래프의 것과 제대로 분리해 준다. 입력을 애플리케이션 특화 JSON-LD 문서로 한정하는 구현자도, 한 검증가능한 크리덴셜의 데이터를 다른 것의 데이터와 병합한다면 이 점을 유념해야 한다. 예컨대 두 검증가능한 크리덴셜에서 credentialSubject.id가 같지만, 그 객체에 앞 문단에서 설명한 "Jane Doe" 형태의 객체가 담겨 있을 수 있는 경우가 그렇다. 비슷한 속성을 가진 것처럼 보이지만 URL과 같은 전역 식별자를 사용하는 id 속성을 담고 있지 않은 객체는 병합하지 않는 것이 중요하다.

4.12 보안 메커니즘 절에서 설명한 바와 같이, 구현자가 적합 문서를 보호할 때 사용할 수 있는 전략은 여러 가지다. 유용성과 상호 운용성을 극대화하기 위해, 적합 문서를 보호하는 새로운 방식을 작성하려는 규격 작성자에게 이 절의 지침을 제공한다.

보안 메커니즘 규격은 적합 문서에 콘텐츠 무결성 보호를 제공하는 규범적 알고리즘을 문서화해야 한다. 그 알고리즘은 일반적인 성격을 가질 수 있으며, 적합 문서가 아닌 데이터를 보호하는 데 사용될 수도 있다.

보안 메커니즘 규격은, 보호된 적합 문서의 정보를 proof나 JOSE/COSE 헤더 매개변수 및 서명과 같은 보안 메커니즘 정보를 포함하지 않고 그 자체만 반환하는 검증 알고리즘을 제공해야 한다. 검증 알고리즘은 보안 메커니즘의 세부 사항처럼 (예를 들어 유효성 검사 중이나 디버깅 목적에) 도움이 될 수 있는 추가 정보를 반환할 수 있다. 검증 알고리즘은 미디어 타입(문자열 inputMediaType)과 입력 데이터(바이트 시퀀스 또는 맵 inputData)를 받는 인터페이스를 제공해야 한다. 보안 메커니즘 규격은 이 문서가 명시하는 것 외에 추가 알고리즘과 인터페이스를 제공할 수 있다. 검증 알고리즘은 최소한 다음 항목을 담은 검증 결과를 반환한다.

boolean verified: 검증이 성공하면 값이 true, 성공하지 못하면 false인 검증 상태.
map verifiedDocument: 성공적으로 보호된 정보만 담고 있는 문서.
string mediaType: [RFC6838]이 정의하는 미디어 타입.

보안 메커니즘 규격은 유효성 검사에 결정적인, URL이 참조하는 모든 정보에 무결성 보호를 제공하는 것이 좋다. 이 보호를 달성할 수 있는 메커니즘은 5.3 관련 자원의 무결성 절과 B.1 기본 컨텍스트 절에서 논의한다.

새로운 유형의 내장 증명을 만드는 보안 메커니즘 규격은 검증가능한 크리덴셜이나 검증가능한 프레젠테이션을 증명 그래프에 연결하는 속성을 명시해야 한다. 보안 메커니즘에 대한 요구사항은 다음과 같다.

보안 메커니즘은 증명 그래프가 사용하는 모든 용어를 정의해야 한다. 예를 들어 그 메커니즘은 이 규격이 사용하는 것과 동일한 방식으로 어휘 규격과 @context 파일을 정의할 수 있다.
보안 메커니즘은 그 검증가능한 크리덴셜이나 검증가능한 프레젠테이션 자체를 보호하는 증명 그래프를 제외한, 검증가능한 크리덴셜이나 검증가능한 프레젠테이션의 모든 그래프를 보호해야 한다.

Note

마지막 요구사항은 보안 메커니즘이 기본 그래프를, 그리고 검증가능한 프레젠테이션의 경우 그 프레젠테이션의 각 검증가능한 크리덴셜을 각각의 증명 그래프와 함께 보호한다는 뜻이다. See also Figure 9 or Figure 14.

[VC-DATA-INTEGRITY]가 정의하는 proof 속성을 내장 보안 메커니즘이 사용할 수 있다.

보안 메커니즘 규격은 그 보안 메커니즘을 Verifiable Credential Extensions 문서의 Securing Mechanisms 절에 등록하는 것이 좋다.

참고: 보안 메커니즘 선택은 사용 사례에 따라 다르다

허용되는 보안 메커니즘은 여러 가지이며, 이 규격은 검증가능한 크리덴셜이나 검증가능한 프레젠테이션에 사용할 특정 보안 메커니즘을 의무화하지 않는다. 이 규격을 만든 워킹 그룹은 두 가지 보안 메커니즘 선택지를 표준화했는데, Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY]와 Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]이다. 커뮤니티에 알려진 다른 보안 메커니즘은 Verifiable Credential Extensions 문서의 Securing Mechanisms 절에서 찾을 수 있다.

3. 핵심 데이터 모델, 4. 기본 개념, 5. 고급 개념 절에서 기술한 데이터 모델은 검증가능한 크리덴셜이나 검증가능한 프레젠테이션의 표준적인 구조적 표현이다. 모든 구문은 그 데이터 모델을 특정 형식으로 표현한 것이다. 이 절은 각각 검증가능한 크리덴셜과 검증가능한 프레젠테이션의 기본 미디어 타입인 application/vc와 application/vp에 대해 데이터 모델이 JSON-LD로 어떻게 직렬화되는지 명시한다. 구문적 대응은 JSON-LD에 대해서만 제공되지만, 애플리케이션과 서비스는 application/vc나 application/vp로 다시 대응시킬 수 있는 다른 어떤 데이터 표현 구문(XML, YAML, CBOR 등)이든 사용할 수 있다. 검증과 유효성 검사 요구사항이 데이터 모델을 기준으로 정의되므로, 모든 직렬화 구문은 처리, 유효성 검사, 비교를 위해 결정적으로 데이터 모델로 번역될 수 있어야 한다.

이 규격에서 속성 값에 기대되는 항수(arity)와, 그 값을 담는 결과 데이터 타입은 속성에 따라 달라질 수 있다. 존재하는 경우 다음 속성들은 단일 값으로 표현된다: id (4.4 식별자 절), issuer(4.7 발급자 절), validFrom/validUntil(4.9 유효 기간 절). 그 밖의 모든 속성은 존재하는 경우 단일 값이거나 값의 배열로 표현된다.

이 규격은 여기서 기술하는 데이터 모델을 직렬화하는 데 JSON-LD 1.1을 사용한다. JSON-LD가 유용한 이유는 검증가능한 크리덴셜의 바탕이 되는 그래프 기반 데이터 모델과 기계가 읽을 수 있는 의미론을 표현할 수 있게 해 주기 때문이며, 데이터 모델을 확장할 때도 유용하다 (3. 핵심 데이터 모델 절과 5.2 확장성 절 참조).

JSON-LD는 Linked Data를 직렬화하는 데 사용되는 JSON 기반 형식이다. Linked Data는 자원 기술 프레임워크(RDF) [RDF11-CONCEPTS]를 사용하여 모델링된다. RDF는 진술의 그래프를 모델링하는 기술이다. 각 진술은 하나의 주체→속성→값(엔티티→속성→값 이라고도 한다) 관계이며, 이 규격에서는 이를 클레임이라 부른다. JSON-LD는 관용적인 JSON을 사용하여 RDF를 표현할 수 있게 하는 기술로, JSON에 익숙한 개발자가 RDF를 JSON으로 소비하는 애플리케이션을 작성할 수 있게 해 준다. 자세한 내용은 Relationship of JSON-LD to RDF를 참조한다.

일반적으로 이 문서가 기술하는 데이터 모델과 구문은 개발자가 검증가능한 크리덴셜을 대체로 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 표현 사용을 제한한다. application/vc나 application/vp 미디어 타입을 사용하는 데이터 모델의 모든 표현에는 JSON-LD 축약 문서 형식을 사용해야 한다.

6.3 타입별 크리덴셜 처리 절에서 자세히 설명하듯, 일부 소프트웨어 애플리케이션은 일반화된 JSON-LD 처리를 수행하지 않을 수 있다. 적합 문서의 작성자는 @base나 @vocab 키워드 중 하나 또는 둘 다를 설정하는 등, @context 값의 JSON-LD 키워드를 사용하여 검증가능한 크리덴셜이나 검증가능한 프레젠테이션의 값에 전역적으로 영향을 주면 상호 운용성이 떨어질 수 있다는 점에 유의해야 한다. 예를 들어 이 값들을 설정하면, 타입별 크리덴셜 처리를 수행하면서 @context 값에 @base나 @vocab 값이 표현되리라 예상하지 않는 구현에서, 잘못 구현된 @context 값의 JSON Schema 검사가 실패할 수 있다.

상호 운용성을 높이기 위해, 적합 문서 작성자는 타입별 크리덴셜 처리를 수행할 때 쉽게 감지되지 않는 JSON-LD 기능을 사용하지 않을 것을 강력히 권한다. 그러한 기능에는 다음이 포함된다.

@base나 @vocab 설정처럼, 문서의 용어 및 값 처리를 전역적으로 수정하는 JSON-LD 키워드를 @context 값에 인라인으로 선언하는 것
@vocab을 재설정하는 것처럼, 앞선 컨텍스트의 선언을 재정의하는 JSON-LD 컨텍스트를 사용하는 것
@context 속성에 JSON-LD 컨텍스트를 인라인으로 선언하는 것
JSON-LD @context 대응(예: https://www.w3.org/ns/credentials/v2)에 명시적으로 정의된 짧은 형태(예: VerifiableCredential이나 SomeNewType) 대신, JSON-LD 용어와 타입에 전체 URL(예: https://www.w3.org/2018/credentials#VerifiableCredential이나 https://vocab.example/myvocab#SomeNewType)을 사용하는 것

이 규격은 @vocab 사용에 주의를 당부하지만, 실험, 개발, 지역화된 배포를 쉽게 하는 등 이 기능의 정당한 용도도 있다. 용어 충돌을 줄이고 의미론적 상호 운용성의 이점을 살리기 위해 권장되지 않음에도 애플리케이션 개발자가 운영 환경에서 @vocab을 사용하고자 한다면, @vocab을 사용하는 순간 "정의되지 않은 용어" 오류 보고가 비활성화되고, 나중의 사용이 앞선 @vocab 선언을 재정의한다는 점을 이해할 것을 강력히 권한다. @vocab 값이 달라지면 문서에 담긴 정보의 의미론이 바뀔 수 있으므로, 이러한 변화가 개발 중인 애플리케이션에 영향을 주는지, 그리고 어떻게 주는지 이해하는 것이 중요하다.

JSON-LD 1.1을 사용하면 리스트, 배열, 심지어 리스트의 리스트까지 가능하다. 리스트와 배열이 필요한 사용 사례에서 RDF 의미론을 원한다면 JSON-LD 1.1의 리스트에 대한 지침을 따를 것을 권한다.

일반적으로 JSON 배열은 순서가 있지만, JSON-LD 배열은 그 배열이 @list 키워드를 사용하지 않는 한 순서가 없다.

참고: 배열 순서가 중요하지 않을 수 있다

타입별 크리덴셜 처리를 수행하여 이 데이터 모델을 사용하는 것이 가능하지만, 그렇게 하면서 배열을 활용하는 사람은 위 지침을 따르지 않는 한 JSON-LD에서 배열 항목의 순서가 보장되지 않는다는 점을 알아야 한다. 이는 예상치 못한 동작으로 이어질 수 있다.

JSON 구조나 순서가 애플리케이션에 중요하다면, 사용 사례에 특화된 @context를 통해 그러한 요소를 @json으로 표시할 것을 권한다. 그러한 선언의 예시를 아래에 보인다.

예시 33: 행렬을 내장 JSON 데이터 구조로 정의하는 @context 파일

{
  "@context":
    {
      "matrix": {
        "@id": "https://website.example/vocabulary#matrix",
        "@type": "@json"
      }
    }
}

아래 예시에서 @context 속성에 https://website.example/matrix/v1 컨텍스트를 포함하여 위에 보인 컨텍스트를 사용하면, credentialSubject.matrix의 값은 자신의 JSON 의미론을 유지한다. 즉 2차원 행렬의 모든 요소의 정확한 순서가 보존된다.

예시 34: 내장 JSON 데이터 구조를 가진 검증가능한 크리덴셜

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://website.example/matrix/v1"
  ],
  "id": "http://university.example/credentials/1872",
  "type": [
    "VerifiableCredential",
    "ExampleMatrixCredential"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "matrix": [
      [1,2,3,4,5,6,7,8,9,10,11,12],
      [1,1,1,1,1,1,1,1,0,0,0,0],
      [0,0,1,1,1,1,1,1,1,0,0,0]
    ]
  }
}

[RFC6838]이 정의하는 미디어 타입은 검증가능한 크리덴셜을 표현하는 데 사용된 구문과 그 밖의 유용한 처리 지침을 식별한다.

이 규격에서 데이터 모델을 표현하는 데 사용되는 구문은 미디어 타입으로 식별되는 것이 좋으며, 검증가능한 크리덴셜과 함께 미디어 타입을 정의하거나 사용할 때 이 절이 제시하는 관례를 따르는 것이 좋다.

핵심 데이터 모델과 연관된 미디어 타입은 두 가지이며, C. IANA 고려사항 절에 나열되어 있다. application/vc와 application/vp이다.

application/vc와 application/vp 미디어 타입은 특정 보안 메커니즘을 함의하지 않으며, 보안 메커니즘과 함께 사용되도록 의도되었다. 이 미디어 타입의 무결성을 보호하려면 보안 메커니즘을 적용해야 한다. 전달에 사용된 미디어 타입이 무엇이든, 콘텐츠가 안전하다고 가정하지 말 것.

This section is non-normative.

때때로 개발자나 시스템이 검증가능한 크리덴셜이나 검증가능한 프레젠테이션을 전달하는 데 정밀도가 낮은 미디어 타입을 사용할 수 있다. 정밀도가 낮은 미디어 타입을 사용하는 이유로는 다음과 같은 것들이 있다.

파일 확장자가 없어 미디어 타입을 판단할 수 없을 때 웹 서버가 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 문서에 VerifiablePresentation 요소를 담은 최상위 type 속성이 있으면 application/vp 미디어 타입으로 가정한다. 그 페이로드가 적합한 검증가능한 프레젠테이션을 표현하는지 확인하기 위해 (이 규격에 따라) 이후 추가 검사를 수행할 것으로 여전히 기대된다.
JSON 문서에 VerifiableCredential 요소를 담은 최상위 type 속성이 있으면 application/vc 미디어 타입으로 가정한다. 그 페이로드가 적합한 검증가능한 크리덴셜을 표현하는지 확인하기 위해 (이 규격에 따라) 이후 추가 검사를 수행할 것으로 여전히 기대된다.

가능한 한 구현자는 이 규격이 정의하는 모든 페이로드에 가장 정밀한(정밀도가 가장 높은) 미디어 타입을 사용할 것을 권한다. 또한 구현자는 정밀도가 낮은 미디어 타입으로 태그된 페이로드라고 해서 그것이 더 정밀한 타입으로 태그하는 데 필요한 규칙을 충족하지 못한다는 뜻은 아님을 인식할 것을 권한다. 마찬가지로 정밀도가 높은 미디어 타입으로 태그된 페이로드라고 해서 그 페이로드가 그 미디어 타입과 연관된 요구사항을 충족하리라는 뜻도 아니다. 페이로드 수신자는 연관된 미디어 타입이 무엇이든, 그 페이로드가 주어진 시스템에서의 사용에 필요한 요구사항에 부합하는지 확인하기 위해 적절한 검사를 수행할 것으로 기대된다.

HTTP 클라이언트와 서버는 accept 헤더와 콘텐츠 타입을 나타낼 때 검증가능한 크리덴셜과 검증가능한 프레젠테이션에 연관된 미디어 타입을 사용한다. 구현자는 HTTP 서버가 accept 헤더를 무시하고 다른 콘텐츠 타입을 반환하거나, 415 Unsupported Media Type과 같은 오류 코드를 반환할 수 있다는 점에 주의해야 한다.

This section is non-normative.

JSON은 여러 종류의 정보를 표현하는 데 사용될 수 있으므로, 특정 JSON 문서의 소비자는 그 문서를 맥락에 놓고 다른 가능한 표현과 구별해 주는 정보를 가지고 있을 때에만 작성자의 의도를 제대로 해석할 수 있다. 이 해석을 돕는 정보는 JSON 문서 완전히 바깥에 있을 수도 있고 문서 안에서 링크될 수도 있다. 축약된 JSON-LD 문서에는 클레임을 표현하기 위한 맥락 정보를 내부적으로 표현하거나 그것으로 링크하는 @context 속성이 포함된다. 이러한 기능 덕분에 JSON-LD 문서를 한 컨텍스트에서 다른 컨텍스트로 변환하는 일반화된 프로세서를 작성할 수 있지만, 소비자가 이미 자신이 기대하는 컨텍스트와 형태를 사용하는 JSON-LD 문서를 받는 경우에는 이것이 필요하지 않다. 검증가능한 크리덴셜의 발급자와 같은 JSON-LD 문서의 작성자는 상호 운용성을 촉진하기 위해 적절한 JSON-LD 컨텍스트를 제공하고 이 규칙들을 따라야 한다.

아래 내용은 소비자가 JSON-LD 문서의 내용을 소비하기 위해 그것을 변환할 필요가 없도록, 그 문서가 자신의 애플리케이션이 이미 이해하는 컨텍스트와 형태로 표현되게 하는 방법을 이해하는 데 도움을 준다. 특히 이는 소비자가 어떤 컨텍스트도 이해할 필요가 없다는 뜻이 아니다. 오히려 소비하는 애플리케이션은 함께 작업할, 선택된 컨텍스트와 문서 형태의 집합만 이해하면 되고 다른 것들은 이해하지 않아도 된다는 뜻이다. 발급자는 다른 JSON 형식 데이터에 대해서도 그렇게 할 수 있는 것과 마찬가지로, 일반화된 프로세서를 사용하지 않는 소비자를 돕기 위해 컨텍스트와 자신의 검증가능한 크리덴셜에 대한 정보를 게시할 수 있다.

일반 JSON-LD 처리는 JSON-LD 소프트웨어 라이브러리를 사용하여 여러 변환을 수행함으로써 적합 문서를 처리하는 메커니즘으로 정의된다. 타입별 크리덴셜 처리는 JSON-LD 소프트웨어 라이브러리를 요구하지 않는, 적합 문서 처리를 위한 더 가벼운 메커니즘으로 정의된다. 검증가능한 크리덴셜의 일부 소비자는 특정 타입의 크리덴셜만 소비하면 된다. 이러한 소비자는 일반화된 처리 대신 타입별 크리덴셜 처리를 사용할 수 있다. 타입별 크리덴셜 처리가 바람직할 수 있는 시나리오에는 다음이 포함되나 이에 국한되지 않는다.

적합 문서에 보안 메커니즘을 적용하기 전이나, 보안 메커니즘으로 보호된 적합 문서를 검증한 후 데이터 무결성을 보장하기 위할 때.
4.11 데이터 스키마 절에서 설명하는 대로 JSON Schema 유효성 검사를 수행할 때.
검증가능한 크리덴셜이나 검증가능한 프레젠테이션의 내용을 저장하거나 색인하는 시스템으로 직렬화하거나 역직렬화할 때.
일반 JSON-LD 처리를 요구하는 보안 메커니즘에 대해 검증이나 유효성 검사를 수행한 후, 소프트웨어 애플리케이션에서 검증가능한 크리덴셜이나 검증가능한 프레젠테이션을 다룰 때.
애플리케이션이 +json 구조화 미디어 타입 접미사를 사용하여 미디어 타입을 처리하기로 선택할 때.

즉 소비되거나 생성되는 문서가 적합 문서이기만 하면 타입별 크리덴셜 처리가 허용된다.

타입별 크리덴셜 처리를 원한다면, 구현자는 다음 규칙을 따를 것을 권한다.

@context 속성과 연관된 모든 값이 기대되는 순서로 있는지, 컨텍스트 파일의 내용이 각 파일에 대해 알려진 정상 암호학적 해시와 일치하는지, 그리고 그 내용이 의도한 사용 사례에 적절하다고 해당 분야 전문가가 판단했는지 확인한다.

JSON Schema와 함께 정적 컨텍스트 파일을 사용하는 것은 위 규칙을 구현하는 한 가지 허용 가능한 접근법이다. 이는 타입별 크리덴셜 처리를 수행할 때 올바른 용어 식별, 타입 지정, 순서를 보장할 수 있다.

위 규칙은 @context 메커니즘을 통해 리터럴 JSON 키를 URI에 대응시키는 두 처리 메커니즘 사이의 의미론적 상호 운용성을 보장한다. 일반 JSON-LD 처리는 모든 용어가 올바르게 명시되었는지 검증하기 위해 자신의 알고리즘에 제공된, 이전에 본 적 없는 @context 값을 사용할 수 있는 반면, 타입별 크리덴셜 처리를 수행하는 구현은 그 구현이 미리 이해하도록 만들어진 특정 @context 값만 받아들이며, 그 결과 JSON-LD API를 전혀 호출하지 않고도 동일한 의미론을 얻는다. 다시 말해 데이터 교환이 일어나는 컨텍스트는 동일한 적합 문서 의미론으로 이어지는 방식으로 @context를 사용함으로써, 두 처리 메커니즘 모두에 대해 명시적으로 진술된다.

이 절에는 구현이 검증과 같은 일반적인 연산을 수행하는 데 사용할 수 있는 알고리즘이 담겨 있다. 알고리즘으로 표현된 적합성 요구사항은 Infra Standard [INFRA]의 규범적 개념을 사용한다. 구현 요구사항에 대한 자세한 지침은 Infra Standard의 Algorithm Conformance 절을 참조한다.

참고: 구현자는 추가 검사, 경고, 오류를 포함할 수 있다.

구현자는 이 절의 알고리즘이 이 규격에 대한 적합성을 시험하기 위해 구현이 사용하는 최소한의 검사 집합만을 담고 있다는 점에 유의해야 한다. 구현은 개발자가 잠재적 문제를 디버깅하는 데 도움이 되는 유용한 경고를 보고하는 추가 검사를 제공할 것으로 기대된다. 마찬가지로 구현은 해로운 콘텐츠를 막기 위해 새로운 유형의 오류 보고로 이어질 수 있는 추가 검사를 제공할 가능성이 크다. 이러한 추가 검사 중 어느 것이든 이 규격의 향후 버전에 통합될 수 있다.

이 절에는 적합 검증자 구현이 검증가능한 크리덴셜이나 검증가능한 프레젠테이션을 검증할 때 실행해야 하는 알고리즘이 담겨 있다. 이 알고리즘은 미디어 타입(문자열 inputMediaType)과 보호된 데이터(바이트 시퀀스 inputData)를 받아 다음을 담은 맵을 반환한다.

상태(불리언 status)
적합 문서(맵 document)
미디어 타입(문자열 mediaType)
보안 메커니즘과 연관된 검증 방법의 제어자(문자열 controller)
보안 메커니즘을 검증하는 데 사용된 검증 방법과 연관된 제어 식별자 문서(맵 controlledIdentifierDocument)
0개 이상의 경고(ProblemDetails의 리스트 warnings)
0개 이상의 오류(ProblemDetails의 리스트 errors)

검증 알고리즘은 다음과 같다.

다음 단계를 수행하여 보안 메커니즘이 적합 문서를 제대로 보호했는지 확인한다.
1. inputMediaType과 Verifiable Credential Extensions 문서의 Securing Mechanisms 절, 또는 그 구현에 알려진 다른 메커니즘을 사용하여 보안 메커니즘을 검증할 때 사용할 암호 스위트를 결정함으로써 verifyProof 함수를 설정한다. verifyProof 함수는 5.13 보안 메커니즘 규격에서 기술하는 인터페이스를 구현해야 한다.
2. verifyProof 함수가 바이트 시퀀스를 기대하면 inputMediaType과 inputData를 알고리즘에 제공한다. verifyProof 함수가 맵을 기대하면 inputMediaType과, inputData에 대해 JSON 바이트를 Infra 값으로 파싱한 결과를 제공한다. result를 verifyProof 함수 호출의 결과로 설정한다. 호출이 성공했다면 result에는 status, document, mediaType, controller, controlledIdentifierDocument, warnings, errors 속성이 담긴다.
3. result.status가 false로 설정되어 있으면 result.errors에 CRYPTOGRAPHIC_SECURITY_ERROR를 추가한다.
result.status가 true로 설정되어 있으면 result.document가 적합 문서인지 확인한다. 그렇지 않으면 result.status를 false로 설정하고, result에서 document 속성을 제거하며, result.errors에 최소한 하나의 MALFORMED_VALUE_ERROR를 추가한다. 디버깅 과정을 돕기 위해 다른 경고와 오류를 포함할 수 있다.
result를 반환한다.

보안 메커니즘의 상태를 검증하는 단계와 입력 문서가 적합 문서인지 검증하는 단계는, 구현이 동일한 유효하지 않은 입력에 대해 오류를 반환하기만 한다면 위에 제시된 것과 다른 순서로 수행할 수 있다. 구현은 위에 기술된 것과 다른 오류를 발생시킬 수 있다.

구현이 문서를 처리하는 중 이상을 감지했을 때, ProblemDetails 객체를 사용하여 그 문제를 다른 소프트웨어 시스템에 보고할 수 있다. 이 객체들의 인터페이스는 데이터를 인코딩하기 위해 [RFC9457]을 따른다. ProblemDetails 객체는 다음 속성으로 구성된다.

type: type 속성은 존재해야 하며, 그 값은 문제의 유형을 식별하는 URL이어야 한다.
title: title 속성은 그 문제에 대해 짧지만 구체적인, 사람이 읽을 수 있는 문자열을 제공하는 것이 좋다.
detail: detail 속성은 그 문제에 대해 더 긴, 사람이 읽을 수 있는 문자열을 제공하는 것이 좋다.

이 규격은 다음 문제 기술 유형을 정의한다.

https://www.w3.org/TR/vc-data-model#PARSING_ERROR: 입력을 파싱하는 중 오류가 있었다.
https://www.w3.org/TR/vc-data-model#CRYPTOGRAPHIC_SECURITY_ERROR: 그 문서의 보안 메커니즘이 문서가 생성된 이후 문서 내용의 수정을 감지했다. 잠재적 변조가 감지되었다. 7.1 검증 절을 참조한다.
https://www.w3.org/TR/vc-data-model#MALFORMED_VALUE_ERROR: 특정 속성과 연관된 값의 형식이 잘못되었다. 그 속성의 이름과 그 속성으로의 경로를 ProblemDetails 객체에 제공하는 것이 좋다. 7.1 검증 절을 참조한다.
https://www.w3.org/TR/vc-data-model#RANGE_ERROR: 배열에 주어진 인덱스 값이 그 배열의 현재 크기보다 큰 경우처럼, 제공된 값이 연관된 값의 기대 범위를 벗어났다.

구현은 추가 유형이나 속성을 명시하여 ProblemDetails 객체를 확장할 수 있다. 이 메커니즘 사용에 대한 자세한 지침은 [RFC9457]의 Extension Member 절을 참조한다.

This section is non-normative.

이 절은 검증가능한 크리덴셜 데이터 모델을 운영 환경에 배포할 때의 일반적인 프라이버시 고려사항과 구체적인 프라이버시 함의를 상세히 다룬다.

This section is non-normative.

가명에서 강하게 식별되는 상태에 이르는 프라이버시의 스펙트럼이 존재한다는 점을 인식하는 것이 중요하다. 사용 사례에 따라 사람들은 자신이 기꺼이 제공하려는 정보와 그로부터 파생될 수 있는 정보에 대해 서로 다른 수준의 편안함을 느낀다.

왼쪽은 빨강, 가운데는
주황, 오른쪽은 초록인 가로 막대. 빨강에는 '상관관계를
짓기 매우 쉬움(전역 ID). 예: 정부 발급 신분증, 배송
주소, 신용카드 번호'라는 텍스트가 있다. 주황에는
'결탁을 통해 상관관계를 지을 수 있음(개인 식별
정보). 예: 이름, 생일, 우편번호'라는 텍스트가 있다.
초록에는 '상관관계를 지을 수 없음(가명). 예: 21세
이상'이라는 텍스트가 있다. — Figure 13 가명에서 완전히 식별되는 상태에 이르는 프라이버시 스펙트럼.

프라이버시 해법은 사용 사례마다 다르다. 예를 들어 주류를 구매할 때 규제는 구매자가 특정 연령 이상인지만 확인하도록 하므로, 많은 사람이 익명으로 남기를 선호할 것이다. 반면 의료 전문가가 환자에게 써 준 처방전을 조제할 때, 약국은 처방자와 환자 모두를 더 강하게 식별하도록 법적으로 요구받는다. 모든 사용 사례에 통하는 단일한 프라이버시 접근법은 없다.

참고: 어떤 사용 사례에서는 연령 증명만으로 충분하지 않을 수 있다

주류를 구매할 때 익명으로 남고 싶은 사람이라도 판매자에게 적절한 확신을 주기 위해 사진이 있는 신분증을 제시해야 할 수 있다. 판매자는 당신이 특정 연령 이상이라는 것 외에 이름이나 다른 세부 사항을 알 필요가 없을 수 있지만, 많은 경우 단순한 연령 증명만으로는 규제를 충족하기에 충분하지 않을 수 있다.

검증가능한 크리덴셜 데이터 모델은 프라이버시 스펙트럼 전체를 지원하고자 하며, 특정 거래에 적절한 익명성 수준에 대해 철학적 입장을 취하지 않는다. 다음 절들은 프라이버시에 적대적인 특정 시나리오를 피하고자 하는 구현자에게 지침을 제공한다.

This section is non-normative.

이 규격이 기술하는 생태계에는 다양한 신뢰 관계가 존재한다. 웹 브라우저를 사용하는 개인은 사용자 에이전트라고도 하는 그 웹 브라우저가 자신의 개인 정보를 데이터 브로커에게 업로드하지 않음으로써 그 신뢰를 지켜주리라 신뢰한다. 마찬가지로 이 규격이 기술하는 생태계에서 역할을 맡은 엔티티들은 각 역할을 대신하여 동작하는 소프트웨어를 신뢰한다. 예를 들면 다음과 같다.

온라인 교육 플랫폼과 같은 발급자의 사용자 에이전트(발급자 소프트웨어)는 발급자가 자신의 교육 과정을 이수했다고 주장하는 개인에게만 검증가능한 크리덴셜을 발급할 것으로 기대된다.
채용 웹사이트와 같은 검증자의 사용자 에이전트(검증 소프트웨어)는 그러한 개인이 플랫폼에 제공한 검증가능한 크리덴셜과 검증가능한 프레젠테이션에 대해 유효한 검증 상태를 가진 개인에게만 접근을 허용할 것으로 기대된다.
디지털 지갑과 같은 보유자의 사용자 에이전트(보유자 소프트웨어)는 보유자가 그 정보의 공개에 동의할 때에만 검증자에게 정보를 내놓을 것으로 기대된다.

위 예시는 전부가 아니며, 이 역할을 맡은 사용자들은 자신의 목표를 달성하기 위해 사용하는 소프트웨어에 다른 여러 가지도 기대할 수 있다. 요컨대 사용자는 소프트웨어가 자신의 최선의 이익을 위해 동작하기를 기대한다. 이 기대를 저버리는 것은 신뢰를 깨뜨리며 더 믿을 만한 대안으로 그 소프트웨어가 교체되는 결과로 이어질 수 있다. 구현자는 사용자 신뢰를 지키는 소프트웨어를 만들 것을 강력히 권한다. 또한 사용자나 신뢰할 수 있는 제3자가 그 소프트웨어가 자신들의 최선의 이익에 부합하게 동작하는지 검증할 수 있게 하는 감사 기능을 포함할 것을 권한다.

독자는 단일 검증자와 여러 보유자에게 서비스를 제공하는 웹사이트처럼, 일부 소프트웨어는 두 역할 모두에 대해 사용자 에이전트로 동작할 수 있지만 항상 모든 당사자의 최선의 이익을 위해 동시에 동작할 수는 없을 수 있다는 점에 유의해야 한다. 예를 들어 어떤 웹사이트가 여러 보유자 사이에서 검증가능한 크리덴셜의 부정 사용 시도를 감지했다고 하자. 그 경우 그 웹사이트는 그러한 이상을 검증자에게 보고할 수 있는데, 이는 모든 보유자의 최선의 이익에 부합하지 않는다고 여겨질 수 있지만, 검증자와 그러한 위반을 저지르지 않은 보유자에게는 최선의 이익이 된다. 소프트웨어가 이런 방식으로 동작할 때는, 웹사이트 이용 정책과 같은 메커니즘을 통해 그 소프트웨어가 누구의 최선의 이익을 위해 동작하는지 분명히 밝히는 것이 필수적이다.

This section is non-normative.

credential.credentialSubject 속성에 저장된, 검증가능한 크리덴셜과 연관된 데이터는 검증자와 공유될 때 프라이버시 침해에 취약하다. 정부 발급 식별자, 배송 주소, 성명과 같은 개인 식별 데이터는 엔티티를 특정하고, 추적하고, 상관관계를 짓는 데 쉽게 사용될 수 있다. 생년월일과 우편번호의 조합처럼 개인을 식별할 수 없어 보이는 정보조차 강력한 상관관계 및 익명 해제 능력을 가진다.

보유자가 사용하는 소프트웨어의 구현자는 보유자가 이러한 특성을 가진 데이터를 공유할 때 경고할 것을 강력히 권한다. 발급자는 가능한 한 프라이버시를 보호하는 검증가능한 크리덴셜을 제공할 것을 강력히 권한다. 예를 들어 검증자가 어떤 엔티티가 18세 이상인지 판단하고자 할 때 쓰도록 dateOfBirth 검증가능한 크리덴셜 대신 ageOver 검증가능한 크리덴셜을 발급하는 식이다.

검증가능한 크리덴셜에는 개인 식별 정보(PII)가 담기는 경우가 많으므로, 구현자는 검증가능한 크리덴셜을 저장하고 전송할 때 접근 권한이 없어야 할 사람들로부터 그 데이터를 보호하는 메커니즘을 사용할 것을 강력히 권한다. 고려할 수 있는 메커니즘으로는 전송 중 데이터를 암호화하는 전송 계층 보안(TLS)이나 그 밖의 수단, 그리고 저장 중인 검증가능한 크리덴셜의 데이터를 보호하는 암호화나 접근 제어 메커니즘이 있다.

일반적으로 개인은 검증가능한 크리덴셜이 대부분의 물리적 크리덴셜과 마찬가지로 공유될 때 개인 식별 정보를 흘릴 것이라고 가정할 것을 권한다. 그러한 유출에 대응하려면 검증가능한 크리덴셜과 그 보안 메커니즘이 상관관계를 방지하도록 신중히 설계되어야 한다. 개인 식별 정보의 유출을 막도록 특별히 설계된 검증가능한 크리덴셜이 존재한다. 개인과 구현자는 개인 식별 정보를 보호하도록 설계되지 않은 크리덴셜 타입보다 이러한 크리덴셜 타입을 선택할 것을 권한다.

This section is non-normative.

검증가능한 크리덴셜에는 개인의 상관관계를 짓는 데 사용될 수 있는 오래 지속되는 식별자가 담길 수 있다. 이러한 식별자에는 주체 식별자, 이메일 주소, 정부 발급 식별자, 조직 발급 식별자, 주소, 건강 지표, 그 밖의 오래 지속되는 여러 식별자가 포함된다. 보유자용 소프트웨어의 구현자는 검증가능한 크리덴셜에서 개인의 상관관계를 짓는 데 사용될 수 있는 식별자를 감지하고, 보유자가 이 정보를 공유하기 전에 경고할 것을 권한다. 이 절의 나머지는 오래 지속되는 식별자 사용과 관련된 지침을 자세히 다룬다.

검증가능한 크리덴셜의 주체는 4.4 식별자 절에서 정의하고 credentialSubject.id 속성 같은 곳에서 사용되는 id 속성으로 식별된다. 주체를 식별하는 데 사용되는 식별자는 그것이 오래 지속되거나 둘 이상의 웹 도메인에 걸쳐 사용될 때 더 큰 상관관계 위험을 만든다. 이 범주에 속하는 다른 유형의 식별자로는 이메일 주소, 정부 발급 식별자, 조직 발급 식별자가 있다.

마찬가지로 (예시 3에서처럼) 크리덴셜 식별자를 공개하면 여러 검증자, 또는 발급자와 검증자가 결탁하여 보유자의 상관관계를 지을 수 있는 상황으로 이어질 수 있다.

상관관계를 줄이고자 하는 보유자는 검증가능한 프레젠테이션에서 상관관계를 짓는 식별자를 선택적으로 공개하는 것을 지원하는 발급자의 검증가능한 크리덴셜을 사용할 것을 권한다. 그러한 접근법은 보유자가 식별자를 생성할 것으로 기대하며, 블라인드 서명과 같은 기법을 통해 식별자를 검증가능한 크리덴셜에 내장하고 서명한 상태로 유지하면서도 발급자에게는 숨기는 것을 허용할 수도 있다.

보안 메커니즘 규격 작성자는 선택적으로 공개할 수 없는, 상관관계를 짓는 식별자의 사용을 피하도록 자신의 기술을 설계함으로써 식별자 기반 상관관계가 가능해지지 않게 할 것을 권한다.

검증가능한 크리덴셜 시스템에 강력한 상관관계 방지 속성이 요구된다면, 식별자가 다음 기준 중 하나 이상을 충족하는 것이 필수적이다.

선택적으로 공개 가능할 것
단일 오리진에 결속될 것
일회용일 것
사용하지 않고 대신 수명이 짧은 일회용 무기명 토큰으로 대체할 것

This section is non-normative.

검증가능한 크리덴셜의 내용은 보안 메커니즘으로 보호된다. 보안 메커니즘을 나타내는 값은 여러 세션이나 도메인에 걸쳐 동일하게 유지될 때 더 큰 상관관계 위험을 초래한다. 그러한 값의 예로는 다음이 있다.

디지털 서명의 이진 값
디지털 서명 생성과 연관된 타임스탬프 정보
공개키 식별자와 같이 디지털 서명과 연관된 암호학적 자료

강력한 상관관계 방지 속성이 요구될 때, 발급자는 각 검증가능한 프레젠테이션마다 서명 값과 메타데이터를 다시 생성할 수 있는 검증가능한 크리덴셜을 만들 것을 권한다. 이는 Data Integrity BBS Cryptosuites v1.0 규격처럼 연결 불가능한 공개를 지원하는 기술을 사용하여 달성할 수 있다. 가능한 경우 검증자는 보유자와 주체의 프라이버시를 강화하기 위해 이 기술을 사용하는 검증가능한 프레젠테이션을 선호할 것을 권한다.

참고: 연결 불가능성이 완전한 해법은 아니다

연결 불가능한 서명을 쓰더라도 검증가능한 크리덴셜에는 사용된 암호 기술의 상관관계 방지 속성을 훼손하는 다른 정보가 담겨 있을 수 있다. 8.3 개인 식별 정보, 8.4 식별자 기반 상관관계, 8.6 메타데이터 기반 상관관계, 8.11 유효성 검사 중 상관관계 절과 8. 프라이버시 고려사항 절의 다른 대부분의 하위 절을 참조한다.

This section is non-normative.

4. 기본 개념 절과 5. 고급 개념 절에서 기술한 것과 같은 여러 확장점은, 상대적으로 소수의 발급자만이 특정 확장 타입이나 타입 조합을 사용하는 경우 의도치 않게 또는 바람직하지 않게 상관관계 메커니즘으로 작용할 수 있다. 예를 들어 특정 국가에 고유한 암호 방식, 특정 관할권에 특화된 폐기 형식, 특정 지역에서 채택한 크리덴셜 타입을 사용하는 것은, 보유자가 검증자에게 정보를 선택적으로 공개할 때 기대하는 가명성을 떨어뜨리는 메커니즘으로 작용할 수 있다.

발급자는 가명 사용을 의도한 검증가능한 크리덴셜을 발급할 때 보유자의 가명성을 떨어뜨릴 수 있는 확장의 종류를 제한함으로써 메타데이터 기반 상관관계 위험을 최소화할 것을 권한다. 전 세계적으로 채택된 크리덴셜 타입, 확장, 기술 프로파일이 가장 바람직하고, 그다음이 국가 단위로 쓰이는 것이며, 지역에서만 쓰이는 것이 가장 덜 바람직하다.

This section is non-normative.

검증가능한 크리덴셜 바깥에도 인터넷과 웹에서 개인을 추적하고 상관관계를 짓는 메커니즘이 있다. 이러한 메커니즘에는 인터넷 프로토콜(IP) 주소 추적, 웹 브라우저 핑거프린팅, 에버쿠키, 광고 네트워크 트래커, 모바일 네트워크 위치 정보, 애플리케이션 내 위성 위치 확인 시스템(GPS) API가 포함된다. 검증가능한 크리덴셜을 사용한다고 해서 이러한 다른 추적 기술의 사용을 막을 수는 없다. 오히려 이러한 기술을 검증가능한 크리덴셜과 함께 사용하면 상관관계를 지을 수 있는 새로운 정보가 드러날 수 있다. 예를 들어 생년월일이 GPS 위치와 결합되면 여러 웹사이트에 걸쳐 개인의 상관관계를 강하게 지을 수 있다.

프라이버시를 존중하는 시스템은 다른 추적 기술이 검증가능한 크리덴셜과 결합되는 것을 막는 것을 목표로 삼아야 한다. 어떤 경우에는 보유자를 대신하여 검증가능한 크리덴셜을 전송하는 기기에서 추적 기술을 비활성화해야 할 수도 있다.

Oblivious HTTP 프로토콜 [RFC9458]은 검증가능한 크리덴셜이나 검증가능한 프레젠테이션과 연관된 외부 자원을 가져올 때 구현자가 사용을 고려할 수 있는 한 가지 메커니즘이다. Oblivious HTTP는 메시지를 전달하는 데 사용되는 노드에 제한된 신뢰만 두면서, 클라이언트가 오리진 서버에 여러 번 요청하되 그 서버가 그 요청들을 해당 클라이언트와 연결하거나 그 요청들이 단일 클라이언트에서 왔다고 식별조차 할 수 없게 한다. Oblivious HTTP는 기기 추적과 핑거프린팅의 가능성을 줄일 수 있는 프라이버시 보호 메커니즘 중 하나다. 아래는 Oblivious HTTP가 생태계 참여자에게 이로울 수 있는 방식의 구체적인 예시다.

디지털 지갑을 사용하는 보유자는 자신의 디지털 지갑에 저장된 검증가능한 크리덴셜 안의 외부 링크에 접근할 때 제3자에게 추적당할 가능성을 줄일 수 있다. 예를 들어 디지털 지갑은 링크된 이미지를 가져와 렌더링하거나, 외부에 링크된 폐기 목록을 가져와 검증가능한 크리덴셜의 유효성을 확인할 수 있다.
검증자는 그 검증자가 특정 검증가능한 크리덴셜을 받았다는 사실을 발급자에게 알리게 될 가능성을 줄일 수 있다. 예를 들어 검증자는 검증가능한 크리덴셜에 대해 상태 확인을 수행하면서 외부에 링크된 폐기 목록을 가져올 수 있다.

This section is non-normative.

발급자는 수신자가 필요 이상의 개인 식별 정보(PII)를 공개하지 않고도 여러 상황에서 사용할 수 있도록, 검증가능한 크리덴셜에 포함되는 정보를 의도한 목적에 필요한 최소한의 집합으로 제한할 것을 권한다. 검증가능한 크리덴셜에 PII를 넣지 않는 한 가지 방법은, 주체에 대해 지나치게 구체적인 정보를 제공하지 않으면서 검증자의 필요를 충족하는 추상적인 속성을 사용하는 것이다.

예를 들어 이 문서는 더 민감한 PII가 될 구체적인 생년월일 대신 ageOver 속성을 사용한다. 특정 시장의 소매업체가 통상 구매자에게 일정 연령 이상일 것을 요구한다면, 그 시장에서 신뢰받는 발급자는 고객의 생일에 대한 클레임이 담긴 검증가능한 크리덴셜을 제공하기보다, 주체가 그 요건을 충족했다고 주장하는 검증가능한 크리덴셜을 제공하기로 선택할 수 있다. 이러한 관행은 개별 고객이 필요 이상의 PII를 공개하지 않고도 구매할 수 있게 해 준다.

This section is non-normative.

프라이버시 침해는 한 맥락에서 내놓은 정보가 다른 맥락으로 새어나갈 때 발생한다. 그러한 침해를 막기 위해 널리 받아들여지는 모범 사례 하나는, 검증자가 요청하고 수신하는 정보를 특정 거래에 필요한 절대 최소한으로 제한하는 것이다. 미국의 건강보험 이동성 및 책임에 관한 법률(HIPAA)과 유럽연합의 일반 개인정보 보호법(GDPR)을 포함하여 여러 관할권의 규제가 이 데이터 최소화 접근법을 의무화하고 있다.

검증가능한 크리덴셜에서 발급자의 데이터 최소화란, 예상되는 용도에 대해 잠재적 검증자가 요구하는 최소한으로 검증가능한 크리덴셜의 내용을 제한하는 것을 뜻한다. 검증자에게 데이터 최소화란 서비스 접근을 위해 요청하거나 요구하는 정보의 범위를 제한하는 것을 뜻한다.

예를 들어 운전자 ID 번호, 키, 몸무게, 생일, 자택 주소가 담긴 운전면허증을 검증가능한 크리덴셜로 표현한 것은, 그 사람이 일정 연령 이상임을 확립하는 데 필요한 것보다 많은 정보를 담고 있다.

발급자가 정보를 원자화하거나 선택적 공개를 허용하는 보안 메커니즘을 사용하는 것이 모범 사례로 여겨진다. 예를 들어 운전면허증의 발급자는 운전면허증에 나오는 모든 속성을 담은 검증가능한 크리덴셜을 발급하고, 보유자가 각 속성을 선택적으로 공개하도록 할 수 있다. 또는 더 추상적인 검증가능한 크리덴셜(예: ageOver 속성만 담은 검증가능한 크리덴셜)을 발급할 수도 있다. 한 가지 가능한 방안은 발급자가 검증가능한 크리덴셜의 가명 사용을 촉진하는 일회용 무기명 크리덴셜을 가져올 수 있는 보안 HTTP 엔드포인트를 제공하는 것이다. 이것이 비현실적이거나 안전하지 않다고 보는 구현자는, 증명 시점에 발급자에 대한 의존을 없애고 발급자에 의한 시간적 상관관계의 위험을 줄이는 선택적 공개 방식을 고려할 수 있다.

검증자는 특정 거래가 이루어지는 데 엄격히 필요한 정보만 요청할 것을 강력히 권한다. 이는 최소한 두 가지 이유에서 중요하다.

다룰 필요가 없는 매우 민감한 정보를 다루는 데 따르는 검증자의 책임을 줄여준다.
특정 거래에 필요한 정보만 요구함으로써 주체나 보유자의 프라이버시를 강화한다.

보유자가 사용하는 소프트웨어의 구현자는 검증자가 요청하는 정보를 알려주어 보유자가 그 거래에 불필요한 특정 정보의 공유를 거부할 수 있게 할 것을 권한다. 또한 보유자가 사용하는 소프트웨어의 구현자는 보유자에게 검증자와 공유한 정보의 로그에 대한 접근을 제공할 것을 권한다. 이는 보유자가 자신이 정보 과다 요구를 당했거나 특정 거래에 필요한 것보다 많은 정보를 공유하도록 강요당했다고 여길 때 그 정보를 당국에 제공할 수 있게 해 준다.

참고: 최소한의 공개로도 고유 식별에 이를 수 있다

최소 공개의 원칙을 실천하는 것이 가능하기는 하지만, 특정 사용 사례에서는 단일 세션 중이나 여러 세션에 걸쳐 개인이 강하게 식별되는 것을 피하기가 불가능할 수 있다. 이 문서의 저자들은 현실 세계의 시나리오에서 이 원칙을 충족하기가 얼마나 어려운지 아무리 강조해도 지나치지 않다고 본다.

This section is non-normative.

검증가능한 크리덴셜을 처리할 때 검증자는 관련 클레임을 신뢰하기 전에 그것을 평가한다. 이 평가는 유효성 검사를 수행하는 검증자의 요구사항을 충족하기만 하면 원하는 어떤 방식으로든 이루어질 수 있다. 많은 검증자는 부록 A. 유효성 검사에 나열된 검사와 더불어 다음과 같은 다양한 구체적 업무 절차 검사를 수행할 것이다.

보유자의 전문 면허 상태.
면허 갱신 또는 취소 일자.
개인의 하위 자격.
보유자와, 그 보유자가 상호작용하려는 엔티티 사이에 관계가 존재하는지 여부.
보유자와 연관된 지리적 위치 정보.

이러한 검사를 수행하는 과정에서 정보가 새어나가 보유자의 프라이버시 침해로 이어질 수 있다. 예를 들어 잘못 구성된 폐기 목록을 확인하는 것과 같은 단순한 연산이, 특정 사업체가 그 보유자와 상호작용하고 있을 가능성이 크다는 사실을 발급자에게 알릴 수 있다. 이는 발급자들이 결탁하여 개인이 알지 못하는 사이에 그들의 상관관계를 짓게 할 수 있다.

발급자는 검증 과정에서 크리덴셜마다 고유한 크리덴셜 폐기 목록처럼 프라이버시 침해로 이어질 수 있는 메커니즘을 사용하지 않을 것을 강력히 권한다. 보유자에게 소프트웨어를 제공하는 조직은 크리덴셜에 검증 과정에서 프라이버시 침해로 이어질 수 있는 정보가 포함되어 있으면 경고해야 한다. 검증자는 프라이버시 침해를 낳거나 수준 미달의 프라이버시 관행을 가능하게 하는 크리덴셜을 거부하는 것을 고려할 것을 강력히 권한다.

This section is non-normative.

보유자가 발급자로부터 검증가능한 크리덴셜을 받으면, 그 검증가능한 크리덴셜을 어딘가에(예: 크리덴셜 리포지토리) 저장해야 한다. 보유자는 검증가능한 크리덴셜의 정보가 민감하고 고도로 개인화되어 있어 데이터 마이닝의 주요 표적이 된다는 점을 알아야 한다. 검증가능한 크리덴셜을 "무료로" 저장해 준다는 서비스는 개인 데이터를 마이닝하여, 사람과 조직에 대한 개인화된 프로파일을 구축하는 데 관심 있는 조직에 팔 수 있다.

보유자는 자신의 크리덴셜 리포지토리의 서비스 약관, 특히 그 서비스 제공자에게 검증가능한 크리덴셜을 저장하는 사람들을 위해 마련된 상관관계 및 데이터 마이닝 보호 조치를 알아야 한다.

데이터 마이닝과 프로파일링에 대한 효과적인 완화책으로는 다음을 사용하는 것이 있다.

당신의 정보를 제3자에게 팔지 않는 서비스 제공자.
서비스 제공자가 크리덴셜의 내용을 볼 수 없도록 검증가능한 크리덴셜을 암호화하는 소프트웨어.
검증가능한 크리덴셜을 당신이 통제하는 기기에 로컬로 저장하며, 당신의 예상을 넘어 정보를 업로드하거나 분석하지 않는 소프트웨어.

위 완화책에 더하여, 벤더 분석과 감사에 시민 사회와 규제 기관이 참여하면, 자신의 최선의 이익에 부합하지 않는 관행에 영향을 받는 개인을 위해 법적 보호가 제정되고 집행되도록 하는 데 도움이 될 수 있다.

This section is non-normative.

동일한 주체에 대한 두 가지 정보를 갖는 것은, 그 조각들이 서로 다른 경로로 전달되었더라도, 그 둘을 단순히 합한 것보다 그 주체에 대해 더 많은 것을 드러내는 경우가 많다. 검증가능한 크리덴셜을 모으는 것은 프라이버시 위험을 초래하며, 생태계의 모든 참여자는 데이터 집합의 위험을 알아야 한다.

예를 들어 이메일 주소에 대한 것 하나와 보유자가 21세 이상임을 진술하는 것 하나, 이렇게 두 무기명 크리덴셜이 여러 세션에 걸쳐 동일한 검증자에게 제공된다고 하자. 이제 그 정보의 검증자는 그 개인에 대해 고유 식별자(이메일 주소)와 함께 연령 관련("21세 이상") 정보를 갖게 된다. 이제 그 보유자의 프로파일을 만들고, 시간이 지나며 정보가 새어나오는 대로 계속 덧붙여 키워가기 쉬워진다. 그러한 크리덴셜의 집합은 여러 사이트가 서로 결탁하여 수행할 수도 있으며, 이는 프라이버시 침해로 이어진다.

기술적 관점에서 정보 집합을 막는 것은 까다로운 프라이버시 문제다. 영지식 증명과 같은 새로운 암호 기법이 집합 및 상관관계 문제의 해법으로 제안되고 있지만, 오래 지속되는 식별자와 브라우저 추적 기법의 존재는 가장 현대적인 암호 기법조차 무력화한다.

상관관계나 집합이 갖는 프라이버시 함의에 대한 해법은 대개 기술적인 것이 아니라 정책에 의한 것이다. 따라서 보유자가 자신의 정보가 모이는 것을 피하고자 한다면, 자신이 전송하는 검증가능한 프레젠테이션에, 그리고 자신이 검증가능한 프레젠테이션을 전송하는 보유자와 검증자를 통해 이를 표현해야 한다.

This section is non-normative.

관련된 모두가 프라이버시를 보장하려 최선을 다하더라도, 검증가능한 크리덴셜을 사용하는 것은 익명 해제와 프라이버시 상실로 이어질 가능성이 있다. 이러한 상관관계는 다음 중 어느 하나가 일어날 때 발생할 수 있다.

동일한 검증가능한 크리덴셜이 동일한 검증자에게 두 번 이상 제시된다. 그 검증자는 그 보유자가 동일한 개인이라고 추론할 수 있다.
동일한 검증가능한 크리덴셜이 서로 다른 검증자에게 제시되고, 그 검증자들이 결탁하거나 제3자가 두 검증자 모두의 거래 기록에 접근할 수 있다. 눈여겨보는 당사자는 그 검증가능한 크리덴셜을 제시하는 개인이 두 서비스에서 동일인이라고 추론할 수 있다. 즉 동일인이 두 계정을 통제한다는 것이다.
크리덴셜의 주체 식별자가 여러 프레젠테이션이나 검증자에 걸쳐 동일한 주체를 가리킨다. 서로 다른 크리덴셜이 제시되더라도 주체 식별자가 같으면, 검증자(그리고 검증자 로그에 접근할 수 있는 이들)는 그 크리덴셜들의 주체가 동일한 엔티티라고 추론할 수 있다.
크리덴셜에 담긴 기저 정보가 여러 서비스에 걸쳐 개인을 식별하는 데 사용될 수 있다. 이 경우 검증자는 다른 출처의 정보(보유자가 직접 제공한 정보 포함)를 사용하여, 그 크리덴셜 안의 정보로 그 개인을 기존 프로파일과 연결지을 수 있다. 예를 들어 보유자가 우편번호, 나이, 성별이 담긴 크리덴셜을 제시하면, 검증자는 그 크리덴셜의 주체를 기존 프로파일과 연결지을 수 있다. 자세한 내용은 [DEMOGRAPHICS]를 참조한다.
크리덴셜의 식별자를 중앙화된 폐기 서버에 전달한다. 그 중앙화된 서버는 여러 상호작용에 걸쳐 그 크리덴셜의 사용을 상관지을 수 있다. 예를 들어 크리덴셜이 이런 식으로 연령 증명에 사용되면, 그 중앙화된 서비스는 그 크리덴셜이 제시된 모든 곳(모든 주류 판매점, 술집, 성인용품점, 복권 판매점 등)을 알 수 있다.

이 익명 해제와 프라이버시 상실은 다음을 통해 부분적으로 완화할 수 있다.

보유자 소프트웨어가 주어진 각 검증가능한 크리덴셜에 대해 주체로서 전역적으로 고유한 식별자를 제공하고, 그 검증가능한 크리덴셜을 결코 재사용하지 않는 것.
발급자가 폐기 확인이 수행될 때 자신에게 접속이 오지 않도록 전역적으로 분산된 폐기 서비스를 사용하는 것.
규격 작성자가, 검증가능한 크리덴셜의 고유 식별자를 질의 API에 제출하는 데 의존하지 않고 대신 예컨대 프라이버시를 보호하는 폐기 목록을 사용하는 폐기 메커니즘을 설계하는 것.
발급자가 개인 식별 정보를 오래 지속되는 특정 주체 식별자와 연관시키지 않는 것.

안타깝게도 이러한 완화 기법은 때때로만 현실적이며, 필요한 용도와 양립조차 하지 않을 때도 있다. 때로는 상관관계 자체가 요구사항이기도 하다.

예를 들어 일부 처방 의약품 모니터링 프로그램에서는 처방 사용을 감시하는 것이 요구사항이다. 집행 기관은 개인이 규제 약물에 대한 다중 처방을 받으려고 제도를 악용하고 있지 않은지 확인할 수 있어야 한다. 처방 사용의 상관관계를 지어야 한다는 이러한 법적·규제적 필요는 개인의 프라이버시 우려에 우선한다.

검증가능한 크리덴셜은 여러 서비스에 걸쳐 개인을 의도적으로 상관짓는 데도 사용될 것이다. 예를 들어 공통 페르소나로 여러 서비스에 로그인할 때, 그 각 서비스에서의 모든 활동은 의도적으로 동일한 개인에 연결된다. 그 서비스들 각각이 그 상관관계를 예상된 방식으로 사용하는 한, 이는 프라이버시 문제가 아니다.

검증가능한 크리덴셜의 사용과 관련된 프라이버시 침해는, 그 검증가능한 크리덴셜을 제시하는 데서 의도치 않거나 예상치 못한 상관관계가 발생할 때 일어난다.

This section is non-normative.

법적 절차는 발급자, 보유자, 검증자에게 법 집행 기관과 같은 당국에 사적 정보를 공개하도록 강제할 수 있다. 또한 소프트웨어 버그나 보안 실패를 통해 동일한 사적 정보가 권한 없는 당사자에게 우발적으로 공개될 수도 있다. 법적 절차와 규정 준수 체계의 작성자는, 사적 정보가 의도적으로든 우발적으로든 제3자에게 공개될 때 관련 주체에게 통지하도록 요구하는 지침을 마련할 것을 권한다. 소프트웨어 서비스 제공자는 그러한 사적 정보가 제3자와 공유되게 할 수 있는 알려진 상황과 그 제3자의 신원에 대해 투명하게 밝힐 것을 권한다.

This section is non-normative.

검증가능한 크리덴셜과 검증가능한 프레젠테이션에 표현된 데이터는 신뢰할 수 있는 제3자(발급자 등)나 개인(보유자나 주체 등)이 한 진정한 진술을 담고 있어 가치가 있다. 이 데이터의 저장과 접근성은 악의적 행위자를 위한 민감 데이터의 허니팟을 의도치 않게 만들어낼 수 있다. 이러한 적대자는 흔히 그러한 민감 정보의 저수지를 악용하려 하며, 금전적 이득을 위해 그 데이터를 획득하고 거래하는 것을 목표로 한다.

발급자는 보유자에게 검증가능한 크리덴셜을 발급하고 그 크리덴셜의 상태와 폐기를 관리하는 데 필요한 최소한의 데이터만 보관할 것을 권한다. 마찬가지로 발급자는 개인 식별 정보(PII)나 그 밖의 민감한 데이터가 담긴, 공개적으로 접근 가능한 크리덴셜을 만들지 않을 것을 권한다. 소프트웨어 구현자는 견고한 동의 및 접근 제어 조치를 사용하여 검증가능한 크리덴셜을 보호하고, 권한 없는 엔티티가 접근할 수 없도록 보장할 것을 권한다.

보유자는 전송 중과 저장 중의 데이터를 적절히 암호화하고, 민감한 자료(암호학적 비밀 등)를 하드웨어나 기타 기기에서 쉽게 추출할 수 없는 방식으로 보호하는 구현을 사용할 것을 권한다. 나아가 보유자는 자신의 데이터가 공격받을 가능성과 공격이 성공했을 때 대규모 도난에 포함될 가능성을 줄이기 위해, 중앙화된 시스템에서 벗어나 자신이 통제하는 기기에서만 데이터를 저장하고 다룰 것을 제안한다. 또한 보유자는 자신의 크리덴셜과 프레젠테이션에 대한 접근을 엄격히 통제하여, 명시적으로 인가된 이들에게만 접근을 허용할 것을 권한다.

검증자는 특정 거래에 필요한 데이터만 요구하고, 특정 거래의 필요를 넘어서는 데이터는 보관하지 않을 것을 권한다.

규제 기관은 프라이버시를 더 잘 보존하는 메커니즘으로도 비슷한 집행 및 감사 역량을 달성할 수 있도록 기존 감사 요구사항을 재고할 것을 권한다. 예를 들어 개인 식별 정보의 수집과 장기 보관을 고집하는 감사 중심 규제는, 나중에 그 정보가 침해되어 공격자가 접근하게 되면 개인과 조직에 해를 끼칠 수 있다. 이 규격이 기술하는 기술은 보유자가 자신과 타인에 대한 속성을 더 손쉽게 증명할 수 있게 하여, 검증자가 데이터를 장기 보관할 필요를 줄인다. 대안으로는 정보가 수집되고 확인되었다는 로그를 남기는 것과, 규정 준수 체계가 예상대로 작동하는지 확인하기 위한 무작위 점검이 있다.

This section is non-normative.

8.14 사용 패턴 절에서 자세히 다룬 대로, 사용 패턴은 특정 유형의 행동과 상관지어질 수 있다. 이 상관관계는 보유자가 발급자가 모르는 채로 검증가능한 크리덴셜을 사용할 때 부분적으로 완화된다. 그러나 발급자는 자신의 검증가능한 크리덴셜의 수명을 짧게 하고 갱신을 자동으로 만듦으로써 이 보호를 무력화할 수 있다.

예를 들어 ageOver 검증가능한 크리덴셜은 술집에 들어가는 데 유용하다. 발급자가 그러한 검증가능한 크리덴셜을 유효 기간이 매우 짧고 자동 갱신 메커니즘을 갖춘 형태로 발급한다면, 그 발급자는 그 보유자의 행동을 상관지어 그 보유자에게 부정적인 영향을 줄 수 있다.

보유자에게 소프트웨어를 제공하는 조직은, 수명이 짧은 크리덴셜을 반복 사용하여 행동 상관관계로 이어질 수 있는 경우 그들에게 경고해야 한다. 발급자는 자신이 사용 패턴을 상관지을 수 있게 하는 크리덴셜을 발급하지 않아야 한다.

This section is non-normative.

이상적인, 프라이버시를 존중하는 시스템이라면 보유자가 검증자와의 상호작용에 필요한 정보만 공개하도록 요구할 것이다. 그러면 검증자는 공개 요건이 충족되었음을 기록하고 공개된 민감 정보는 폐기한다. 많은 경우 규제 부담과 같은 상충하는 우선순위 때문에 이 이상적인 시스템을 채택하지 못한다. 다른 경우에는 오래 지속되는 식별자가 일회용 사용을 가로막는다. 검증가능한 크리덴셜 생태계를 설계하는 사람은 가능한 한 일회용 검증가능한 크리덴셜을 선호함으로써 그 생태계를 최대한 프라이버시를 존중하는 것으로 만들려 노력해야 한다.

일회용 검증가능한 크리덴셜을 사용하면 여러 이점이 있다. 첫 번째 이점은 검증자에게 돌아간다. 검증가능한 크리덴셜의 데이터가 최신임을 확신할 수 있기 때문이다. 두 번째 이점은 보유자에게 돌아간다. 그 검증가능한 크리덴셜에 오래 지속되는 식별자가 없다면 그 검증가능한 크리덴셜 자체가 온라인에서 자신을 추적하거나 상관짓는 데 사용될 수 없음을 알기 때문이다. 끝으로 공격자가 훔칠 것이 없어져 생태계 전체가 더 안전하게 돌아간다.

This section is non-normative.

이상적인 비공개 브라우징 시나리오에서는 PII가 전혀 드러나지 않을 것이다. 많은 크리덴셜에 PII가 포함되므로, 보유자에게 소프트웨어를 제공하는 조직은 비공개 브라우징 모드에서 크리덴셜과 프레젠테이션을 사용할 경우 이 정보가 드러날 수 있다는 점을 그들에게 경고해야 한다. 브라우저 벤더마다 비공개 브라우징을 다르게 처리하고 일부 브라우저에는 이 기능이 없을 수 있으므로, 구현자가 어떤 프라이버시 보호든 비공개 브라우징 모드에 의존하지 않는 것이 중요하다. 그 대신 구현자는 프라이버시 보장을 제공하기 위해 자신의 소프트웨어가 직접 사용할 수 있는 도구에 의존할 것을 권한다.

This section is non-normative.

검증가능한 크리덴셜은 발급자에 대한 높은 수준의 신뢰에 의존한다. 보유자가 가능한 프라이버시 보호를 어느 정도까지 활용할 수 있는지는 흔히 발급자가 그러한 기능을 얼마나 지원하는지에 크게 좌우된다. 많은 경우 영지식 증명, 데이터 최소화 기법, 무기명 크리덴셜, 추상적 클레임, 서명 기반 상관관계에 대한 보호를 활용하는 프라이버시 보호는 발급자의 적극적인 지원을 필요로 하며, 발급자는 자신이 발급하는 검증가능한 크리덴셜에 그러한 역량을 포함시켜야 한다.

보유자가 보유자와 주체의 프라이버시를 지키는 데 도움이 되는 검증가능한 크리덴셜 역량을 제공받기 위해 발급자의 참여에 의존할 뿐 아니라, 발급자가 이러한 프라이버시 보호를 고의로 무너뜨리지 않으리라는 데에도 의존한다는 점에 유의하는 것이 매우 중요하다. 예를 들어 발급자가 서명 기반 상관관계를 막아주는 서명 방식을 사용하여 검증가능한 크리덴셜에 서명할 수 있다. 이는 서명 값이 검증자들 사이에서 공유될 때 그 값으로 보유자의 상관관계가 지어지는 것을 막아준다. 그러나 그 발급자가 발급하는 크리덴셜마다 고유한 키를 만든다면, 검증자는 그럴 수 없더라도 그 발급자는 그 크리덴셜의 프레젠테이션을 추적할 수 있을지도 모른다.

발급자가 제공할 수 있는, 앞서 기술한 프라이버시 보호에 더하여, 발급자는 크리덴셜을 발급할 때 사용하는 식별자 및 클레임 타입과 연관되어 새어나가는 데이터를 인지해야 한다. 그 한 예는, 자신의 관할 지역과 주체의 거주지를 모두 드러내는 운전면허증을 발급하는 발급자이다. 검증자는 이를 악용하여, 주체가 운전 면허를 가졌는지 확인한다며 크리덴셜을 요청하지만, 실제로는 그 크리덴셜에 대한 메타데이터, 예컨대 어느 발급자가 그 크리덴셜을 발급했는지와, 발급자가 흘렸을 수 있는 부수적 정보(예: 주체의 자택 주소)에 관심이 있을 수 있다. 그러한 유출을 완화하기 위해 발급자는 공통 식별자를 사용하여 구체적인 위치 정보나 그 밖의 민감한 메타데이터를 가릴 수 있다. 예를 들어 카운티, 시, 읍, 또는 더 작은 지자체 수준이 아니라 주(州)나 국가 수준의 공유 발급자 식별자를 쓰는 것이다. 나아가 검증자는 정확한 발급자를 공개할 필요 없이 어떤 발급자가 신뢰할 수 있는 엔티티 집합에 존재한다는 증명을 제공하는 보유자 증언 메커니즘을 사용하여 프라이버시를 지킬 수 있다.

기본 클래스	목적
`CredentialEvidence`	evidence 속성에 들어가는 구체적인 증거 타입의 상위 클래스 역할을 한다.
`CredentialSchema`	credentialSchema 속성에 들어가는 구체적인 스키마 타입의 상위 클래스 역할을 한다.
`CredentialStatus`	credentialStatus 속성에 들어가는 구체적인 크리덴셜 상태 타입의 상위 클래스 역할을 한다.
`ConfidenceMethod`	`confidenceMethod` 속성에 들어가는 구체적인 신뢰도 방법 타입의 상위 클래스 역할을 한다.
`RefreshService`	credentialRefresh 속성에 들어가는 구체적인 갱신 서비스 타입의 상위 클래스 역할을 한다.
`RenderMethod`	`renderMethod` 속성에 들어가는 구체적인 렌더 방법 타입의 상위 클래스 역할을 한다.
`TermsOfUse`	termsOfUse 속성에 들어가는 구체적인 사용 조건 타입의 상위 클래스 역할을 한다.

타입 이름:	application
서브타입 이름:	vc
필수 매개변수:	없음
인코딩 고려사항:	`application/vc` 미디어 타입을 사용하는 자원은 `application/ld+json` 미디어 타입의 모든 요구사항에 부합해야 하며, 따라서 The JavaScript Object Notation (JSON) Data Interchange Format의 Section 11이 명시하는 것과 동일한 인코딩 고려사항의 적용을 받는다.
보안 고려사항:	Verifiable Credentials Data Model v2.0에 정의된 대로.
연락처:	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

타입 이름:	application
서브타입 이름:	vp
필수 매개변수:	없음
인코딩 고려사항:	`application/vp` 미디어 타입을 사용하는 자원은 `application/ld+json` 미디어 타입의 모든 요구사항에 부합해야 하며, 따라서 The JavaScript Object Notation (JSON) Data Interchange Format의 Section 11이 명시하는 것과 동일한 인코딩 고려사항의 적용을 받는다.
보안 고려사항:	Verifiable Credentials Data Model v2.0에 정의된 대로.
연락처:	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

JSON-LD 문서와 해시
URL: https://www.w3.org/2018/credentials# 해석된 문서: https://www.w3.org/2018/credentials/index.jsonld SHA2-256 다이제스트: `9db03c54d69a8ec3944f10770e342b33e58a79045c957c35d51285976fc467c4`
URL: https://w3id.org/security# 해석된 문서: https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.jsonld SHA2-256 다이제스트: `689af6f393b55c9b35c37cfad59d13cc421e0c89ce97cf0e8234f9b4a3074104`

검증가능한 크리덴셜 데이터 모델(Verifiable Credentials Data Model v2.0)

요약

현재 문서의 상태

1. 소개

1.1 검증가능한 크리덴셜이란 무엇인가?

1.2 생태계 개요

1.3 적합성

2. 용어

3. 핵심 데이터 모델

3.1 클레임

3.2 크리덴셜

3.3 프레젠테이션

4. 기본 개념

4.1 시작하기

4.2 검증가능한 크리덴셜

4.3 컨텍스트

4.4 식별자

Claim: id

Claim: type

Claim: id

Claim: type

4.5 타입

Claim: id

Claim: type

Claim: id

Claim: type

4.6 이름과 설명

Claim: id

Claim: type

Claim: id

Claim: id

Claim: type

4.7 발급자

Claim: id

Claim: type

Claim: id

Claim: type

Claim: id

Claim: type

Claim: id

Claim: id

Claim: type

4.8 크리덴셜 주체

Claim: id

Claim: type

Claim: id

Claim: type

4.9 유효 기간

Claim: id

Claim: type

Claim: id

Claim: type

4.10 상태

4.11 데이터 스키마

4.12 보안 메커니즘

4.13 검증가능한 프레젠테이션

봉투로 감싼 검증가능한 크리덴셜

봉투로 감싼 검증가능한 프레젠테이션

파생 크리덴셜을 사용하는 프레젠테이션

보유자 클레임을 포함하는 프레젠테이션

5. 고급 개념

5.1 신뢰 모델

5.2 확장성

Claim: id

Claim: type

Claim: id

의미론적 상호 운용성

5.3 관련 자원의 무결성

5.4 갱신

5.5 사용 조건

5.6 증거

5.7 영지식 증명

5.8 시간 표현

5.9 인가

5.10 예약된 확장점

5.11 생태계 호환성

5.12 검증가능한 크리덴셜 그래프

5.13 보안 메커니즘 규격

6. 구문

6.1 JSON-LD