검증 가능한 자격 증명 데이터 모델 v2.1

초록

하나의 검증 가능한 자격 증명은 일련의 주장을 발급자가 표현하는 특정 방식으로, 운전면허증이나 교육 수료증 등이 그 예입니다. 이 명세는 검증 가능한 자격 증명을 위한 확장 가능한 데이터 모델과, 이를 변조로부터 보호하는 방법 및 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 확장성에서 설명합니다. 또는 개발자가 자신의 사용 사례에 적합한 기존 어휘 및 컨텍스트 파일을 재사용할 수도 있습니다. 재사용 가능한 리소스는 검증 가능한 자격 증명 확장에서 찾아볼 수 있습니다.

검증 가능한 자격 증명은 하나 이상의 주체의 속성과 자격 증명 자체의 속성을 표현하는 데 사용합니다. 이 명세에서는 검증 가능한 자격 증명에 다음 속성을 정의합니다:

@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에 매핑합니다.

검증 가능한 자격 증명과 검증 가능한 프레젠테이션은 MUST에 따라 @context 속성을 포함해야 합니다. 애플리케이션 개발자는 MUST에 따라 자신의 애플리케이션에서 사용하는 모든 JSON-LD 컨텍스트를 최소한 해당 애플리케이션에서 사용하는 용어의 의미에 영향을 주는 범위까지 이해해야 합니다. 이를 위한 한 가지 메커니즘은 검증 가능한 자격 증명 데이터 무결성 1.0 명세의 컨텍스트 유효성 검사 절에서 설명합니다. 이 명세를 기반으로 하는 다른 명세는 MAY에 따라 5.3 관련 리소스의 무결성에서 설명하는 relatedResource 기능 또는 실질적으로 동일한 메커니즘을 사용하여 JSON-LD 컨텍스트의 무결성을 보호하도록 요구할 수 있습니다.

@context: @context 속성의 값은 MUST에 따라 첫 번째 항목이 값 https://www.w3.org/ns/credentials/v2인 URL인 순서 집합이어야 합니다. 순서 집합의 이후 항목은 MUST에 따라 각각 JSON-LD 컨텍스트로 처리할 수 있는 URL과 객체의 임의 조합으로 구성되어야 합니다.

예제 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에서 제공되는 데이터는 영구적으로 캐시할 수 있는 정적 문서이며, 이를 처리하기 위한 지침은 부록 C.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 명세의 3.1절: 컨텍스트에서 자세히 설명합니다.

이 문서에서 지정하는 종류의 객체를 처리하는 소프트웨어 시스템은 제공된 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션이 의도한 사용 사례에 적합한지 판단하기 위해 유형 정보를 사용합니다. 이 명세에서는 객체 유형 정보를 표현하기 위한 type 속성을 정의합니다. 이 유형 정보는 부록 B. 유효성 검사에 설명된 유효성 검사 과정에서 사용할 수 있습니다.

검증 가능한 자격 증명과 검증 가능한 프레젠테이션에는 MUST에 따라 연결된 값을 가진 type 속성이 포함되어야 합니다.

type: type 속성의 값은 MUST에 따라 하나 이상의 용어 및 절대 URL 문자열이어야 합니다. 둘 이상의 값을 제공하는 경우 순서는 중요하지 않습니다.

이 명세와 관련하여 다음 표에는 유형을 MUST에 따라 지정해야 하는 객체를 나열합니다.

객체	유형
검증 가능한 자격 증명 객체	`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의 유형 시스템과 동일하며, 3.5절: 유형 지정 및 9절: JSON-LD 문법에서 자세히 설명합니다. JSON-LD 컨텍스트를 사용하는 경우(다음 절 참조: 5.2 확장성) 이 명세에서는 JSON-LD 문서를 더 쉽게 이해할 수 있도록 @type 키워드의 별칭으로 type을 사용합니다. 애플리케이션 개발자와 문서 작성자는 JSON-LD 유형 시스템의 세부 사항을 이해할 필요가 없지만, 상호 운용 가능한 확장성을 지원하려는 이 명세의 구현자는 이해해야 합니다.

모든 자격 증명, 프레젠테이션 및 캡슐화된 객체는 소프트웨어 시스템이 이 추가 정보를 더 쉽게 감지하고 처리할 수 있도록 ExampleDegreeCredential 같은 더 구체적인 추가 유형을 SHOULD에 따라 지정하거나 해당 유형과 연결해야 합니다.

이 명세에서 정의한 캡슐화된 객체를 처리할 때, 예를 들어 credentialSubject 객체와 연결되거나 그 내부에 깊이 중첩된 객체를 처리할 때 소프트웨어 시스템은 계층 구조에서 더 상위에 있는 캡슐화 객체에 지정된 유형 정보를 SHOULD에 따라 사용해야 합니다. 구체적으로 자격 증명과 같은 캡슐화 객체는 검증자가 캡슐화 객체의 유형을 기반으로 연결된 객체의 내용을 빠르게 판단할 수 있도록 연결된 객체의 유형을 SHOULD에 따라 전달해야 합니다.

예를 들어 type이 ExampleDegreeCredential인 자격 증명 객체는 credentialSubject 속성과 연결된 객체에 다음 식별 정보가 포함되어 있음을 검증자에게 알립니다:

id 속성의 주체.
type 속성의 학위 유형.
name 속성의 학위 명칭.

이를 통해 구현자는 type 속성과 연결된 값을 검증에 사용할 수 있습니다. 객체 유형과 이에 연결된 값은 적어도 해당 유형의 URL에서 찾을 수 있는 사람이 읽을 수 있는 명세에 문서화되어야 합니다. 예를 들어 BitstringStatusList 유형의 사람이 읽을 수 있는 정의는 https://www.w3.org/ns/credentials/status/#BitstringStatusList에서 확인할 수 있습니다. 또한 동일한 URL에서 HTTP 콘텐츠 협상을 통해 기계 판독 가능한 버전을 제공하는 것이 좋습니다.

참고: 새 자격 증명 유형을 생성하려면 구현 지침을 참조하세요

새로운 유형의 검증 가능한 자격 증명을 생성하는 방법에 대한 설명은 이 명세의 범위를 벗어납니다. 이에 관심 있는 독자는 검증 가능한 자격 증명 구현 지침 1.0의 새 자격 증명 유형 생성 절을 읽는 것이 좋습니다.

자격 증명을 표시할 때는 발급자가 제공하여 자격 증명에 이름과 그 목적에 대한 간단한 설명을 덧붙이는 텍스트가 있으면 유용할 수 있습니다. name 및 description 속성은 이러한 용도로 사용됩니다.

name: 자격 증명의 이름을 나타내는 선택 사항 속성입니다. 이 속성이 있는 경우, name 속성의 값은 반드시 하나 이상의 문자열 또는 언어 값 객체여야 하며, 이에 대해서는 9.1 언어 및 기본 방향에 설명되어 있습니다. 이상적으로는 자격 증명의 이름이 간결하고 사람이 읽을 수 있으며, 개인이 보유하고 있는 하나의 자격 증명을 다른 자격 증명과 빠르게 구별할 수 있도록 해야 합니다.
description: 자격 증명에 관한 구체적인 세부 정보를 전달하는 선택 사항 속성입니다. 이 속성이 있는 경우, description 속성의 값은 반드시 하나 이상의 문자열 또는 언어 값 객체여야 하며, 이에 대해서는 9.1 언어 및 기본 방향에 설명되어 있습니다. 이상적으로는 자격 증명의 설명이 몇 문장 이하의 길이이며, 개인이 자격 증명의 전체 클레임을 살펴보지 않고도 그 내용을 떠올릴 수 있을 만큼 충분한 정보를 전달해야 합니다.

예제 5: name 및 description 속성 사용

이름과 설명은 여러 언어로 콘텐츠를 표현하는 것도 지원합니다. 언어 및 기본 방향 정보가 포함된 문자열을 표현하려면 @value, @language 및 @direction 속성을 포함하는 객체를 사용하여 각각 텍스트 값, 언어 태그 및 기본 방향을 표현할 수 있습니다. 자세한 내용은 9.1 언어 및 기본 방향을 참조하십시오.

참고: @direction은 단일 언어 문자열에 필수가 아닙니다

아래 예제의 @direction 속성은 관련 단일 언어 문자열에 필수가 아닙니다. 이러한 문자열의 기본 방향이 @direction 값으로 설정된 방향과 동일하기 때문입니다. 여기서는 예시를 명확히 하고 복사+붙여넣기+편집을 통해 올바르게 작동하는 결과를 얻을 수 있도록 @direction 속성을 포함했습니다. 구현자는 JSON-LD 1.1 사양의 문자열 국제화 절을 읽어보는 것이 좋습니다.

예제 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 속성은 OPTIONAL입니다. 이 속성은 자격 증명 상태 객체의 고유 식별자를 제공하는 데 사용할 수 있습니다(MAY). 이 속성이 있는 경우 4.4 식별자절의 규범적 지침을 따라야 합니다(MUST).
type: type 속성은 REQUIRED입니다. 이 속성은 객체가 표현하는 상태 정보의 유형을 나타내는 데 사용됩니다. 4.5 유형절의 관련 규범적 지침을 따라야 합니다(MUST).

자격 증명 상태 정보의 정확한 내용은 구체적인 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"
  }]
}

구현자는 여러 상태 항목이 있는 자격 증명에 서로 충돌하는 정보가 포함될 수 있다는 점에 유의해야 합니다. 이러한 충돌을 조정하는 작업은 유효성 검사 프로세스의 일부이므로 검증자의 비즈니스 로직에 속하며, 따라서 이 사양의 범위를 벗어납니다.

상태 체계의 데이터 모델, 형식 및 프로토콜을 정의하는 것은 이 사양의 범위를 벗어납니다. 검증 가능한 자격 증명 확장 문서에는 검증 가능한 자격 증명의 상태 확인을 구현하려는 구현자가 사용할 수 있는 상태 체계가 포함되어 있습니다.

자격 증명 상태 사양은 개인 추적을 가능하게 해서는 안 됩니다(MUST NOT). 예를 들어 검증자가 특정 보유자 또는 주체에 관심을 보일 때 발급자에게 직간접적으로 알리는 방식이 이에 해당합니다. 허용할 수 없는 접근 방식에는 자격 증명을 사용할 때마다 특정 개인의 상태를 확인하기 위해 자격 증명의 발급자에게 연락하는 "홈으로 연락하기" 방식이나, 자격 증명을 사용할 때마다 발급자에게 정보를 요청하여 발급자가 특정 개인에 대한 검증자의 관심을 추론할 수 있게 하는 "가명성 저하" 방식이 포함됩니다.

데이터 스키마는 주어진 데이터 모음에 특정 구조를 적용할 때 유용합니다. 이 사양에서는 최소한 다음 두 가지 유형의 데이터 스키마를 고려합니다.

데이터 검증 스키마는 자격 증명 또는 검증 가능한 자격 증명의 구조와 내용이 공개된 스키마를 준수하는지 확인하는 데 사용됩니다.
데이터 인코딩 스키마는 검증 가능한 자격 증명의 내용을 영지식 증명에 사용되는 형식과 같은 대체 표현 형식으로 매핑하는 데 사용됩니다.

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

이 사양은 발급자가 발급하는 검증 가능한 자격 증명에 포함할 수 있는 데이터 스키마를 표현하기 위해 다음 속성을 정의합니다.

credentialSchema

credentialSchema 속성의 값은 제공된 데이터가 제공된 스키마를 준수하는지 판단하기에 충분한 정보를 검증자에게 제공하는 하나 이상의 데이터 스키마여야 합니다(MUST). 각 credentialSchema는 type(예: JsonSchema)과 스키마 파일을 식별하는 URL이어야 하는 id 속성을 지정해야 합니다(MUST). 구체적인 유형 정의에 따라 각 데이터 스키마의 정확한 내용이 결정됩니다.

여러 스키마가 있는 경우 각 스키마와 연결된 type 속성에 명시된 처리 규칙에 따라 유효성이 결정됩니다.

참고: 자격 증명 유형별 구문 검사가 가능합니다

credentialSchema 속성을 사용하면 유형 정의에 주석을 달거나 어휘의 특정 버전에 고정할 수 있습니다. 검증 가능한 자격 증명의 작성자는 콘텐츠 무결성 보호 메커니즘으로 보호된 어휘의 정적 버전을 credentialSchema를 사용하여 포함할 수 있습니다. credentialSchema 속성을 사용하면 자격 증명에 대한 구문 검사도 수행할 수 있으며, JSON 스키마 [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 스키마 [VC-JSON-SCHEMA] 파일을 가리킵니다.

이 사양에서는 두 가지 종류의 보호 메커니즘을 인정합니다. 하나는 엔벨로핑 증명을 사용하는 메커니즘이고 다른 하나는 내장 증명을 사용하는 메커니즘입니다.

엔벨로핑 증명은 이 데이터 모델의 직렬화된 표현을 감쌉니다. 이러한 RECOMMENDED 엔벨로핑 증명 메커니즘 중 하나는 JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]에 정의되어 있습니다.

내장 증명은 증명이 데이터 모델의 직렬화된 표현에 포함되는 메커니즘입니다. 이러한 RECOMMENDED 내장 증명 메커니즘 중 하나는 검증 가능한 자격 증명 데이터 무결성 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 형식을 이해하는 도구를 사용하여 처리할 수 있는 검증 가능한 자격 증명이 생성됩니다.

검증 가능한 프레젠테이션은 여러 검증 가능한 자격 증명의 정보를 집계하는 데 사용할 수 있습니다(MAY).

검증 가능한 프레젠테이션은 수명이 극히 짧고 검증자가 제공한 챌린지에 바인딩되어야 합니다(SHOULD). 이를 달성하는 구체적인 방법은 보호 메커니즘, 전송 프로토콜 및 검증자 정책에 따라 달라집니다. 특정 보호 메커니즘이나 임베딩 프로토콜에서 추가 요구 사항을 정의하지 않는 한, 검증자는 일반적으로 검증 가능한 프레젠테이션이 제시된 검증 가능한 자격 증명과 연관되어 있다고 가정할 수 없습니다.

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

검증 가능한 프레젠테이션에는 다음 속성이 정의됩니다.

id: id 속성은 선택 사항입니다. 이 속성은 검증 가능한 프레젠테이션의 고유 식별자를 제공하는 데 사용할 수 있습니다(MAY). 이 속성이 있는 경우 4.4 식별자절의 규범적 지침을 따라야 합니다(MUST).
type: type 속성은 있어야 합니다(MUST). 이 속성은 검증 가능한 프레젠테이션의 유형을 표현하는 데 사용됩니다. 이 속성의 값 중 하나는 VerifiablePresentation이어야 하지만(MUST), 추가 유형을 포함할 수도 있습니다(MAY). 4.5 유형절의 관련 규범적 지침을 따라야 합니다(MUST).
verifiableCredential: verifiableCredential 속성은 존재할 수 있습니다(MAY). 그 값은 하나 이상의 검증 가능한 자격 증명 및/또는 엔벨로프된 검증 가능한 자격 증명 객체여야 합니다(MUST). 값은 숫자, 문자열 또는 URL과 같은 객체가 아닌 값이어서는 안 됩니다(MUST NOT). 이러한 객체를 검증 가능한 자격 증명 그래프라고 하며, 보호 메커니즘을 사용하여 보호된 정보를 표현해야 합니다(MUST). 자세한 내용은 5.12 검증 가능한 자격 증명 그래프절을 참조하십시오.
holder: 검증 가능한 프레젠테이션에는 holder 속성을 포함할 수 있습니다(MAY). 이 속성이 있는 경우 그 값은 URL 또는 id 속성을 포함하는 객체여야 합니다(MUST). holder의 URL 또는 그 id는 역참조했을 때 검증 가능한 프레젠테이션에 표현된 정보를 검증하는 데 사용할 수 있는 보유자에 관한 기계 판독 가능 정보를 포함하는 문서가 반환되는 것이 RECOMMENDED됩니다. 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 속성의 내용은 이 사양에서 설명하는 검증 가능한 자격 증명 그래프입니다.

검증 가능한 프레젠테이션에는 JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]와 같이 페이로드를 "엔벨로프"하는 보호 메커니즘을 사용하여 보호된 하나 이상의 검증 가능한 자격 증명을 포함할 수 있습니다. 이는 type이 EnvelopedVerifiableCredential인 객체를 verifiableCredential 속성과 연결하여 달성할 수 있습니다.

EnvelopedVerifiableCredential: 엔벨로프된 검증 가능한 자격 증명을 포함하는 객체를 검증 가능한 프레젠테이션의 verifiableCredential 속성과 연결하는 데 사용됩니다. 객체의 @context 속성은 있어야 하며(MUST), 이 사양이 제공하는 기본 컨텍스트에 정의된 것과 같이 최소한 id, type 및 EnvelopedVerifiableCredential 용어를 정의하는 이 사양의 기본 컨텍스트와 같은 컨텍스트를 포함해야 합니다. 객체의 id 값은 검증 가능한 자격 증명을 엔벨로핑 보안 체계를 사용하여 보호된 형태로 표현하는 data: URL이어야 합니다(MUST) [RFC2397]. 이러한 체계의 예로 JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]가 있습니다. 객체의 type 값은 EnvelopedVerifiableCredential이어야 합니다(MUST).

아래 예제는 엔벨로프된 검증 가능한 자격 증명을 포함하는 검증 가능한 프레젠테이션을 보여 줍니다.

예제 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와 관련된 객체 사이에 연결을 생성하고자 할 수 있습니다. 이를 수행하려는 필요성과 그 메커니즘은 사용 사례에 따라 달라지므로 구현에 따라서도 달라집니다.

JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]와 같이 페이로드를 "엔벨로프"하는 메커니즘을 사용하여 보호된 검증 가능한 프레젠테이션을 표현할 수 있습니다. 이는 type이 EnvelopedVerifiablePresentation인 객체를 사용하여 달성할 수 있습니다.

EnvelopedVerifiablePresentation: 엔벨로프된 검증 가능한 프레젠테이션을 표현하는 데 사용됩니다. 객체의 @context 속성은 있어야 하며(MUST), 이 사양이 제공하는 기본 컨텍스트에 정의된 것과 같이 최소한 id, type 및 EnvelopedVerifiablePresentation 용어를 정의하는 이 사양의 기본 컨텍스트와 같은 컨텍스트를 포함해야 합니다. 객체의 id 값은 검증 가능한 프레젠테이션을 엔벨로핑 보호 메커니즘을 사용하여 보호된 형태로 표현하는 data: URL이어야 합니다(MUST) [RFC2397]. 이러한 메커니즘의 예로 JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]가 있습니다. 객체의 type 값은 EnvelopedVerifiablePresentation이어야 합니다(MUST).

아래 예제는 엔벨로프된 검증 가능한 프레젠테이션을 보여 줍니다.

예제 19: 엔벨로프된 검증 가능한 프레젠테이션의 기본 구조

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

일부 영지식 암호 방식에서는 보유자가 주장을 검증 가능한 자격 증명에서 받았으며 이를 보유하고 있음을, 해당 검증 가능한 자격 증명의 모든 주장을 공개하지 않고도 간접적으로 증명할 수 있습니다. 이러한 방식에서는 검증 가능한 자격 증명을 사용하여 제시 가능한 데이터를 파생할 수 있습니다. 이 데이터는 검증자가 발급자를 신뢰한다면 그 값을 신뢰할 수 있도록 암호학적으로 보증됩니다.

일부 선택적 공개 체계에서는 검증 가능한 자격 증명에서 파생된 주장의 일부를 공유할 수 있습니다.

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

직접 내장된 검증 가능한 자격 증명 대신 파생 데이터를 포함하는 ZKP 형식의 검증 가능한 프레젠테이션의 예는 5.7 영지식 증명절을 참조하십시오.

Pat에게 값이 21인
overAge 속성이 있습니다 — 그림 11 Pat이 21세를 초과했음을 표현하는 기본 주장입니다.

보유자는 검증 가능한 프레젠테이션의 verifiableCredential 속성을 사용하여 자신을 포함한 모든 발급자의 검증 가능한 자격 증명을 포함할 수 있습니다(MAY). 검증 가능한 자격 증명의 발급자가 보유자인 경우, 해당 검증 가능한 자격 증명의 주장은 자체 주장으로 간주됩니다. 이러한 자체 주장은 이를 포함하는 검증 가능한 프레젠테이션을 보호하는 것과 동일한 메커니즘이나 다른 검증 가능한 자격 증명에 사용할 수 있는 모든 메커니즘으로 보호할 수 있습니다.

이러한 자체 주장된 주체, 즉 주장의 대상에는 제한이 없습니다. 따라서 이러한 주장에는 보유자, 함께 포함된 다른 검증 가능한 자격 증명 중 하나, 심지어 자체 주장된 검증 가능한 자격 증명이 포함된 검증 가능한 프레젠테이션에 관한 진술도 포함될 수 있습니다. 각 경우 id 속성은 특정 주체를 식별하는 데 사용됩니다. 이는 해당 주체에 관한 주장이 제시되는 객체에서, 자체 주장되지 않은 검증 가능한 자격 증명과 동일한 방식으로 이루어집니다.

자체 주장 검증 가능한 자격 증명을 포함하고, 해당 자격 증명이 검증 가능한 프레젠테이션과 동일한 메커니즘으로만 보호되는 검증 가능한 프레젠테이션은 holder 속성을 포함해야 합니다(MUST).

검증 가능한 자격 증명에 대해 정의된 모든 규범적 요구 사항은 자체 주장 검증 가능한 자격 증명에도 적용됩니다.

검증 가능한 프레젠테이션에 포함된 검증 가능한 자격 증명은 해당 검증 가능한 자격 증명의 issuer 속성 값이 검증 가능한 프레젠테이션의 holder 속성 값과 같으면 자체 주장된 것으로 간주됩니다.

아래 예제는 검증 가능한 프레젠테이션과 동일한 메커니즘을 사용하여 보호된 자체 주장 검증 가능한 자격 증명을 포함하는 검증 가능한 프레젠테이션을 보여 줍니다.

예제 20: 내장 데이터 무결성 증명으로 보호되고 자체 주장 검증 가능한 자격 증명을 포함하는 검증 가능한 프레젠테이션

{
  "@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: 내장 데이터 무결성 증명으로 보호되고 검증 가능한 프레젠테이션에 관한 자체 주장 검증 가능한 자격 증명을 포함하는 검증 가능한 프레젠테이션

{
  "@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. 기본 개념절에서 소개한 개념을 바탕으로, 이 절에서는 검증 가능한 자격 증명에 관한 더 복잡한 주제를 살펴봅니다.

이 절은 비규범적입니다.

검증 가능한 자격 증명의 신뢰 모델은 다음과 같은 기대를 기반으로 합니다.

검증자는 발급자가 자신이 받는 자격 증명을 검증 가능한 방식으로 발급하기를 기대합니다. 이는 다음 중 하나를 충족하여 확립할 수 있습니다.
- 발급자가 자격 증명을 보호 메커니즘으로 보호하여, 발급자가 해당 자격 증명을 생성했음을 확립합니다. 다시 말해, 발급자가 검증 가능한 자격 증명을 발급합니다.
- 자격 증명은 다음 사항을 명확히 확립하는 방식으로 전송됩니다. 즉, 발급자가 자격 증명을 생성했으며, 자격 증명이 전송 중이나 저장 중에 변조되지 않았다는 것입니다. 이 기대 수준은 검증자의 위험 평가에 따라 낮아질 수 있습니다.
모든 엔터티는 검증 가능한 데이터 레지스트리가 변조 흔적을 드러내고, 어느 데이터가 어느 엔터티의 통제를 받는지 정확히 기록하기를 기대합니다. 이는 일반적으로 게시 방식으로 달성됩니다. 예를 들어 신뢰할 수 있는 게시자의 피어 투 피어 프로토콜, 공개적으로 접근할 수 있고 널리 알려진 웹 사이트 (콘텐츠 해시 포함), 블록체인 등을 사용할 수 있습니다. 엔터티가 자신에 관한 메타데이터를 게시할 때에는 엔터티의 개인 키로 보호하여 게시물의 무결성을 보호할 수 있습니다.
보유자와 검증자는 발급자가 주장한 내용, 즉 자격 증명에서 주체에 관해 밝힌 내용을 계속 지지하고, 더 이상 이를 지지하지 않게 되면 자격 증명을 신속히 철회하여 해당 주장을 거두기를 기대합니다.
보유자는 발급자의 주장을 신뢰할 수 있습니다. 이는 보유자가 발급자와 기존 신뢰 관계를 맺고 있기 때문입니다. 예를 들어 고용주는 직원에게 고용 검증 가능한 자격 증명을 제공하거나, 정부는 시민에게 전자 여권을 발급할 수 있습니다.
기존 신뢰 관계가 없다면 보유자는 발급자가 제공되는 검증 가능한 자격 증명을 발급할 자격이 있는지 판단할 대역 외 수단을 사용할 수 있습니다.

참고: 보유자가 항상 발급자를 신뢰해야 하는 것은 아닙니다. 발급된 검증 가능한 자격 증명이 주체에 관한 주장일 수 있는데, 그 주체가 보유자가 아니거나 특정 인물을 가리키지 않을 수도 있기 때문입니다. 또한 보유자는 정보의 진실성에 대한 책임을 지지 않고 이를 검증자에게 전달하고자 할 수 있습니다.
보유자는 자격 증명 저장소가 자격 증명을 안전하게 저장하고, 자격 증명을 보유자 외의 누구에게도 공개하지 않으며 (보유자는 이후 이를 검증자에게 제시할 수 있습니다), 보관하는 동안 자격 증명을 손상하거나 잃지 않기를 기대합니다.

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

발급자와 검증자는 자격 증명 저장소에 관해 아무것도 알 필요가 없습니다.
발급자는 검증자에 관해 아무것도 알 필요가 없습니다.

검증자가 어떤 발급자를 어떤 데이터나 목적에 대해 신뢰할지 결정하는 방법은 이 권고안의 범위를 벗어납니다. 잘 알려진 조직과 같은 일부 발급자는 평판만으로 많은 검증자의 신뢰를 받을 수 있습니다. 일부 발급자와 검증자는 가입 규칙에 따라 모든 구성원이 서로 신뢰하는 공동체의 구성원일 수 있습니다. 일부 검증자는 발급자를 심사하고 전자 서명 및 인프라(ESI); 신뢰 목록 [ETSI-TRUST-LISTS] 또는 Adobe 승인 신뢰 목록과 같은 신뢰 목록에 올리는 일을 담당하는 특정 신뢰 서비스 제공자를 신뢰할 수 있습니다.

발급자와 검증자 사이의 기대를 분리하면 더 유연하고 동적인 신뢰 모델이 만들어져 시장 경쟁과 고객의 선택권이 확대됩니다.

이 신뢰 모델이 실무 그룹에서 연구한 여러 위협 모델과 어떻게 상호 작용하는지 자세히 알아보려면 검증 가능한 자격 증명 사용 사례 [VC-USE-CASES]를 참조하십시오.

참고: 신뢰 모델은 기존 인증 기관 시스템과 다릅니다

이 사양에 상세히 기술된 데이터 모델은 보다 전통적인 인증 기관 신뢰 모델이 제공하는 것과 같은 전이적 신뢰 모델을 전제로 하지 않습니다. 검증 가능한 자격 증명 데이터 모델에서 검증자는 발급자를 직접 신뢰하거나 신뢰하지 않습니다. 검증 가능한 자격 증명 데이터 모델을 사용해 전이적 신뢰 모델을 구축할 수는 있지만, 구현자는 보안 취약점을 알아보는 것이 좋습니다. 이러한 취약점은 인증 기관 시스템이 채택한 방식으로 신뢰를 광범위하게 위임할 때 발생합니다.

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

관련 리소스까지 무결성을 보호하기 위해 발급자는 검증 가능한 자격 증명에 MAY relatedResource 속성을 포함할 수 있습니다.

relatedResource

relatedResource 속성의 값은 MUST 다음 형식의 하나 이상의 객체여야 합니다.

속성	설명
`id`	리소스의 식별자는 REQUIRED이며 4.4 식별자절에서 정의한 형식을 준수합니다. 이 값은 관련 리소스 객체 목록에서 MUST 고유해야 합니다.
`mediaType`	이 값은 OPTIONAL이며 IANA 미디어 유형 레지스트리에 나열된 유효한 미디어 유형입니다.
`digestSRI`	하나 이상의 암호화 다이제스트이며, `hash-expression` ABNF 문법으로 정의됩니다. 이 문법은 하위 리소스 무결성 사양에 정의되어 있습니다. 다음을 참조하십시오. 3.5절: `integrity` 속성.
`digestMultibase`	하나 이상의 암호화 다이제스트이며, `digestMultibase` 속성으로 정의됩니다. 이 속성은 검증 가능한 자격 증명 데이터 무결성 1.0 사양에 정의되어 있습니다. 다음을 참조하십시오. 2.6절: 리소스 무결성.

relatedResource와 연결된 각 객체는 MUST 최소한 digestSRI 또는 digestMultibase 값을 하나 포함해야 합니다.

mediaType이 나열되어 있으면 id 속성으로 식별된 리소스를 HTTP 의미론을 사용해 가져오는 구현은 SHOULD 다음을 수행해야 합니다.

Accept HTTP 헤더에 해당 미디어 유형을 사용합니다.
응답에 다른 미디어 유형의 Content-Type HTTP 헤더가 포함되어 있으면 응답을 거부합니다.

검증 가능한 자격 증명에서 id 속성을 포함하는 모든 객체에는 MAY digestSRI 또는 digestMultibase 속성을 추가하여 무결성 정보를 주석으로 달 수 있습니다. 두 속성 모두 MAY 추가적인 선택 사항인 mediaType 속성과 함께 사용할 수 있습니다.

선택적 공개 또는 연결 불가능한 공개가 필요한 객체는 SHOULD NOT relatedResource 배열의 객체로 포함해서는 안 됩니다.

적합한 검증자 구현이 id를 기준으로 리소스를 사용하는 경우, 이 식별자가 relatedResource 객체에 속하고 해당 객체가 적합 문서 안에 있고 이에 대응하는 암호화 다이제스트가 relatedResource 객체 값에 나타난다면, 구현은 MUST 가져온 리소스의 다이제스트를 계산해야 합니다. 발급자가 제공한 다이제스트가 가져온 리소스에 대해 계산한 다이제스트와 일치하지 않으면, 적합한 검증자 구현은 MUST 오류를 발생시켜야 합니다.

구현자는 현재 사용하기에 적합하고 신뢰할 수 있는 해시 알고리즘을 선택하기 위해 FIPS 180-4 보안 해시 표준 및 상용 국가 보안 알고리즘 제품군 2.0과 같은 적절한 자료를 참조하는 것이 좋습니다. 이 글을 작성하는 시점에는 sha384를 구현자가 사용할 수 있는 최소 강도의 해시 알고리즘으로 SHOULD 간주해야 합니다.

다음은 JSON-LD 컨텍스트를 참조하는 관련 리소스 무결성 객체의 예입니다.

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

"relatedResource": [{
  "id": "https://www.w3.org/ns/credentials/v2",
  "digestSRI":
    "sha384-l/HrjlBCNWyAX91hr6LFV2Y3heB5Tcr6IeE4/Tje8YyzYBM8IhqjHWiWpr8+ZbYU"
},{
  "id": "https://www.w3.org/ns/credentials/examples/v2",
  "digestSRI":
    "sha384-zNNbQTWCSUSi0bbz7dbua+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"
}]

시스템에서 만료된 검증 가능한 자격 증명을 수동 또는 자동으로 갱신할 수 있으면 유용합니다. 검증 가능한 자격 증명의 유효 기간에 관한 자세한 내용은 B.7 유효 기간절을 참조하십시오. 이 사양은 refreshService 속성을 정의합니다. 이 속성을 사용하면 발급자가 갱신 서비스의 링크를 포함할 수 있습니다.

발급자는 갱신 서비스를 검증 가능한 자격 증명 안에 요소로 포함할 수 있습니다. 이 방식은 검증자 또는 보유자(또는 둘 다)를 위한 경우에 사용합니다. 또는 갱신 서비스를 검증 가능한 프레젠테이션 안에 포함할 수도 있는데, 이 방식은 보유자만을 위한 경우에 사용합니다. 후자의 경우 보유자는 검증 가능한 자격 증명을 갱신한 다음 검증 가능한 프레젠테이션을 만들어 검증자와 공유할 수 있습니다. 전자의 경우 갱신 서비스를 검증 가능한 자격 증명 안에 포함하면 보유자 또는 검증자가 나중에 자격 증명을 업데이트할 수 있습니다.

갱신 서비스는 자격 증명이 만료되었거나 발급자가 자격 증명 상태 정보를 게시하지 않을 때만 사용될 것으로 예상됩니다. 발급자는 refreshService 속성을 공개 정보가 포함되지 않았거나 갱신 서비스가 어떤 방식으로도 보호되지 않은 검증 가능한 자격 증명에는 넣지 않는 것이 좋습니다.

refreshService: refreshService 속성의 값은 MUST 수신자의 소프트웨어가 검증 가능한 자격 증명을 갱신할 수 있을 만큼 충분한 정보를 제공하는 하나 이상의 갱신 서비스여야 합니다. 각 refreshService 값은 MUST 자체 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"
  }
}

위 예제에서 발급자는 자동 refreshService를 지정합니다. 이 서비스는 검증 가능한 자격 증명을 갱신 서비스의 url로 POST하여 사용할 수 있습니다. 이 특정 검증 가능한 자격 증명은 원래 발급자 이외의 누구와도 공유하기 위한 것이 아닙니다.

참고: 인증되지 않은 자격 증명 갱신

refreshService 속성을 검증 가능한 자격 증명에 넣어 검증자가 이용할 수 있게 하면 보유자에게서 통제권과 동의를 박탈하고, 검증 가능한 자격 증명을 검증자에게 직접 발급할 수 있게 되어, 보유자를 우회할 수 있습니다.

이용 약관은 발급자 또는 보유자가 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션이 발급된 조건을 전달하는 데 사용할 수 있습니다. 발급자는 자신의 이용 약관을 검증 가능한 자격 증명 안에 넣습니다. 보유자는 자신의 이용 약관을 검증 가능한 프레젠테이션 안에 넣습니다. 이 사양은 이용 약관 정보를 표현하기 위한 termsOfUse 속성을 정의합니다.

termsOfUse 속성의 값은 다른 정보와 함께 다음 중 일부 또는 전부를 검증자에게 알리는 데 사용할 수 있습니다.

검증 가능한 자격 증명을 발급할 때 사용한 절차 또는 정책입니다. 예를 들어 이러한 절차나 정책을 찾을 수 있는 공개 위치의 포인터 ("발급처로 자동 연락"하는 데 따른 개인 정보 보호 문제를 방지하기 위함) 또는 이를 정의하는 표준의 이름을 제공할 수 있습니다.
발급자가 이 검증 가능한 자격 증명을 검증자에게 제시할 때 적용하는 규칙과 정책입니다. 예를 들어 이러한 규칙이나 정책을 찾을 수 있는 공개 위치의 포인터("발급처로 자동 연락"하는 데 따른 개인 정보 보호 문제를 방지하기 위함)를 제공할 수 있습니다.
발급자가 이 특정 검증 가능한 자격 증명을 발급하도록 권한을 부여한 엔터티의 신원입니다.

termsOfUse: termsOfUse 속성의 값은 MUST 작성자가 자격 증명 또는 프레젠테이션을 발급할 때 적용한 하나 이상의 이용 약관 정책을 지정해야 합니다. 수신자(보유자 또는 검증자)가 지정된 이용 약관을 준수할 의사가 없다면, 그에 따른 책임은 수신자 자신에게 있으며 명시된 이용 약관을 위반할 경우 법적 책임을 질 수 있습니다. 각 termsOfUse 값은 MUST 자체 유형(예: TrustFrameworkPolicy)을 지정해야 하며, MAY 인스턴스 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"를 법적 근거로 발급되었으며, 해당 정책으로 연결되는 구체적인 링크가 있다고 주장합니다.

이 기능은 정부가 발급한 검증 가능한 자격 증명에서 디지털 지갑에 해당 자격 증명의 사용을 유사한 정부 기관으로 제한하도록 지시하여, 민감한 데이터가 예상치 못하게 사용되는 일로부터 시민을 보호하는 데 활용될 것으로 예상됩니다. 마찬가지로 민간 부문이 발급한 일부 검증 가능한 자격 증명은 그 사용이 조직 내부 부서 또는 업무 시간으로만 제한될 것으로 예상됩니다. 구현자는 검증 가능한 자격 증명 구현 지침 [VC-IMP-GUIDE] 문서의 관련 절에서 발전 중인 이 기능을 자세히 살펴보는 것이 좋습니다.

발급자는 검증자에게 추가적인 뒷받침 정보를 제공하기 위해 검증 가능한 자격 증명에 증거를 포함할 수 있습니다. 검증자는 이를 사용해 검증 가능한 자격 증명의 주장을 어느 정도 신뢰할 수 있는지 판단할 수 있습니다. 예를 들어 발급자는 주체가 제공한 실물 문서를 확인하거나 자격 증명을 발급하기 전에 일련의 신원 조사를 수행할 수 있습니다. 특정 상황에서는 이 정보가 검증자가 특정 자격 증명을 신뢰할 때의 위험을 판단하는 데 유용합니다.

이 사양은 증거 정보를 표현하기 위한 evidence 속성을 정의합니다.

evidence

evidence 속성이 있으면 그 값은 MUST 단일 객체 또는 하나 이상의 객체 집합이어야 합니다. 모든 증거 객체에는 다음 속성이 정의됩니다.

id: id 속성은 OPTIONAL입니다. 이 속성은 증거 객체에 고유 식별자를 제공하기 위해 MAY 사용될 수 있습니다. 이 속성이 있으면 4.4 식별자절의 규범적 지침을 MUST 따라야 합니다.
type: type 속성은 REQUIRED입니다. 객체가 표현하는 증거 정보의 유형을 나타내는 데 사용합니다. 관련 규범적 지침은 다음 4.5 유형절에 있으며 이를 MUST 따라야 합니다.

참고: 증거 제공 전략은 구현 가이드를 참조하십시오

이 사양이 첨부 파일, 자격 증명 참조 및 자격 증명이 아닌 데이터의 참조를 지원할 수 있는 방법은 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
      "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 보호 메커니즘절을 참조하십시오.

영지식 증명은 보호 메커니즘으로, 보유자가 실제 값을 공개하지 않고도 특정 값이 포함된 검증 가능한 자격 증명을 보유하고 있음을 증명할 수 있게 합니다. 예를 들어 생년월일을 공개하지 않고도 개인이 25세를 초과했음을 증명할 수 있습니다. 이 데이터 모델은 영지식 증명을 사용한 보호를 지원합니다.

영지식 증명 메커니즘으로 구현할 수 있으며 검증 가능한 자격 증명과 호환되는 기능에는 다음이 포함됩니다.

선택적 공개: 검증 가능한 자격 증명의 속성을 보유자가 검증자에게 선택적으로 공개합니다. 이를 통해 보유자는 검증자에게 필요한 정보만 정확히 제공할 수 있습니다. 또한 파생 검증 가능한 자격 증명을 검증자의 데이터 스키마에 맞는 형식으로 생성할 수 있으며, 제시 과정에서 발급자가 관여할 필요도 없습니다. 이 기능은 보유자가 발급받은 검증 가능한 자격 증명을 매우 유연하게 사용할 수 있게 합니다.
연결 불가능한 공개: 검증 가능한 자격 증명의 속성을 보유자가 검증자에게 공개합니다. 블라인드 서명은 연결 불가능한 공개를 가능하게 하며, 여러 차례 제시할 때 발생하는 보유자 상관관계의 일반적인 원인을 제거합니다. 이러한 제시는 하나 이상의 검증자에게 이루어질 수 있습니다. 이를 통해 보유자는 제시할 때마다 서로 다른 서명 값을 공유할 수 있으며, 그 결과 공유되는 데이터의 양이 줄어듭니다.
보유자 및/또는 주체를 상관관계 분석이 불가능한 방식으로 식별합니다. 이를 통해 보유자는 자격 증명이 자신에게 발급되었음을 증명하거나, 주체는 자격 증명이 자신에 관해 발급되었음을 상관관계 분석이 가능한 식별자를 공유하지 않고 증명할 수 있습니다. 이 기능은 공유해야 하는 데이터의 양도 줄여 줍니다. 또한 여러 검증 가능한 자격 증명을 여러 발급자로부터 받아 하나의 검증 가능한 프레젠테이션으로 결합하면서도 검증 가능한 자격 증명 또는 주체의 식별자를 검증자에게 공개하지 않을 수 있습니다.

보호 메커니즘을 만드는 사양 작성자는 MUST NOT 정보가 유출되어 검증자가 보유자를 여러 검증 가능한 프레젠테이션이 서로 다른 검증자에게 제시될 때에도 상관관계로 연결할 수 있게 하는 방식으로 메커니즘을 설계해서는 안 됩니다.

모든 영지식 증명 메커니즘이 모든 기능을 지원하는 것은 아닙니다. 특정 영지식 증명 메커니즘이 제공하는 기능과 기법의 구체적인 내용 및 이를 검증 가능한 자격 증명과 함께 사용할 때의 규범적 요구 사항은 해당 영지식 증명 메커니즘으로 검증 가능한 자격 증명을 보호하는 사양에서 확인할 수 있습니다. 이러한 사양의 예는 데이터 무결성 BBS 암호 스위트 v1.0을 참조하십시오.

대부분의 경우 보유자가 영지식 메커니즘을 검증 가능한 자격 증명과 함께 사용하려면 발급자가 검증 가능한 자격 증명을 이러한 기능을 지원하는 방식으로 보호해야 합니다.

아래 그림은 이 데이터 모델을 사용하여 영지식 방식으로 검증 가능한 자격 증명을 발급하고 제시하는 방법을 보여 줍니다.

왼쪽의 검증 가능한
자격 증명 1과 검증 가능한 자격 증명 2가 오른쪽 프레젠테이션 안의
파생 자격 증명 1과 파생 자격 증명 2에 대응합니다. 검증 가능한 자격 증명 1에는
컨텍스트, 유형, ID, 발급자, 발급일, 만료일, 자격 증명 주체 및 증명이 포함됩니다.
자격 증명 주체에는 이름, 성 및 생년월일이 포함되고, 증명에는 서명,
정확성 증명 및 속성이 포함됩니다. 검증 가능한 자격 증명 2에는
컨텍스트, 유형, ID, 발급자, 발급일, 만료일, 자격 증명 주체 및 증명이 포함됩니다.
자격 증명 주체에는 대학이 포함되고, 대학에는 학과가, 학과에는 수여 학위가 포함됩니다.
증명에는 서명, 정확성 증명 및 속성이 포함됩니다. 오른쪽 프레젠테이션 그림에는
컨텍스트, 유형, ID, 검증 가능한 자격 증명 및 증명이 포함됩니다.
검증 가능한 자격 증명에는 파생 자격 증명 1과 파생 자격 증명 2가 포함되고,
증명에는 공통 링크 비밀값이 포함됩니다. 파생 자격 증명 1에는 컨텍스트, 유형, ID,
발급자, 발급일, 자격 증명 주체 및 증명이 포함됩니다. 자격 증명 주체에는 18세 이상이 포함되고,
증명에는 서명 지식이 포함됩니다. 파생 자격 증명 2에는 컨텍스트, 유형, ID,
발급자, 발급일, 자격 증명 주체 및 증명이 포함됩니다. 자격 증명 주체에는 학위가 포함되고,
증명에는 서명 지식이 포함됩니다. 한 선은 검증 가능한 자격 증명 1의 생년월일을
파생 자격 증명 1의 18세 이상과 연결합니다. 다른 선은 검증 가능한 자격 증명 2의 수여 학위를
파생 자격 증명 2의 학위와 연결합니다. — 그림 12 ZKP 프레젠테이션에서 자격 증명과 파생 자격 증명 사이의 관계를 보여 주는 시각적 예.

다음은 검증 가능한 자격 증명과 검증 가능한 프레젠테이션의 예로, 데이터 무결성 BBS 암호 스위트 v1.0의 연결 불가능한 선택적 공개 보호 메커니즘을 사용합니다.

예제 30: 기본 증명이 포함된 데이터 무결성 BBS 암호 스위트를 사용하는 검증 가능한 자격 증명

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:web:utopia.example",
    "image": "data:image/png;base64,iVBORw0KGg...VORK5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgo...g==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": [
        "PermanentResidentCard"
      ],
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2026-09-05T00:00:00Z",
  "validUntil": "2027-09-05T23:59:59Z",
  "proof": [
    {
      "type": "DataIntegrityProof",
      "created": "2026-09-05T17:21:31Z",
      "verificationMethod": "did:web:utopia.example#zDnae...QGW8",
      "cryptosuite": "ecdsa-rdfc-2019",
      "proofPurpose": "assertionMethod",
      "proofValue": "z4fJttfr...kn9P"
    },
    {
      "type": "DataIntegrityProof",
      "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
      "cryptosuite": "bbs-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0ChVhQiJsvokWSE4Cq999Bw9aluhWuToMG7qGNtAx5I2_LmNjRPCMcTLoiBc_HV8gjvgvSNnrFNK50Ubf1gIN8i8sHUWwUzqdDMevqlO8qVOWgki1YQM6iv5KVLQKPLTMEAHhSEWyz3z3hrSSQJTjO8vIFJgMWaLnxEOgYUkAwn3mL9Hhr-t6oc0OXaYjMBPYyPIQUnwdYYKipusluRJ7SzUrZmv4RxeebXFP1W0GGgnhEIBufF7eulvisZDSTSVWCkn1KMnStOgmhPPjOCIDvXVY2Xxbm61KFgc2pSZJwhV5kLxZV9igRbX8uzqgdbnLyerjY7DzJdVggryiDkfzraDE3VOas9Ls5wKk4oBfAtvO0QZikpLOL1VeBZy9pc3N1ZXI"
     
    }
  ]
}

위 예제는 검증 가능한 자격 증명입니다. 여기서 발급자는 BBS 기반 연결 불가능 공개 방식을 활성화하여 기본 증명을 만들었습니다. 보유자는 이 기본 증명을 사용하여 원본 검증 가능한 자격 증명의 특정 정보만 공개하는 파생 증명을 만들 수 있습니다.

예제 31: 파생 자격 증명과 증명이 포함된 데이터 무결성 BBS 암호 스위트를 사용하는 검증 가능한 프레젠테이션

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://w3id.org/citizenship/v4rc1"
      ],
      "type": [
        "VerifiableCredential",
        "PermanentResidentCardCredential"
      ],
      "issuer": {
        "id": "did:web:vcplayground.org",
        "image": "data:image/png;base64,iVBORw0KG...YII="
      },
      "credentialSubject": {
        "type": [
          "PermanentResident",
          "Person"
        ],
        "birthCountry": "Arcadia"
      },
      "proof": [
        {
          "type": "DataIntegrityProof",
          "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
          "cryptosuite": "bbs-2023",
          "proofPurpose": "assertionMethod",
          "proofValue": "u2V0DhVkDEJOplpVKV9UBPos-YnSuy7u-_wuxUUcElOCVqJwekpfS8pDYv5mlIiADqJNm62CgfJMG1SeBV9Ri5DlmMAOaWayl51Aqc_fPn1V756d-P51JNwmlPQ9RmyYQPGfk3_8z0KF57H_seUFGZOYAtul85f9rypgN_emBvVApxUSMClqvNSgNVQ_sqVS1ICFkz9MIuTv6Ng6F8CNm0svtv1Tnkmjn6I4bgP0b46j57-lgiAP6Xb72RCnppHyfcuc6z9NB82BgIPCHzu2V3u8sWHyPS1JzVDLUiPVWUy6Oar0A4q9QLP4y92Q4JpJRx0Bl-x3cvCcBZp8ESDphMEDoMgEBqWVdWEZ_KQa2JrYuiWeHfK81WPNlJimOp4xl4CotHqx1NIinSB7jmrtcQ-0dIX_vz5wnYwhlP44rE7TgydrFE_16BYk0hkfKJw8sGCQNxqcUMHGh262ZOie2ASifU8OXd5TZOgTaUXRauwCrAPQZnQKnAQ8j8hBLgD_0Ujzt2Yk6dQueUv493jnmWJMnCbAy33MuRhHSqSxHVJBXOhhUX3s79HY0V-uLkGOZw_61HRpAi0W4spLv77ehUlwW5N35VFbs_THFXGA5AgY3Cg1vY-K5SyqpH5BlWhAcTRwoDKboqp0tOecM5qpZyuAORQ7fK2JddnEMHmvOKW7x_ugykAbQm6DeqhyGPtKxuiSulr-IHFK-KyGCXPAAKbk7X5Hkf29q7tOEGTIU4_9ga88PtiQKJTu7Ao8ABBEg9Gqt-KcfqfPgt8cqwxGtjW21sD3bSbtUiWNQO3ZDPelP9ToXbduEPpsNEYwxRbMtS5SF6YDqy16Bo8uyw41jnKvb-E5ABF-2MGjxB9zt8ZH_TJirGP_IMt0ssYrODZAlJbakLKiD5NH3g-xlvMTHxrD8VEzJakACnJIrm3X9J7MjUM_YTqth99oc2Yq2HLlgwYb1hD3T6jsIaY8zRPzA2ybKdXxZ3ahxyc_nbLDnP2fVNbUj8P9EX2Av_GvmnSYRsE5Wmcblhao6Ref1EF8YFF6JFT8SO2WiAAIBAIQABAUHhAABBxFYRXsiY2hhbGxlbmdlIjoiejFBREtDNVFBdW1Tb1Jud1NDSHRhUXBvQSIsImRvbWFpbiI6InZjcGxheWdyb3VuZC5vcmcifQ"
          
        }
      ]
    }
  ]
}

위 검증 가능한 프레젠테이션에는 앞선 예제 정보의 연결 불가능한 하위 집합과 파생 증명을 담은 검증 가능한 자격 증명이 포함되어 있습니다. 검증자는 파생 증명을 사용하여 정보가 예상한 발급자에게서 비롯되었고 이 특정 정보 교환에 바인딩되어 있음을 확인할 수 있습니다.

구현자는 시간 값을 표현하고 처리하는 일이 겉보기만큼 간단하지 않으며, 세계 각 지역에서 즉시 알아차리기 어렵거나 일관되게 적용되지 않는 다양한 특이 사항이 있음을 이해하는 것이 좋습니다. 예를 들면 다음과 같습니다.

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

이는 벽시계에 표시되는 실제 시각이 한 지역에는 존재하지만 다른 지역에는 존재하지 않을 수도 있음을 보여 주는 몇 가지 예에 불과합니다. 따라서 구현자는 일광 절약 시간제(서머타임)의 영향을 받는 값보다 Z 시간대에 고정된 값과 같이 더 보편적인 시간 값을 사용하는 것이 좋습니다.

이 사양은 dateTimeStamp 구문을 사용하여 보편적으로 인식되는 날짜와 시간 조합을 늘리고, 시간 값이 잘못 해석될 가능성을 줄이고자 합니다. 이 구문은 [XMLSCHEMA11-2] 사양에서 처음 정립했습니다. 서로 다른 시간대 사이의 오해를 줄이기 위해 적합 문서에 표현된 모든 시간 값은 SHOULD dateTimeStamp 형식으로 지정해야 합니다. 값 끝에 Z로 표시하는 협정 세계시(UTC)나 UTC 기준 시간대 오프셋을 사용할 수 있습니다. 오프셋 없이 잘못 직렬화된 시간 값은 MUST 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 스키마 1.1 제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))

이 절은 비규범적입니다.

검증 가능한 자격 증명은 주체를 신뢰할 수 있게 식별하기 위한 수단입니다. 역할 기반 액세스 제어(RBAC)와 속성 기반 액세스 제어(ABAC)가 이러한 식별을 바탕으로 주체에게 리소스 액세스 권한을 부여한다는 점은 인정하지만, 이 사양은 RBAC 또는 ABAC를 위한 완전한 솔루션을 제공하지 않습니다. 함께 사용할 권한 부여 프레임워크가 없다면 권한 부여는 이 사양의 적절한 사용 사례가 아닙니다.

작업 그룹은 이 사양을 작성할 때 권한 부여 사용 사례를 고려했으며, 이 사양 위에 구축하는 아키텍처 계층으로 해당 작업을 추진하고 있습니다.

이 사양은 잠재적인 확장 지점으로 사용할 여러 속성을 예약합니다. 일부 구현자가 이러한 속성에 관심을 나타냈지만, 이 사양에 포함하기에는 이르다고 판단했습니다. 이러한 속성은 어느 것도 이 사양에서 정의하지 않는다는 점이 중요합니다. 따라서 구현자는 이러한 속성의 사용이 실험적인 것으로 간주된다는 점에 유의해야 합니다.

구현자는 이러한 속성을 MAY 사용할 수 있지만, 규범적으로 명세하는 과정에서 속성 및/또는 그 의미가 변경될 수 있음을 SHOULD 예상해야 합니다. 구현자는 구현 방식을 설명하는 공개 사양 없이 이러한 속성을 SHOULD NOT 사용해서는 안 됩니다.

다음 속성의 사용 방식이 충돌하지 않도록 구현은 예약된 속성과 연결된 값에 MUST type 속성을 지정해야 합니다. type 정보 추가에 관한 자세한 내용은 4.5 유형절을 참조하십시오.

예약된 속성 설명

confidenceMethod 검증자가 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션 내부나 그 자체의 속성 값이 정확하다는 신뢰도를 높이는 데 사용할 수 있는 하나 이상의 방법을 지정하는 속성입니다. 연결된 어휘 URL은 MUST https://www.w3.org/2018/credentials#confidenceMethod이어야 합니다. 사용 예를 포함하여 신뢰도 방법에 관해 자세히 알아보려는 구현자는 검증 가능한 자격 증명 신뢰도 방법 v1.0 사양을 참조할 수 있습니다.

renderMethod 자격 증명을 시각적, 청각적, 촉각적 또는 기타 형식으로 렌더링하는 하나 이상의 방법을 지정하는 속성입니다. 연결된 어휘 URL은 MUST https://www.w3.org/2018/credentials#renderMethod이어야 합니다. 사용 예를 포함하여 렌더링 방법에 관해 자세히 알아보려는 구현자는 검증 가능한 자격 증명 렌더링 방법 v1.0 사양을 참조할 수 있습니다.

예약된 속성	설명
`confidenceMethod`	검증자가 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션 내부나 그 자체의 속성 값이 정확하다는 신뢰도를 높이는 데 사용할 수 있는 하나 이상의 방법을 지정하는 속성입니다. 연결된 어휘 URL은 MUST `https://www.w3.org/2018/credentials#confidenceMethod`이어야 합니다. 사용 예를 포함하여 신뢰도 방법에 관해 자세히 알아보려는 구현자는 검증 가능한 자격 증명 신뢰도 방법 v1.0 사양을 참조할 수 있습니다.
`renderMethod`	자격 증명을 시각적, 청각적, 촉각적 또는 기타 형식으로 렌더링하는 하나 이상의 방법을 지정하는 속성입니다. 연결된 어휘 URL은 MUST `https://www.w3.org/2018/credentials#renderMethod`이어야 합니다. 사용 예를 포함하여 렌더링 방법에 관해 자세히 알아보려는 구현자는 검증 가능한 자격 증명 렌더링 방법 v1.0 사양을 참조할 수 있습니다.

이 사양에서 정의한 확장 지점 및 이 절에서 정의한 예약된 확장 지점과 관련된 사양의 비공식 목록은 검증 가능한 자격 증명 확장에서 확인할 수 있습니다. 디렉터리에서 예약된 확장 지점을 참조하는 항목은 SHOULD 실험적인 것으로 취급해야 합니다.

이 문서에서 제공하는 데이터 모델을 기본적으로 사용하지 않지만, 이 사양의 여러 개념과 부합하는 디지털 자격 증명 형식이 다수 있습니다. 이 문서가 발행된 시점에 이러한 디지털 자격 증명 형식의 예로는 JSON 웹 토큰(JWT), CBOR 웹 토큰(CWT), JSON 고급 전자 서명(JAdES), ISO-18013-5:2021 (mDL), AnonCreds, 고르디언 엔벌로프 및 인증된 연쇄 데이터 컨테이너(ACDC)가 있습니다.

개념적으로 부합하는 디지털 자격 증명 형식을 이 절의 규칙에 따라 적합 문서로 변환할 수 있으면 해당 형식은 "W3C 검증 가능한 자격 증명 생태계와 호환됨"으로 간주합니다. 사양 작성자는 검증 가능한 자격 증명 생태계와의 호환성을 지원하는 변환을 문서화할 때 다음 규칙을 따르는 것이 좋습니다. 변환 사양은 —

이 데이터 모델로의 변환이 단방향 전용인지 왕복 변환 가능한지 MUST 명시해야 합니다.
MUST 왕복 변환을 수행할 때 @context 값을 보존해야 합니다.
이 사양에서 설명하는 데이터 모델로 변환할 때 결과가 MUST 적합 문서여야 합니다.
입력 문서에 등록된 미디어 유형을 MUST 지정해야 합니다.
SHOULD 이 사양의 데이터 모델로 변환하는 명시된 알고리즘의 결과가 적합 문서임을 입증하는 테스트 모음을 제공해야 합니다.
SHOULD 변환된 적합 문서에서 사용하는 모든 의미론이 연결 데이터 모범 사례를 따르도록 해야 합니다. 자세한 지침은 4.1 시작하기절, 5.2 확장성절 및 연결 데이터 모범 사례 [LD-BP]를 참조하십시오.

참고: 검증 가능한 자격 증명의 요건은 무엇입니까?

디지털 자격 증명은 W3C 검증 가능한 자격 증명 생태계와 호환되는 것으로 간주되려면 적합 문서이면서 이 사양의 해당 요구 사항에서 설명한 보호 메커니즘을 하나 이상 사용해야 한다는 점에 유의하십시오. 일부 커뮤니티에서는 적합 문서가 아닌 일부 디지털 자격 증명 형식을 "검증 가능한 자격 증명"이라고 부를 수 있지만, 그렇게 부른다고 해서 해당 디지털 자격 증명이 이 사양을 준수하는 것은 아닙니다. 예를 들어 SD-JWT-VC [SD-JWT-VC] 사양은 이름에 "VC"라는 글자를 사용하지만 W3C 검증 가능한 자격 증명과 호환되지 않는다고 명시적으로 밝힙니다.

검증 가능한 자격 증명을 표현할 때(예: 프레젠테이션) 한 검증 가능한 자격 증명의 데이터를 다른 검증 가능한 자격 증명의 동일한 데이터로 오인하지 않도록 해야 합니다. 예를 들어 다음 형식의 객체를 각각 포함하는 두 검증 가능한 자격 증명이 있다고 가정합니다: {"type": "Person", "name": "Jane Doe"}. 한 객체가 다른 객체와 동일한 사람을 설명하는지는 알 수 없습니다. 즉, 두 검증 가능한 자격 증명이 동일한 엔터티 및/또는 속성을 다루는지 확인하지 않고 데이터를 병합하면 데이터 집합이 손상될 수 있습니다.

서로 다른 검증 가능한 자격 증명의 데이터가 실수로 뒤섞이지 않도록 검증 가능한 자격 증명 그래프라는 개념을 사용하여 각 검증 가능한 자격 증명을 캡슐화합니다. 단순한 검증 가능한 자격 증명, 즉 JSON-LD 문서에 하나의 자격 증명과 그에 연결된 증명이 포함될 수 있는 경우 이 그래프는 기본 그래프입니다. 프레젠테이션의 경우 각 verifiableCredential 속성 값은 프레젠테이션 내부에서 별도의 명명된 그래프로 분리되며, 그 유형은 VerifiableCredentialGraph 입니다. 이 그래프에는 하나의 검증 가능한 자격 증명 또는 봉투형 검증 가능한 자격 증명이 포함됩니다.

이러한 그래프는 JSON-LD 처리 시 한 그래프의 그래프 노드 식별자를 다른 그래프의 식별자와 올바르게 분리하는 구체적인 효과가 있습니다. 입력을 애플리케이션별 JSON-LD 문서로 제한하는 구현도 한 검증 가능한 자격 증명의 데이터를 다른 자격 증명의 데이터와 병합할 때 이 점을 고려해야 합니다. 예를 들어 credentialSubject.id가 두 검증 가능한 자격 증명에서 같더라도, 객체에는 앞 단락에서 설명한 "Jane Doe" 형식의 객체가 포함될 수 있습니다. 비슷한 속성을 가진 것처럼 보이지만 URL과 같은 전역 식별자를 사용하는 id 속성이 없는 객체는 병합하지 않는 것이 중요합니다.

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

보호 메커니즘 사양은 MUST 적합 문서의 콘텐츠 무결성을 보호하는 규범적 알고리즘을 문서화해야 합니다. 이 알고리즘은 MAY 일반적인 성격을 지닐 수 있으며, MAY 적합 문서 이외의 데이터를 보호하는 데 사용할 수 있습니다.

보호 메커니즘 사양은 MUST 보호된 적합 문서의 정보를 독립적으로 반환하는 검증 알고리즘을 제공해야 합니다. 반환 정보에는 proof, JOSE/COSE 헤더 매개변수 및 서명과 같은 보호 메커니즘 정보가 포함되지 않아야 합니다. 검증 알고리즘은 MAY 보호 메커니즘의 세부 정보처럼 유효성 검사나 디버깅 등에 유용한 추가 정보를 반환할 수 있습니다. 검증 알고리즘은 MUST 미디어 유형(문자열 inputMediaType)과 입력 데이터(바이트 시퀀스 또는 맵 inputData)를 받는 인터페이스를 제공해야 합니다. 보호 메커니즘 사양은 MAY 이 문서에서 지정한 것 이외의 알고리즘과 인터페이스를 제공할 수 있습니다. 검증 알고리즘은 최소한 다음 항목을 포함하는 검증 결과를 반환합니다.

불리언 verified: 검증 성공 시 값이 true이고, 실패 시 false인 검증 상태입니다.
맵 verifiedDocument: 성공적으로 보호된 정보만 포함하는 문서입니다.
문자열 mediaType: [RFC6838]에서 정의한 미디어 유형입니다.

보호 메커니즘 사양은 유효성 검사에 중요한, URL로 참조되는 모든 정보에 대해 SHOULD 무결성 보호를 제공해야 합니다. 이러한 보호를 구현할 수 있는 메커니즘은 5.3 관련 리소스의 무결성절과 C.1 기본 컨텍스트절에서 설명합니다.

새로운 유형의 내장 증명을 만드는 보호 메커니즘 사양은 MUST 속성을 지정해야 합니다. 이 속성은 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 증명 그래프와 연결합니다. 보호 메커니즘의 요구 사항은 다음과 같습니다.

보호 메커니즘은 MUST 증명 그래프에서 사용하는 모든 용어를 정의해야 합니다. 예를 들어 이 사양에서 사용하는 방식과 동일하게 어휘 사양과 @context 파일을 정의할 수 있습니다.
보호 메커니즘은 MUST 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 모든 그래프를 보호해야 합니다. 다만 증명 그래프 중 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션 자체를 보호하는 그래프는 제외합니다.

참고

마지막 요구 사항은 보호 메커니즘이 기본 그래프를 보호하고, 검증 가능한 프레젠테이션의 경우 프레젠테이션에 포함된 각 검증 가능한 자격 증명을 해당 증명 그래프와 함께 보호한다는 뜻입니다. 그림 9 또는 그림 14도 참조하십시오.

proof 속성은 [VC-DATA-INTEGRITY]에서 정의한 것이며, 내장 보호 메커니즘에서 MAY 사용할 수 있습니다.

보호 메커니즘 사양은 SHOULD 해당 보호 메커니즘을 보호 메커니즘절에 등록해야 합니다. 이 절은 검증 가능한 자격 증명 확장 문서에 있습니다.

참고: 보호 메커니즘 선택은 사용 사례에 따라 달라집니다

허용되는 보호 메커니즘은 여러 가지이며, 이 사양은 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션과 함께 사용할 특정 보호 메커니즘을 의무화하지 않습니다. 이 사양을 작성한 작업 그룹은 다음 두 가지 보호 메커니즘을 표준화했습니다. 검증 가능한 자격 증명 데이터 무결성 1.0 [VC-DATA-INTEGRITY] 및 JOSE 및 COSE를 사용한 검증 가능한 자격 증명 보호 [VC-JOSE-COSE]. 커뮤니티에 알려진 다른 보호 메커니즘은 보호 메커니즘절, 즉 검증 가능한 자격 증명 확장 문서에서 확인할 수 있습니다.

3. 핵심 데이터 모델절, 4. 기본 개념절 및 5. 고급 개념절에서 설명한 데이터 모델은 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 정규 구조 표현입니다. 모든 구문은 해당 데이터 모델을 특정 형식으로 표현한 것입니다. 이 절에서는 application/vc와 application/vp를 위해 데이터 모델을 JSON-LD로 직렬화하는 방법을 지정합니다. 이들은 각각 검증 가능한 자격 증명과 검증 가능한 프레젠테이션의 기본 미디어 유형입니다. 구문 매핑은 JSON-LD에 대해서만 제공되지만, 애플리케이션과 서비스는 application/vc 또는 application/vp로 다시 매핑할 수 있는 다른 모든 데이터 표현 구문(예: XML, YAML 또는 CBOR)을 사용할 수 있습니다. 검증 및 유효성 검사 요구 사항은 데이터 모델을 기준으로 정의되므로, 모든 직렬화 구문은 처리, 유효성 검사 또는 비교를 위해 결정론적으로 데이터 모델로 변환되어야 합니다.

이 사양에서 속성 값의 예상 개수와 그 값을 담는 결과 데이터 유형은 속성에 따라 달라질 수 있습니다. 다음 속성이 존재하는 경우 단일 값으로 표현됩니다. id (4.4 식별자절), issuer(4.7 발급자절) 및 validFrom/validUntil(4.9 유효 기간절). 그 밖의 모든 속성은 존재하는 경우 단일 값 또는 값의 배열로 표현됩니다.

이 사양에서는 이 사양에 설명된 데이터 모델을 직렬화하기 위해 JSON-LD 1.1을 사용합니다. JSON-LD는 그래프 기반 데이터 모델을 표현할 수 있게 하므로 유용합니다. 이 모델은 검증 가능한 자격 증명의 기반이며, JSON-LD는 기계 판독 가능한 의미론도 표현할 수 있습니다. 또한 데이터 모델을 확장할 때도 유용합니다(3. 핵심 데이터 모델절 및 5.2 확장성절 참조).

JSON-LD는 연결 데이터를 직렬화하는 데 사용되는 JSON 기반 형식입니다. 연결 데이터는 리소스 기술 프레임워크(RDF) [RDF11-CONCEPTS]를 사용하여 모델링됩니다. RDF는 진술의 그래프를 모델링하는 기술입니다. 각 진술은 하나의 주체→속성→값(엔터티→특성→값이라고도 함) 관계이며, 이 사양에서는 이를 주장이라고 합니다. JSON-LD는 관용적인 JSON을 사용하여 RDF를 표현할 수 있게 하는 기술이므로, JSON에 익숙한 개발자는 RDF를 JSON으로 처리하는 애플리케이션을 작성할 수 있습니다. 자세한 내용은 JSON-LD와 RDF의 관계를 참조하십시오.

일반적으로 이 문서에서 설명하는 데이터 모델과 구문을 사용하면 개발자는 검증 가능한 자격 증명을 대체로 JSON 문서처럼 다룰 수 있으며, 예제를 조금만 수정하여 자신의 소프트웨어 시스템에 복사해 붙여 넣을 수 있습니다. 이 접근 방식의 설계 목표는 진입 장벽을 낮추면서도 서로 다른 소프트웨어 시스템 사이의 전역 상호 운용성을 보장하는 것입니다. 이 절에서는 이를 가능하게 하는 데 사용되는 몇 가지 JSON-LD 기능을 설명합니다. 대부분의 개발자는 이러한 기능을 알아차리지 못할 가능성이 크지만, 구현자는 세부 사항에 관심을 가질 수 있습니다. 이 사양에서 사용하는 JSON-LD 1.1의 주요 기능은 다음과 같습니다.

@id 및 @type 키워드에는 각각 id와 type이라는 별칭이 지정되어 있으므로, 개발자는 이 사양을 관용적인 JSON으로 사용할 수 있습니다.
정수, 날짜, 측정 단위, URL 등의 데이터 유형에는 유형이 자동으로 지정되어, 이를 필요로 하는 사용 사례에 더 강력한 유형 보장을 제공합니다.
verifiableCredential 속성은 JSON-LD 1.1 그래프 컨테이너로 정의됩니다. 이를 위해 서로 다른 엔터티가 주장한 데이터 집합을 분리하는 데 사용되는 명명된 그래프를 만들어야 합니다. 예를 들어 이를 통해 각 발급자가 제공한 데이터 그래프와 보유자가 검증 가능한 자격 증명을 제시하면서 제공한 데이터 그래프를 암호학적으로 올바르게 분리하여, 각 그래프에 있는 정보의 출처가 보존되도록 합니다.
@protected 속성 기능은 JSON-LD 1.1에서 이 사양에 정의된 용어를 재정의할 수 없도록 하는 데 사용됩니다. 즉, 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 맨 위에 동일한 @context 선언이 있는 한, 데이터 모델 사용자가 이해하는 모든 용어의 상호 운용성이 JSON-LD 1.1 프로세서 사용 여부와 관계없이 보장됩니다.

상호 운용성을 높이기 위해 이 사양은 데이터 모델의 JSON-LD 표현 사용을 제한합니다. JSON-LD 압축 문서 형식은 MUST application/vc 또는 application/vp 미디어 유형을 사용하는 데이터 모델의 모든 표현에 사용해야 합니다.

6.3 유형별 자격 증명 처리절에서 자세히 설명하듯이, 일부 소프트웨어 애플리케이션은 일반적인 JSON-LD 처리를 수행하지 않을 수 있습니다. 적합 문서 작성자는 @context 값의 JSON-LD 키워드를 사용하여 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션의 값에 전역적으로 영향을 주는 경우, 예를 들어 @base 또는 @vocab 키워드 중 하나나 둘 다를 설정하면 상호 운용성이 저하될 수 있다는 점에 유의하는 것이 좋습니다. 예를 들어 이러한 값을 설정하면 @context 값에 대한 JSON 스키마 테스트가 잘못 구현된 경우 실패할 수 있습니다. 이는 유형별 자격 증명 처리를 수행하면서 @base 및/또는 @vocab 값이 @context 값에 표현될 것으로 예상하지 않는 구현에서 발생할 수 있습니다.

상호 운용성을 높이기 위해 적합 문서 작성자는 유형별 자격 증명 처리를 수행할 때 쉽게 감지되지 않는 JSON-LD 기능을 사용하지 않는 것이 좋습니다. 이러한 기능은 다음과 같습니다.

문서의 용어 및 값 처리를 전역적으로 변경하는 JSON-LD 키워드를 @context 값에 인라인으로 선언하는 기능(예: @base 또는 @vocab 설정)
@vocab 재설정처럼 이전 컨텍스트의 선언을 재정의하는 JSON-LD 컨텍스트 사용
@context 속성에 JSON-LD 컨텍스트를 인라인으로 선언하는 기능
JSON-LD 용어와 유형에 전체 URL(예: https://www.w3.org/2018/credentials#VerifiableCredential 또는 https://vocab.example/myvocab#SomeNewType)을 이러한 값의 축약형(예: VerifiableCredential 또는 SomeNewType) 대신 사용하는 기능. 이러한 축약형은 JSON-LD @context 매핑(예: https://www.w3.org/ns/credentials/v2)에 명시적으로 정의됩니다.

이 사양에서는 @vocab 사용에 주의를 요구하지만, 실험·개발·지역화된 배포를 쉽게 하는 등 이 기능의 정당한 용도도 있습니다. 애플리케이션 개발자가 프로덕션 환경에서 @vocab을 사용하려는 경우, 용어 충돌을 줄이고 의미론적 상호 운용성의 이점을 활용하려면 사용하지 않는 것이 좋습니다. 또한 @vocab을 사용하면 "정의되지 않은 용어" 오류 보고가 비활성화되고, 이후의 사용이 이전의 모든 @vocab 선언을 재정의한다는 점을 이해해야 합니다. 서로 다른 @vocab 값은 문서에 포함된 정보의 의미론을 바꿀 수 있으므로, 이러한 변경이 개발 중인 애플리케이션에 영향을 주는지, 영향을 준다면 어떤 방식인지 이해하는 것이 중요합니다.

JSON-LD 1.1을 사용하면 목록, 배열, 심지어 목록의 목록도 표현할 수 있습니다. 목록과 배열이 필요한 사용 사례에서 RDF 의미론을 사용하려는 경우 JSON-LD 1.1의 목록에 관한 지침을 따르는 것이 좋습니다.

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

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

유형별 자격 증명 처리를 수행하여 이 데이터 모델을 사용할 수 있지만, 이 방식으로 배열을 사용하는 경우 위 지침을 따르지 않으면 JSON-LD에서 배열 항목의 순서가 보장되지 않는다는 점에 유의해야 합니다. 이로 인해 예상치 못한 동작이 발생할 수 있습니다.

JSON 구조나 순서가 애플리케이션에 중요하다면 해당 요소를 @json으로 표시하는 것이 좋습니다. 이때 사용 사례에 특화된 @context를 사용합니다. 이러한 선언의 예는 아래와 같습니다.

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

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

아래 예제에서 위에 표시한 컨텍스트를 사용하고 https://website.example/matrix/v1 컨텍스트를 @context 속성에 포함하면 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]에서 정의한 미디어 유형은 검증 가능한 자격 증명을 표현하는 데 사용되는 구문과 그 밖의 유용한 처리 지침을 식별합니다.

이 사양의 데이터 모델을 표현하는 데 사용되는 구문은 SHOULD 미디어 유형으로 식별해야 하며, 이 절에서 설명한 규칙도 SHOULD 검증 가능한 자격 증명과 함께 사용할 미디어 유형을 정의하거나 사용할 때는 따라야 합니다.

핵심 데이터 모델과 연결된 미디어 유형은 두 가지이며, D. IANA 고려 사항절에 나열되어 있습니다. 바로 application/vc와 application/vp입니다.

application/vc 및 application/vp 미디어 유형은 특정 보호 메커니즘을 전제로 하지 않지만, 보호 메커니즘과 함께 사용하기 위한 것입니다. 이러한 미디어 유형의 무결성을 보호하려면 보호 메커니즘을 적용해야 합니다. 콘텐츠 전달에 어떤 미디어 유형을 사용하든 콘텐츠가 안전하다고 가정해서는 안 됩니다.

이 절은 비규범적입니다.

개발자나 시스템이 정밀도가 낮은 미디어 유형을 사용하여 검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 전달하는 경우가 있습니다. 정밀도가 낮은 미디어 유형을 사용하는 이유는 다음과 같습니다.

파일 확장자를 사용할 수 없고 미디어 유형을 확인할 수 없으면 웹 서버는 기본적으로 text/plain 또는 application/octet-stream을 사용합니다.
개발자가 파일의 콘텐츠보다 덜 구체적인 미디어 유형으로 이어지는 파일 확장자를 추가합니다. 예를 들어 .json은 application/json 미디어 유형으로 이어질 수 있고, .jsonld는 application/ld+json 미디어 유형으로 이어질 수 있습니다.
특정 트랜잭션에서 프로토콜이 정밀도가 더 낮은 미디어 유형을 요구합니다. 예를 들어 application/json과 같이 application/vp보다 덜 정밀한 유형을 요구할 수 있습니다.

사용된 미디어 유형을 해당 프로토콜에서 허용할 수 있고 페이로드에서 의도한 미디어 유형을 확인할 수 있다면, 구현자는 오류를 발생시키지 않는 것이 좋습니다. 예를 들어 애플리케이션이 application/vc 미디어 유형과 관련된 규칙을 준수하는 페이로드만 허용하지만 페이로드에 application/json 또는 application/ld+json이라는 태그가 대신 지정되어 있다면, 애플리케이션은 해당 페이로드가 정밀도가 더 높은 미디어 유형도 준수하는지 확인하기 위해 다음 단계를 수행할 수 있습니다.

페이로드를 JSON 문서로 구문 분석합니다.
@context 속성의 첫 번째 요소가 https://www.w3.org/ns/credentials/v2와 일치하는지 확인합니다.
application/vp 미디어 유형으로 간주합니다. 이는 JSON 문서에 최상위 type 속성이 있고 그 안에 VerifiablePresentation 요소가 있는 경우입니다. 페이로드가 적합한 검증 가능한 프레젠테이션을 표현하는지 확인하기 위해 이 사양에 따라 이후의 추가 검사를 계속 수행해야 합니다.
application/vc 미디어 유형으로 간주합니다. 이는 JSON 문서에 최상위 type 속성이 있고 그 안에 VerifiableCredential 요소가 있는 경우입니다. 페이로드가 적합한 검증 가능한 자격 증명을 표현하는지 확인하기 위해 이 사양에 따라 이후의 추가 검사를 계속 수행해야 합니다.

가능하면 구현자는 이 사양에서 정의한 모든 페이로드에 가장 정밀한 미디어 유형을 사용하는 것이 좋습니다. 또한 페이로드에 정밀도가 낮은 미디어 유형 태그가 지정되어 있다고 해서 그 페이로드가 정밀도가 높은 유형의 태그를 지정하는 데 필요한 규칙을 충족하지 않는다는 의미는 아님을 알아야 합니다. 마찬가지로 정밀도가 높은 미디어 유형 태그가 지정되어 있다고 해서 페이로드가 해당 미디어 유형과 관련된 요구 사항을 충족한다는 의미도 아닙니다. 페이로드 수신자는 연결된 미디어 유형과 관계없이 페이로드가 해당 시스템에서 사용하기 위한 요구 사항을 준수하는지 적절히 검사해야 합니다.

HTTP 클라이언트와 서버는 검증 가능한 자격 증명 및 검증 가능한 프레젠테이션과 연결된 미디어 유형을 Accept 헤더와 콘텐츠 유형을 나타낼 때 사용합니다. 구현자는 HTTP 서버가 Accept 헤더를 무시하고 다른 콘텐츠 유형을 반환하거나 415 Unsupported Media Type과 같은 오류 코드를 반환할 수 있다는 점에 유의해야 합니다.

이 절은 비규범적입니다.

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 스키마 유효성 검사를 수행할 때
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 그 콘텐츠를 저장하거나 색인하는 시스템으로 직렬화하거나 시스템에서 역직렬화할 때
검증 가능한 자격 증명 또는 검증 가능한 프레젠테이션을 소프트웨어 애플리케이션에서 처리할 때. 단, 이는 일반 JSON-LD 처리가 필요한 보호 메커니즘에 대해 검증 또는 유효성 검사를 수행한 후여야 합니다.
애플리케이션이 +json 구조화 미디어 유형 접미사를 사용하여 미디어 유형을 처리하기로 선택한 경우

즉, 유형별 자격 증명 처리는 소비하거나 생성하는 문서가 적합 문서인 한 허용됩니다.

유형별 자격 증명 처리를 사용하려는 구현자는 다음 규칙을 따르는 것이 좋습니다.

@context 속성과 연결된 모든 값이 예상한 순서로 되어 있고, 컨텍스트 파일의 콘텐츠가 각 파일에 대해 올바른 것으로 알려진 암호학적 해시와 일치하며, 도메인 전문가가 해당 콘텐츠가 의도한 사용 사례에 적합하다고 판단했는지 확인하십시오.

JSON 스키마와 함께 정적 컨텍스트 파일을 사용하는 것은 위 규칙을 구현하는 데 허용되는 한 가지 접근 방식입니다. 이를 통해 유형별 자격 증명 처리를 수행할 때 용어 식별, 유형 지정 및 순서가 올바른지 확인할 수 있습니다.

위 규칙은 @context 메커니즘을 통해 리터럴 JSON 키를 URI에 매핑하는 두 처리 메커니즘 사이의 의미론적 상호 운용성을 보장합니다. 일반 JSON-LD 처리는 알고리즘에 제공된 이전에 보지 못한 @context 값을 사용하여 모든 용어가 올바르게 지정되었는지 확인할 수 있습니다. 반면 유형별 자격 증명 처리를 수행하는 구현은 미리 이해하도록 설계된 특정 @context 값만 허용하므로, JSON-LD API를 호출하지 않고도 동일한 의미론을 얻습니다. 다시 말해 두 처리 메커니즘 모두 데이터 교환이 이루어지는 컨텍스트를 @context를 사용하여 명시적으로 나타냅니다. 이 사용 방식은 동일한 적합 문서 의미론으로 이어집니다.

기본 클래스	목적
`CredentialEvidence`	evidence 속성에 배치되는 특정 증거 유형의 상위 클래스 역할을 합니다.
`CredentialSchema`	credentialSchema 속성에 배치되는 특정 스키마 유형의 상위 클래스 역할을 합니다.
`CredentialStatus`	credentialStatus 속성에 배치되는 특정 자격 증명 상태 유형의 상위 클래스 역할을 합니다.
`ConfidenceMethod`	`confidenceMethod` 속성에 배치되는 특정 신뢰도 방법 유형의 상위 클래스 역할을 합니다.
`RefreshService`	credentialRefresh 속성에 배치되는 특정 갱신 서비스 유형의 상위 클래스 역할을 합니다.
`RenderMethod`	`renderMethod` 속성에 배치되는 특정 렌더링 방법 유형의 상위 클래스 역할을 합니다.
`TermsOfUse`	termsOfUse 속성에 배치되는 특정 이용 약관 유형의 상위 클래스 역할을 합니다.

유형 이름:	application
하위 유형 이름:	vc
필수 매개변수:	없음
인코딩 고려 사항:	`application/vc` 미디어 유형을 사용하는 리소스는 `application/ld+json` 미디어 유형의 모든 요구 사항을 준수해야 하므로, JavaScript 객체 표기법 (JSON) 데이터 교환 형식의 섹션 11에 명시된 것과 동일한 인코딩 고려 사항이 적용됩니다.
보안 고려 사항:	검증 가능한 자격 증명 데이터 모델 v2.0에 정의된 바와 같습니다.
연락처:	W3C 검증 가능한 자격 증명 워킹 그룹 public-vc-wg@w3.org

유형 이름:	application
하위 유형 이름:	vp
필수 매개변수:	없음
인코딩 고려 사항:	`application/vp` 미디어 유형을 사용하는 리소스는 `application/ld+json` 미디어 유형의 모든 요구 사항을 준수해야 하므로, JavaScript 객체 표기법(JSON) 데이터 교환 형식의 11절에 명시된 것과 동일한 인코딩 고려 사항이 적용됩니다.
보안 고려 사항:	검증 가능한 자격 증명 데이터 모델 v2.0에 정의된 대로입니다.
연락처:	W3C 검증 가능한 자격 증명 작업 그룹 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 다이제스트: `134f9a8ccbd3b2063baf7c77e9ff9931903b489951f01f5202af893bdb65e282`

검증 가능한 자격 증명 데이터 모델 v2.1

초록

이 문서의 상태

1. 소개

1.1 검증 가능한 자격 증명이란?

1.2 생태계 개요

1.3 적합성

2. 용어

3. 핵심 데이터 모델

3.1 주장

3.2 자격 증명

3.3 프레젠테이션

4. 기본 개념

4.1 시작하기

4.2 검증 가능한 자격 증명

4.3 컨텍스트

4.4 식별자

클레임: id

클레임: type

클레임: id

클레임: type

4.5 유형

클레임: id

클레임: type

클레임: id

클레임: type

4.6 이름 및 설명

클레임: id

클레임: type

클레임: id

클레임: id

클레임: type

4.7 발급자

클레임: id

클레임: type

클레임: id

클레임: type

클레임: id

클레임: type

클레임: id

클레임: id

클레임: type

4.8 자격 증명 주체

클레임: id

클레임: type

클레임: id

클레임: type

4.9 유효 기간

클레임: id

클레임: type

클레임: id

클레임: type

4.10 상태

4.11 데이터 스키마

4.12 보호 메커니즘

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

엔벨로프된 검증 가능한 자격 증명

엔벨로프된 검증 가능한 프레젠테이션

파생 자격 증명을 사용하는 프레젠테이션

보유자 주장을 포함하는 프레젠테이션

5. 고급 개념

5.1 신뢰 모델

5.2 확장성

클레임: id

클레임: type

클레임: 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

C.3.1 `sriString` 데이터 유형