검증 가능한 자격 증명 데이터 무결성 1.1

데이터 무결성 증명은 증명 메커니즘, 그 증명을 검증하는 데 필요한 매개변수, 그리고 증명 값 자체에 대한 정보를 제공한다. 이 모든 정보는 The Security Vocabulary와 같은 링크드 데이터 어휘를 사용하여 제공된다.

객체에 데이터 무결성 증명을 표현할 때는 proof 속성을 사용해야 MUST 한다. 검증 가능한 자격 증명 내의 proof 속성은 명명된 그래프이다. 존재하는 경우, 그 값은 반드시 단일 객체이거나, 아래 속성으로 표현되는 순서 없는 객체 집합이어야 MUST 한다.

id

증명의 선택적 식별자로, URL [URL]이어야 MUST 한다. 예를 들어 URN으로서의 UUID(urn:uuid:6a1676b8-b51f-11ed-937b-d76685a20ff5)가 있다. 이 속성의 사용은 2.1.2 증명 체인 절에서 더 설명된다.

type

특정 증명 타입은 URL [URL]에 매핑되는 문자열로 지정되어야 MUST 한다. 증명 타입의 예에는 DataIntegrityProof 및 Ed25519Signature2020가 포함된다. 증명 타입은 증명을 보호하고 검증하기 위해 어떤 다른 필드가 필요한지를 결정한다.

proofPurpose

증명이 생성된 이유는 URL [URL]에 매핑되는 문자열로 지정되어야 MUST 한다. 증명 목적은 증명이 의도된 목적이 아닌 다른 목적에 적용되어 오용되는 것을 방지하는 안전장치로 작동한다. 예를 들어 이 값이 없으면 증명 생성자가 로그인 과정(authentication)에서 검증 가능한 자격 증명 (assertionMethod)을 만드는 데 일반적으로 사용되는 암호학적 자료를 사용하도록 속을 수 있고, 그 결과 웹사이트에 단순히 로그인하려는 의도된 동작 대신 자신이 만들 의도가 없었던 검증 가능한 자격 증명이 생성될 수 있다.

verificationMethod

검증 방법은 증명을 검증하는 데 필요한 수단과 정보이다. 포함되는 경우, 값은 [URL]에 매핑되는 문자열이어야 MUST 한다. verificationMethod의 포함은 OPTIONAL이지만, 포함되지 않은 경우 cryptosuite와 같은 다른 속성이 증명을 검증하는 데 필요한 정보를 얻는 메커니즘을 제공할 수 있다. verificationMethod가 데이터 무결성 증명에 표현될 때, 그 값은 데이터의 실제 위치를 가리킨다는 점에 유의하라. 즉, verificationMethod는 URL을 통해 증명을 검증하는 데 사용할 수 있는 공개 키의 위치를 참조한다. 이 공개 키 데이터는 검증 방법의 전체 설명을 포함하는 제어 식별자 문서에 저장된다.

cryptosuite

증명을 검증하는 데 사용할 수 있는 암호 스위트의 식별자이다. 자세한 내용은 3. 암호 스위트를 참조하라. 증명 type이 DataIntegrityProof인 경우, cryptosuite는 반드시 지정되어야 MUST 한다. 그렇지 않은 경우 cryptosuite는 지정될 수 있다 MAY. 지정되는 경우 그 값은 문자열이어야 MUST 한다.

created

증명이 생성된 날짜와 시간은 OPTIONAL이며, 포함되는 경우 [XMLSCHEMA11-2] dateTimeStamp 문자열로 지정되어야 MUST 한다. 이는 값 끝에 Z로 표시되는 협정 세계시(UTC)이거나 UTC에 대한 시간대 오프셋이 있는 값이다. 적합한 처리기는 오프셋 없이 잘못 직렬화된 시간 값을 소비하도록 선택할 수 있다 MAY. 오프셋 없이 잘못 직렬화된 시간 값은 UTC로 해석되어야 한다.

expires

expires 속성은 OPTIONAL이며, 존재하는 경우 증명이 만료되는 시점을 지정한다. 존재하는 경우, 이는 [XMLSCHEMA11-2] dateTimeStamp 문자열이어야 MUST 하며, 값 끝에 Z로 표시되는 협정 세계시(UTC)이거나 UTC에 대한 시간대 오프셋이 있는 값이어야 한다. 적합한 처리기는 오프셋 없이 잘못 직렬화된 시간 값을 소비하도록 선택할 수 있다 MAY. 오프셋 없이 잘못 직렬화된 시간 값은 UTC로 해석되어야 한다.

domain

domain 속성은 OPTIONAL이다. 이는 증명이 사용되도록 의도된 하나 이상의 보안 도메인을 전달한다. 지정되는 경우, 관련 값은 문자열 또는 순서 없는 문자열 집합이어야 MUST 한다. 검증자는 증명이 검증자가 운영 중인 보안 도메인에서 사용되도록 의도되었는지 확인하기 위해 그 값을 사용해야 SHOULD 한다. domain 매개변수의 지정은 검증자가 증명 생성자에게 알려진 보안 도메인 내에서 운영되는 challenge-response 프로토콜에서 유용하다. 도메인 값의 예에는 domain.example(DNS 도메인), https://domain.example:8443(웹 출처), mycorp-intranet(맞춤 텍스트 문자열), 그리고 b31d37d4-dd59-47d3-9dd8-c973da43b63a(UUID)가 포함된다.

challenge

domain이 지정된 경우 증명에 포함되어야 하는 문자열 값이다 SHOULD. 이 값은 특정 도메인과 시간 창에 대해 한 번 사용된다. 이 값은 재생 공격을 완화하는 데 사용된다. challenge 값의 예에는 1235abcd6789, 79d34551-ae81-44ae-823b-6dadbab9ebd4, 그리고 ruby가 포함된다.

proofValue

지정된 verificationMethod를 사용하여 디지털 증명을 검증하는 데 필요한 base 인코딩된 바이너리 데이터를 표현하는 문자열 값이다. 이 값은 바이너리 데이터를 표현하기 위해 Controlled Identifiers v1.0 명세의 2.4 Multibase 절에 설명된 헤더와 인코딩을 사용해야 MUST 한다. 이 값의 내용은 특정 cryptosuite에 의해 결정되며 해당 cryptosuite의 Add Proof Algorithm이 생성한 증명 값으로 설정된다. cryptosuite가 지정한 다른 인코딩의 대체 속성은 디지털 증명을 검증하는 데 필요한 데이터를 인코딩하기 위해 이 속성 대신 사용될 수 있다 MAY.

previousProof

previousProof 속성은 OPTIONAL이다. 존재하는 경우, 이는 문자열 값 또는 순서 없는 문자열 값 목록이어야 MUST 한다. 각 값은 또 다른 데이터 무결성 증명을 식별하며, 현재 증명이 검증된 것으로 간주되기 위해서는 이들 모두 또한 검증되어야 MUST 한다. 이 속성은 2.1.2 증명 체인 절에서 사용된다.

nonce

증명 생성자가 제공하는 OPTIONAL 문자열 값이다. 이 필드의 한 가지 용도는 결정론적으로 생성된 서명으로 인해 발생하는 연결 가능성을 줄여 개인정보 보호를 높이는 것이다.

증명은 다음과 같이 JSON 문서에 추가될 수 있다.

{
  "myWebsite": "https://hello.world.example/"
};

다음 증명은 eddsa-jcs-2022 암호 스위트 [DI-EDDSA]를 사용하여 위 문서를 보호한다. 이 스위트는 JSON Canonicalization Scheme (JCS) [RFC8785]을 사용하여 입력 데이터를 변환한 다음 Edwards Digital Signature Algorithm (EdDSA)을 사용하여 디지털 서명함으로써 검증 가능한 디지털 증명을 생성한다.

{
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2023-03-05T19:23:24Z",
    "verificationMethod": "https://di.example/issuer#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

마찬가지로, 증명은 다음과 같이 JSON-LD 데이터 문서에 추가될 수 있다.

{
  "@context": {"myWebsite": "https://vocabulary.example/myWebsite"},
  "myWebsite": "https://hello.world.example/"
};

다음 증명은 ecdsa-rdfc-2019 암호 스위트 [DI-ECDSA]를 사용하여 위 문서를 보호한다. 이 스위트는 RDF Dataset Canonicalization Scheme [RDF-CANON]을 사용하여 입력 데이터를 변환한 다음 Elliptic Curve Digital Signature Algorithm (ECDSA)을 사용하여 디지털 서명함으로써 검증 가능한 디지털 증명을 생성한다.

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "zXb23ZkdakfJNUhiTEdwyE598X7RLrkjnXEADLQZ7vZyUGXX8cyJZRBkNw813SGsJHWrcpo4Y8hRJ7adYn35Eetq"
  }
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    // the proof expires a month after it was created
    "expires": "2020-07-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z98X7RLrkjnXEADJNUhiTEdwyE5GXX8cyJZRLQZ7vZyUXb23ZkdakfRJ7adYY8hn35EetqBkNw813SGsJHWrcpo4"
  }
}

데이터 무결성 명세는 하나의 문서 안에 여러 증명을 포함하는 개념을 지원한다. 식별되는 다중 증명 접근 방식에는 두 가지 유형이 있다. 증명 세트(순서 없음)와 증명 체인(순서 있음)이다.

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // This is one of the proofs in the set
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
  }, {
    // This is the other proof in the set
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T13:08:49Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm95"
  }]
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // The 'id' value identifies this specific proof
    "id": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7",
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:42Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV64oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQe"
  }, {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T21:28:14Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm955QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ",
    // The 'previousProof' value identifies which proof is verified before this one
    "previousProof": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7"
  }]
}

목적을 설명하는 증명은 그것이 다른 목적으로 오용되는 것을 방지하는 데 도움이 된다. 증명 목적은 검증자가 증명 생성자의 의도를 알 수 있게 하여, 메시지가 다른 목적으로 우발적으로 악용되는 것을 막는다. 예를 들어 단순히 주장하기 위한 목적으로 서명된 메시지(널리 공유되도록 의도되었을 수 있음)가 서비스에 인증하거나 어떤 작업(예: 어떤 일을 하기 위한 capability 호출)을 수행하기 위한 메시지로 악용되는 경우가 있다.

증명 목적은 JSON Web Key (JWK)의 key_ops 제한, Web Cryptography API의 KeyUsage 제한 및 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile과는 다른 메커니즘이라는 점이 중요하다. 증명 목적은 증명이 왜 생성되었고 그 의도된 사용 도메인이 무엇인지에 대한 표현인 반면, 언급된 다른 메커니즘은 개인 키가 수행할 수 있는 일을 제한하기 위한 것이다. 증명 목적은 증명과 함께 "이동"하지만, 키 제한은 그렇지 않다.

다음은 흔히 사용되는 증명 목적 값의 목록이다.

authentication

주어진 증명이 인증 프로토콜의 목적에만 사용되어야 함을 나타낸다.

assertionMethod

증명이 예를 들어 검증 가능한 자격 증명에 서명하는 것과 같이 주장 작성에만 사용될 수 있음을 나타낸다.

keyAgreement

증명이 인기 있는 암호화 라이브러리에서 사용되는 Elliptic Curve Diffie Hellman 키 합의와 같은 키 합의 프로토콜에 사용됨을 나타낸다.

capabilityDelegation

증명이 capability 위임에만 사용될 수 있음을 나타낸다. 자세한 내용은 Authorization Capabilities [ZCAP] 명세를 참조하라.

capabilityInvocation

증명이 capability 호출에만 사용될 수 있음을 나타낸다. 자세한 내용은 Authorization Capabilities [ZCAP] 명세를 참조하라.

외부 리소스에 대한 링크가 적합한 보호 문서에 포함되는 경우, 식별된 리소스가 증명이 생성된 이후 변경되었는지 아는 것이 바람직하다. 이는 원격으로 가져오는 외부 리소스가 있는 경우뿐 아니라 검증자가 해당 리소스의 로컬 캐시 사본을 가지고 있을 수 있는 경우에도 적용된다.

적합한 보호 문서가 참조하는 리소스가 문서가 보호된 이후 변경되지 않았음을 확인할 수 있게 하기 위해, 구현자는 id 속성을 포함하는 모든 객체에 digestMultibase라는 속성을 포함할 수 있다 MAY. 존재하는 경우, digestMultibase 값은 단일 문자열 값이거나, 각각 Multibase로 인코딩된 Multihash 값인 문자열 값의 목록이어야 MUST 한다.

JSON-LD 컨텍스트 작성자는 다른 리소스를 참조하는 문서에서 사용될 컨텍스트에 digestMultibase를 추가하고 관련 암호학적 다이제스트를 포함해야 한다. 예를 들어 Verifiable Credentials Data Model v2.0 기본 컨텍스트 (https://www.w3.org/ns/credentials/v2)는 digestMultibase 속성을 포함한다.

리소스 무결성이 보호된 객체의 예는 아래에 표시되어 있다.

{
  ...
  "image": {
    "id": "https://university.example.org/images/58473",
    "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
  },
  ...
}

구현자는 자신의 사용 사례에 적합한 해시 알고리즘을 선택하고 있는지 확인하기 위해 FIPS 180-4 Secure Hash Standard 및 Commercial National Security Algorithm Suite 2.0와 같은 적절한 출처를 참조할 것을 강력히 권장한다.

JSON-LD 처리를 수행하는 구현은 다음 JSON-LD 컨텍스트 URL을 이미 해석된 것으로 취급해야 MUST 하며, 해석된 문서는 아래의 해당 해시 값과 일치해야 한다.

위에 나열된 암호학적 다이제스트는 최신 UNIX 유사 OS 명령줄 인터페이스에서 다음과 같은 명령을 실행하여 확인할 수 있다(<DOCUMENT_URL>을 적절한 값으로 대체한다). curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256

위에 나열된 JSON-LD 컨텍스트가 해석되는 보안 어휘 용어는 https://w3id.org/security# 네임스페이스에 있다. 즉, 이 어휘의 모든 보안 용어는 https://w3id.org/security#TERM 형식이며, 여기서 TERM은 용어의 이름이다.

RDF 처리를 수행하는 구현은 어휘 URL의 JSON-LD 직렬화를 이미 역참조된 것으로 취급해야 MUST 하며, 역참조된 문서는 아래의 해당 해시 값과 일치해야 한다.

https://w3id.org/security# URL을 역참조할 때 반환되는 데이터의 미디어 타입은 HTTP 콘텐츠 협상에 따라 달라진다. 이는 다음과 같다.

위에 나열된 암호학적 다이제스트는 최신 UNIX 유사 OS 명령줄 인터페이스에서 다음과 같은 명령을 실행하여 확인할 수 있다(<MEDIA_TYPE> 및 <DOCUMENT_URL>을 적절한 값으로 대체한다). curl -sL -H "Accept: <MEDIA_TYPE>" <DOCUMENT_URL> | openssl dgst -sha256

애플리케이션별 어휘와 명세의 작성자는 자신의 JSON-LD 컨텍스트와 어휘 파일이 위에서 설명한 캐싱 접근 방식 또는 기능적으로 동등한 메커니즘을 사용하여 영구적으로 캐시 가능하도록 보장해야 SHOULD 한다.

구현은 개발 중에는 애플리케이션별 JSON-LD 컨텍스트 파일을 네트워크에서 로드할 수 있지만 MAY, 프로덕션 설정에서는 보안 및 개인정보 보호 특성을 높이기 위해 적합한 보호 문서에서 사용하는 JSON-LD 컨텍스트 파일을 영구적으로 캐시해야 SHOULD 한다. 처리 속도 목표는 위에서 설명한 것과 같은 캐싱 접근 방식 또는 기능적으로 동등한 메커니즘을 통해 달성될 수 있다 MAY.

디지털 지갑과 같은 일부 애플리케이션은 임의의 발급자와 임의의 컨텍스트를 사용하는 임의의 검증 가능한 자격 증명 또는 기타 데이터 무결성 보호 문서를 보유할 수 있으며, 프로덕션 설정에서 JSON-LD 컨텍스트 파일과 같은 외부 링크 리소스를 로드할 수 있어야 할 수도 있다. 이는 시간이 지남에 따라 생태계에서 사용자 선택, 확장성 및 탈중앙화 업그레이드를 증가시킬 것으로 예상된다. 이러한 애플리케이션의 작성자는 추가 고려 사항을 위해 이 문서의 보안 및 개인정보 보호 절을 읽는 것이 권장된다.

JSON-LD 컨텍스트 및 어휘의 처리에 관한 추가 정보는 Verifiable Credentials v2.0: Base Context 및 Verifiable Credentials v2.0: Vocabularies를 참조하라.

Linked Data라는 용어는 URL과 같은 표준을 사용하여 사물과 그 속성을 식별함으로써 웹에서 정보를 노출, 공유, 연결하기 위한 권장 모범 사례를 설명하는 데 사용된다. 정보가 Linked Data로 제공되면, 다른 관련 정보를 쉽게 발견할 수 있고 새로운 정보를 쉽게 연결할 수 있다. Linked Data는 탈중앙화된 방식으로 확장 가능하여 대규모 통합의 장벽을 크게 낮춘다.

다양한 애플리케이션에서 Linked Data의 사용이 증가함에 따라, Linked Data 문서의 진정성과 무결성을 검증할 수 있어야 할 필요가 있다. 이 명세는 확장성과 조합 가능성 같은 Linked Data 기능을 희생하지 않고, 수학적 증명을 사용하여 데이터 문서에 인증 및 무결성 보호를 추가한다.

이 명세를 구현하는 암호 스위트는 검증 가능한 자격 증명 및 검증 가능한 프레젠테이션을 보호하는 데 사용될 수 있다. 이러한 사용 사례를 다루는 구현자는 그 유형의 문서를 처리할 때 추가 검사가 적절할 수 있음을 주의해야 한다.

증명에 사용된 검증 방법이 issuer와 검증 가능한 자격 증명 안에서, 또는 holder와 검증 가능한 프레젠테이션 안에서, 검증 과정 중 관련되어 있음을 보장하는 것이 중요한 사용 사례가 있다. 그러한 관련성을 확인하는 한 가지 방법은 증명의 검증 방법의 controller 속성 값이 issuer 또는 holder를 식별하는 데 사용된 URL 값과 각각 일치하고, 검증 방법이 증명의 목적을 고려할 때 허용 가능한 검증 관계 아래 표현되어 있는지 확인하는 것이다. 이 특정 관련성은 issuer 또는 holder가 각각 증명을 검증하는 데 사용되는 검증 방법의 컨트롤러임을 나타낸다.

문서 작성자와 구현자는 증명의 유효 기간과 자격 증명의 유효 기간의 차이를 이해하는 것이 권장된다. 증명의 유효 기간은 created 및 expires 속성을 사용하여 표현되고, 자격 증명의 유효 기간은 validFrom 및 validUntil 속성을 사용하여 표현된다. 이러한 속성이 때로는 같은 유효 기간을 표현할 수 있지만, 다른 경우에는 일치하지 않을 수도 있다. 증명을 검증할 때는 관심 시점(현재 시간이거나 다른 어떤 시간일 수 있음)이 증명의 유효 기간 안에 있는지, 즉 created와 expires 사이에 있는지 확인하는 것이 중요하다. 검증할 때 검증 가능한 자격 증명에 대해, 관심 시점이 자격 증명의 유효 기간 안에 있는지, 즉 validFrom과 validUntil 사이에 있는지 확인하는 것이 중요하다. 증명의 유효 기간 또는 자격 증명의 유효 기간을 검증하지 못하면 거부되어야 할 데이터를 수락하게 될 수 있음에 유의하라.

마지막으로, 구현자는 검증 가능한 자격 증명과 관련된 폐기 정보와 검증 방법에 대한 폐기 및 만료 시간 사이에는 차이가 있음을 이해할 것도 강력히 권장된다. 검증 방법의 폐기 및 만료 시간은 각각 revocation 및 expires 속성을 사용하여 표현된다. 이는 비밀 키가 손상되거나 만료되는 것과 같은 이벤트와 관련되어 있으며, 컨트롤러의 보안 관행이나 언제 손상되었을 수 있는지 같은 세부 정보를 드러낼 수 있는 시간 정보를 제공할 수 있다. 검증 가능한 자격 증명의 폐기 정보는 credentialStatus 속성을 사용하여 표현되며, 개인이 검증 가능한 자격 증명이 부여하는 권한을 잃는 것과 같은 이벤트와 관련되어 있고, 시간 정보를 제공하지 않으므로 개인정보 보호를 향상시킨다.

여러 암호 스위트는 데이터 무결성 증명을 표현할 때 동일한 기본 패턴을 따른다. 이 절은 그 일반적인 설계 패턴, 즉 DataIntegrityProof라고 하는 암호 스위트 타입을 명시하며, 설계 기본 요소와 소스 코드의 재사용을 통해 암호 스위트를 작성하고 구현하는 부담을 줄인다.

이 설계 패턴을 사용하는 암호 스위트를 명시할 때, proof 값은 다음 형식을 취한다.

type

type 속성은 문자열 DataIntegrityProof를 포함해야 MUST 한다.

cryptosuite

cryptosuite 속성의 값은 암호 스위트를 식별하는 문자열이어야 MUST 한다. 처리 환경이 문자열 하위 타입을 지원하는 경우, cryptosuite 값의 하위 타입은 https://w3id.org/security#cryptosuiteString 하위 타입이어야 MUST 한다.

proofValue

proofValue 속성은 2.1 증명 절에 명시된 대로 사용되어야 MUST 한다.

암호 스위트 설계자는 2.1 증명 절에 정의된 필수 proof 값 속성을 사용해야 MUST 하며, 자신의 암호 스위트에 특정한 다른 속성을 정의할 수 있다 MAY.

다음 알고리즘은 증명 또는 증명 세트/체인을 포함하는 보호된 문서에서 시작하여, 증명 세트 또는 증명 체인에 증명을 점진적으로 추가하는 방법을 명시한다. 필수 입력은 보호된 데이터 문서 (map securedDocument), 암호 스위트 (cryptosuite instance suite), 그리고 옵션 집합(map options)이다. 출력은 새로운 보호된 데이터 문서 (map)이다. 이 알고리즘이 문자열을 인코딩할 때마다 UTF-8 인코딩을 사용해야 MUST 한다.

1. proof를 securedDocument.proof로 설정한다. allProofs를 빈 목록으로 둔다. proof가 목록이면, proof의 모든 요소를 allProofs에 복사한다. proof가 객체이면 그 객체의 사본을 allProofs에 추가한다.
2. inputDocument를 proof 속성이 제거된 securedDocument의 사본으로 둔다. output을 inputDocument의 사본으로 둔다.
3. matchingProofs를 빈 목록으로 둔다.
4. options에 문자열인 previousProof item이 있으면, previousProof와 일치하는 id 속성을 가진 allProofs의 요소를 matchingProofs에 추가한다. previousProof와 같은 id를 가진 증명이 allProofs에 존재하지 않으면, 오류가 발생해야 MUST 하며 PROOF_GENERATION_ERROR 오류 타입을 전달해야 SHOULD 한다.
5. options에 배열인 previousProof item이 있으면, 그 배열의 요소와 일치하는 id 속성을 가진 allProofs의 각 요소를 추가한다. previousProof list의 어떤 요소든 allProofs의 어떤 요소의 id 속성과도 일치하지 않는 id 속성을 가지면, 오류가 발생해야 MUST 하며 PROOF_GENERATION_ERROR 오류 타입을 전달해야 SHOULD 한다.
6. inputDocument.proof를 matchingProofs로 설정한다.
   참고: 이 단계는 문서와 기존 증명을 보호한다

   이 단계는 명명된 그래프에 대한 참조를 추가할 뿐 아니라, 증명 그래프에 포함된 모든 주장의 사본을 추가한다. 이 단계는 현재 증명을 적용하기 전에 일치하는 모든 증명을 문서에 바인딩하므로 중요하다. 문서의 proof 값은 이 알고리즘의 이후 단계에서 갱신된다.

7. 4.2 증명 추가 절의 알고리즘 1단계부터 6단계까지를 실행하며, inputDocument, suite, 그리고 options를 전달한다. 예외가 발생하지 않으면, 생성된 proof 값을 allProofs에 추가한다. 그렇지 않으면 예외를 발생시킨다.
8. output.proof를 allProofs의 값으로 설정한다.
9. output을 새로운 보호된 데이터 문서로 반환한다.

다음 알고리즘은 디지털 증명을 검증하여 보호된 데이터 문서의 진정성과 무결성을 검사하는 방법을 명시한다. 알고리즘은 다음을 입력으로 받는다.

mediaType

[MIMESNIFF]에 정의된 미디어 타입

documentBytes

미디어 타입이 mediaType인 바이트 시퀀스

cryptosuite

cryptosuite instance

expectedProofPurpose

선택적 문자열로, proof가 검증자가 예상한 이유로 증명 생성자에 의해 생성되었음을 보장하는 데 사용된다. 일반적인 값은 2.2 증명 목적을 참조하라.

domain

선택적 집합의 문자열로, 증명 생성자가 증명을 특정 보안 도메인에 묶는 데 사용하고, 검증자가 증명이 서로 다른 보안 도메인 간에 사용되지 않도록 보장하는 데 사용된다.

challenge

선택적 문자열 challenge로, 검증자가 공격자가 이전에 생성된 증명을 재생하지 않는지 보장하는 데 사용된다.

이 알고리즘은 검증 결과, 즉 다음 항목을 가진 struct를 반환한다.

verified

true 또는 false

verifiedDocument

verified가 false이면 Null, 그렇지 않으면 입력 문서

mediaType

verified가 false이면 Null, 그렇지 않으면 미디어 타입이며, 이는 매개변수를 포함할 수 있다 MAY.

warnings

목록의 ProblemDetails로, 기본값은 빈 목록이다.

errors

목록의 ProblemDetails로, 기본값은 빈 목록이다.

어떤 단계에서 "오류가 발생해야 MUST 한다"라고 말하는 경우, 이는 false인 verified 값과 비어 있지 않은 errors 목록을 가진 검증 결과가 반환되어야 MUST 함을 의미한다.

1. securedDocument를 documentBytes에 대해 Infra 값으로 JSON 바이트 파싱을 실행한 결과로 둔다.
2. securedDocument가 map이 아니거나, securedDocument.proof가 map이 아닌 경우, 오류가 발생해야 MUST 하며 PARSING_ERROR 오류 타입을 전달해야 SHOULD 한다.
3. proof를 securedDocument.proof로 둔다.
4. proof.type, proof.verificationMethod, 그리고 proof.proofPurpose 중 하나 이상이 존재하지 않으면, 오류가 발생해야 MUST 하며 PROOF_VERIFICATION_ERROR 오류 타입을 전달해야 SHOULD 한다.
5. expectedProofPurpose가 주어졌고 이것이 proof.proofPurpose와 일치하지 않으면, 오류가 발생해야 MUST 하며 PROOF_VERIFICATION_ERROR 오류 타입을 전달해야 SHOULD 한다.
6. domain이 주어졌고, 단일 문자열을 그 문자열 하나만 포함하는 집합으로 취급할 때, 그것이 proof.domain과 동일한 문자열을 포함하지 않으면, 오류가 발생해야 MUST 하며 INVALID_DOMAIN_ERROR 오류 타입을 전달해야 SHOULD 한다.
7. challenge가 주어졌고 이것이 proof.challenge와 일치하지 않으면, 오류가 발생해야 MUST 하며 INVALID_CHALLENGE_ERROR 오류 타입을 전달해야 SHOULD 한다.
8. cryptosuiteVerificationResult를 securedDocument를 입력으로 제공하여 cryptosuite.verifyProof 알고리즘을 실행한 결과로 둔다.
9. 다음 항목을 가진 검증 결과를 반환한다.

   verified

   cryptosuiteVerificationResult.verified

   verifiedDocument

   cryptosuiteVerificationResult.verifiedDocument

   mediaType

   mediaType

증명 세트 또는 증명 체인에서 보호된 데이터 문서는 증명 목록(allProofs)을 포함하는 proof 속성을 가진다. 다음 알고리즘은 allProofs의 모든 증명을 검증함으로써 보호된 데이터 문서의 진정성과 무결성을 검사하는 한 가지 방법을 제공한다. 다른 접근 방식도 가능하며, 특히 allProofs에 포함된 증명 중 일부만 검증하려는 경우 그렇다. 증명 중 일부만 검증하는 다른 접근 방식을 취하는 경우, 그 부분 집합 안에서 previousProof를 가진 어떤 증명도 그것이 참조하는 증명들이 또한 검증된 것으로 간주될 때에만 검증된 것으로 간주될 수 있다는 점에 유의하는 것이 중요하다.

필수 입력은 보호된 데이터 문서 (securedDocument)이다. allProofs의 각 증명에 대응하는 검증 결과 목록이 생성되고, 단일 결합 검증 결과가 출력으로 반환된다. 구현은 결합 검증 결과와 함께 다른 검증 결과 및/또는 기타 메타데이터를 반환할 수 있다 MAY.

1. allProofs를 securedDocument.proof로 설정한다.
2. verificationResults를 빈 목록으로 설정한다.
3. allProofs의 각 proof에 대해 다음 단계를 수행한다.
   1. matchingProofs를 빈 목록으로 둔다.
   2. proof가 previousProof 속성을 포함하고 그 속성의 값이 문자열이면, previousProof의 값과 일치하는 id 속성 값을 가진 allProofs의 요소를 matchingProofs에 추가한다. previousProof의 값과 같은 id 값을 가진 증명이 allProofs에 존재하지 않으면, 오류가 발생해야 MUST 하며 PROOF_VERIFICATION_ERROR 오류 타입을 전달해야 SHOULD 한다. previousProof 속성이 목록이면, 그 목록의 요소 값과 일치하는 id 속성 값을 가진 allProofs의 각 요소를 추가한다. previousProof list의 어떤 요소든 allProofs의 어떤 요소의 id 속성 값과도 일치하지 않는 id 속성 값을 가지면, 오류가 발생해야 MUST 하며 PROOF_VERIFICATION_ERROR 오류 타입을 전달해야 SHOULD 한다.
   3. inputDocument를 증명 값이 제거된 securedDocument의 사본으로 둔 다음, inputDocument.proof를 matchingProofs로 설정한다.
      참고: 보호된 문서와 이전 증명

      이 단계가 어떤 문서 속성과 이전 증명을 보호하는지 알아보려면 4.3 증명 세트/체인 추가 절의 6단계에 있는 참고를 참조하라.

   4. 4.4 증명 검증 절의 알고리즘 4단계부터 8단계까지를 inputDocument에 대해 실행한다. 예외가 발생하지 않으면 cryptosuiteVerificationResult를 verificationResults에 추가한다.
4. successfulVerificationResults를 빈 목록으로 설정한다.
5. combinedVerificationResult를 빈 struct로 둔다. combinedVerificationResult.status를 true로, combinedVerificationResult.document를 null로, 그리고 combinedVerificationResult.mediaType를 null로 설정한다.
6. verificationResults의 각 cryptosuiteVerificationResult에 대해:
   1. cryptosuiteVerificationResult.verified가 false이면, combinedVerificationResult.verified를 false로 설정한다.
   2. 그렇지 않으면, combinedVerificationResult.document를 cryptosuiteVerificationResult.verifiedDocument로 설정하고, combinedVerificationResult.mediaType를 cryptosuiteVerificationResult.mediaType로 설정하며, cryptosuiteVerificationResult를 successfulVerificationResults에 추가한다.
7. combinedVerificationResult.status가 false이면, combinedVerificationResult.document를 null로 설정하고 combinedVerificationResult.mediaType를 null로 설정한다.
8. combinedVerificationResult, successfulVerificationResults를 반환한다.

암호학은 비밀을 사용하여 정보를 보호한다. 필요한 비밀을 알고 있으면 특정 정보에 접근하는 것이 계산적으로 쉽다. 계산적으로 어려운 무차별 대입 시도가 그 비밀을 성공적으로 추측하는 경우에도 같은 정보에 접근할 수 있다. 모든 현대 암호학은 계산적으로 어려운 접근 방식이 시간이 지나도 계속 어려운 상태로 유지될 것을 요구하지만, 과학과 수학의 돌파구 때문에 이것이 항상 유지되는 것은 아니다. 즉, 암호학에는 유효 기간이 있다.

이 명세는 오늘날 사용 중인 어떤 암호학도 시간이 지나면 깨질 가능성이 매우 높다고 주장함으로써 모든 암호학적 접근 방식의 노후화를 고려한다. 소프트웨어 시스템은 정보를 계속 보호하기 위해 시간이 지남에 따라 사용 중인 암호학을 변경할 수 있어야 한다. 이러한 변경에는 필요한 비밀 크기를 늘리거나 사용되는 암호학적 기본 요소를 수정하는 일이 포함될 수 있다. 그러나 암호학적 매개변수의 일부 조합은 실제로 보안을 낮출 수 있다. 이러한 가정하에서, 시스템은 서로 다른 안전한 암호학적 매개변수 조합, 즉 cryptographic suites를 서로 구별할 수 있어야 한다. cryptographic suites를 식별하거나 버전 관리할 때 취할 수 있는 접근 방식은 여러 가지가 있으며, 여기에는 매개변수, 숫자, 날짜가 포함된다.

매개변수 기반 버전 관리는 cryptographic suite에 사용되는 특정 암호학적 매개변수를 명시한다. 예를 들어 RSASSA-PKCS1-v1_5-SHA1와 같은 식별자를 사용할 수 있다. 이 방식의 장점은 잘 훈련된 암호학자가 식별자만으로 작동 중인 모든 매개변수를 판단할 수 있다는 것이다. 이 방식의 단점은 이러한 종류의 식별자를 사용하는 대부분의 사람이 충분히 훈련되어 있지 않아, 앞서 언급한 식별자가 더 이상 사용하기 안전하지 않은 cryptographic suite라는 것을 이해하지 못한다는 것이다. 또한 이러한 지식 부족으로 인해 소프트웨어 개발자가 cryptographic suite 식별자의 파싱을 일반화하여 암호학적 기본 요소의 어떤 조합도 허용되도록 만들 수 있고, 그 결과 보안이 저하될 수 있다. 이상적으로는 cryptographic suites가 특정하고 허용 가능한 암호학적 매개변수 프로필로 소프트웨어에 구현되어야 한다.

숫자 기반 버전 관리는 1.0 또는 2.1과 같은 주 버전 및 부 버전 번호를 명시할 수 있다. 숫자 기반 버전 관리는 특정 순서를 전달하고 더 높은 버전 번호가 더 낮은 버전 번호보다 더 뛰어난 기능을 가진다는 인상을 준다. 이 접근 방식의 장점은 전문성이 낮은 개발자가 이해하지 못할 수 있는 복잡한 매개변수를 제거하고, 업그레이드가 적절할 수 있음을 전달하는 더 단순한 모델을 제공한다는 것이다. 이 접근 방식의 단점은 소프트웨어 버전 번호의 증가가 소프트웨어가 계속 작동하기 위해 항상 업그레이드를 요구하는 것은 아니므로, 업그레이드가 필요한지 명확하지 않다는 것이다. 이로 인해 개발자는 특정 버전의 사용이 실제로는 안전하지 않은데도 안전하다고 생각할 수 있다. 이상적으로는 소프트웨어에서 cryptographic suites를 사용하는 개발자에게 그 suite의 지속적인 보안을 위해 주기적인 검토가 필요하다는 추가 신호가 제공되어야 한다.

날짜 기반 버전 관리는 특정 cryptographic suite의 특정 릴리스 날짜를 명시한다. 연도와 같은 날짜의 장점은 개발자가 그 날짜가 비교적 오래되었는지 새로운지 즉시 알 수 있다는 것이다. 오래된 날짜를 보면 개발자는 더 새로운 cryptographic suite를 찾아보게 될 수 있지만, 매개변수 기반 또는 숫자 기반 버전 관리 방식은 그렇지 않을 수 있다. 날짜 기반 버전의 단점은 일부 cryptographic suites가 5~10년 동안 만료되지 않을 수 있어, 개발자가 더 새로운 cryptographic suite를 찾으려 해도 더 새로운 것을 찾지 못할 수 있다는 것이다. 이는 불편할 수 있지만, 더 안전한 생태계 행동으로 이어지는 불편함이다.

현대 암호 알고리즘은 서로 다른 사용 사례의 다양한 요구 사항을 충족할 수 있도록 여러 조정 가능한 매개변수와 옵션을 제공한다. 예를 들어 임베디드 시스템은 처리 및 메모리 환경이 제한되어 있으며, 주어진 알고리즘에서 가장 강한 디지털 서명을 생성할 리소스가 없을 수 있다. 금융 거래 시스템과 같은 다른 환경은 거래가 진행되는 하루 동안만 데이터를 보호하면 될 수 있고, 다른 환경은 여러 십 년 동안 데이터를 보호해야 할 수 있다. 이러한 요구를 충족하기 위해 암호 알고리즘 설계자는 종종 암호 알고리즘을 구성하는 여러 방법을 제공한다.

암호 라이브러리 구현자는 암호 알고리즘 설계자와 명세 작성자가 만든 명세를 가져와, 자신의 라이브러리를 사용하는 애플리케이션 개발자에게 모든 옵션이 제공되도록 구현하는 경우가 많다. 이는 특정 애플리케이션 개발자가 주어진 암호 배포에서 어떤 기능 조합을 필요로 할지 알 수 없기 때문일 수 있다. 모든 옵션은 종종 애플리케이션 개발자에게 노출된다.

암호 라이브러리를 사용하는 애플리케이션 개발자는 주어진 애플리케이션에 대해 암호학적 매개변수와 옵션을 적절히 선택하는 데 필요한 암호학적 전문성과 지식을 갖추지 못한 경우가 많다. 이러한 전문성 부족은 특정 애플리케이션에 부적절한 암호학적 매개변수와 옵션을 선택하는 결과로 이어질 수 있다.

이 명세는 애플리케이션 개발자를 암호 라이브러리 구현자보다, 암호 라이브러리 구현자를 암호 명세 작성자보다, 암호 명세 작성자를 암호 알고리즘 설계자보다 보호하는 것을 구성원 우선순위로 설정한다. 이러한 우선순위를 고려하여 다음 권고 사항이 제시된다.

• 암호 알고리즘 설계자는 [RFC7696]에 따라, 암호 라이브러리 구현자가 자신의 소프트웨어 라이브러리에 대해 더 쉽게 감사 가능한 보안 공격 표면을 갖도록 보장하기 위해 옵션과 매개변수의 수를 가능한 한 적게 줄이는 것이 권장된다.
• 암호 명세 작성자는 가능하다면 옵션과 매개변수의 수를 더 줄여, 암호 민첩성을 보장하면서도 하위 소프트웨어 라이브러리의 감사 가능한 보안 공격 표면을 최소한으로 유지하는 것이 권장된다.
• 암호 라이브러리 구현자는 가능하다면 알려진 양호한 옵션 및 매개변수 조합을 애플리케이션 개발자에게 제공하는 것이 권장된다. 이상적으로는 Elliptic Curve Digital Signatures와 같은 알고리즘 클래스마다 두 개의 사전 설정 기본 구성이 있어야 하며, 이러한 사전 설정을 사용할 때 매개변수와 옵션을 미세 조정할 수 없어야 한다. 라이브러리 옵션은 전문가가 라이브러리 사용을 미세 조정할 수 있도록 제공될 수 있지만, 일반 애플리케이션 개발자 집단이 이러한 옵션을 사용하는 것은 권장되지 않는다.
• 암호 라이브러리 구현자는 폐기 예정 및 실험적 암호 기능을 제공할 수 있지만, 라이브러리 옵션과 같이 개발자가 명시적으로 요청한 경우에만 그렇게 하고, 애플리케이션에 폐기 예정 또는 실험적 암호가 활성화되었음을 라이브러리가 경고하도록 하는 것이 권장된다.
• 애플리케이션 개발자는 여러 사전 설정 암호 라이브러리 구성 중에서 선택하고, 암호 옵션과 매개변수를 수정하거나 실험적 또는 폐기 예정 암호를 사용하는 것을 피하는 것이 권장된다.

위의 지침은 유용한 암호 옵션과 매개변수가 아키텍처의 하위 계층에서 제공되도록 하면서도, 각 옵션의 이점과 단점의 균형을 완전히 이해하지 못할 수 있는 애플리케이션 개발자에게 그러한 옵션과 매개변수가 노출되지 않도록 하기 위한 것이다.

5.1 암호 스위트의 버전 관리 절은 특정 cryptographic suite의 시의성에 관한 비교적 이해하기 쉬운 정보를 제공하는 것의 중요성을 강조했고, 5.2 애플리케이션 개발자 보호 절은 지정해야 할 옵션 수를 최소화하는 것을 더 강조했다. 실제로 3. 암호 스위트 절은 알고리즘, 변환, 해싱, 직렬화의 상세한 명세를 포함하는 cryptographic suites에 대한 요구 사항을 나열한다. 따라서 cryptographic suite의 이름은 이 모든 세부 정보를 포함할 필요가 없으며, 이는 5.1 암호 스위트의 버전 관리 절에서 언급한 매개변수 기반 버전 관리가 필요하지도 바람직하지도 않음을 의미한다.

cryptographic suites에 권장되는 명명 규칙은 서명 알고리즘 식별자와 옵션 식별자(cryptosuite가 호환되지 않는 구현 옵션을 지원하는 경우)를 하이픈으로 구분하고, 그 뒤에 하이픈과 해당 suite가 제안된 대략적인 연도를 붙인 문자열이다.

예를 들어 [DI-EDDSA]는 EdDSA 디지털 서명에 기반하고, 정규화 접근 방식에 기반한 두 개의 호환되지 않는 옵션을 지원하며, 대략 2022년에 제안되었으므로 두 개의 서로 다른 cryptosuite 이름을 갖게 된다. eddsa-rdfc-2022 및 eddsa-jcs-2022.

[DI-ECDSA]는 ECDSA 디지털 서명에 기반하고, [DI-EDDSA]와 같은 두 개의 호환되지 않는 정규화 접근 방식을 지원하며, 두 가지 대체 타원 곡선 및 해시 집합을 통해 두 가지 보안 수준(128비트 및 192비트)을 지원하지만, cryptosuite 이름은 두 개뿐이다. ecdsa-rdfc-2019 및 ecdsa-jcs-2019. 보안 수준과 해당 곡선 및 해시는 검증에 사용되는 공개 키의 multi-key 형식에서 결정된다.

암호 민첩성은 자주 연결되는 정보 보안 시스템이 여러 암호학적 기본 요소 및/또는 알고리즘 사이를 전환하도록 지원하게 설계하는 관행이다. 암호 민첩성의 주요 목표는 시스템 인프라에 파괴적인 변경을 가하지 않고도 시스템이 새로운 암호학적 기본 요소와 알고리즘에 빠르게 적응할 수 있게 하는 것이다. 따라서 SHA-1 알고리즘과 같은 특정 암호학적 기본 요소가 더 이상 사용하기 안전하지 않다고 판단되면, 시스템은 간단한 구성 파일 변경을 통해 더 새로운 기본 요소를 사용하도록 재구성될 수 있다.

암호 민첩성은 정보 보안 시스템의 클라이언트와 서버가 정기적으로 접촉할 때 가장 효과적이다. 그러나 특정 암호 알고리즘으로 보호되는 메시지가 검증 가능한 자격 증명처럼 오래 지속되거나, 클라이언트(보유자)가 서버(발급자)에 쉽게 다시 접촉하지 못할 수 있는 경우, 암호 민첩성은 원하는 보호를 제공하지 못한다.

암호 계층화는 거의 연결되지 않는 정보 보안 시스템이 여러 기본 요소 및/또는 알고리즘을 동시에 사용하도록 설계하는 관행이다. 암호 계층화의 주요 목표는 하나 이상의 암호 알고리즘 또는 기본 요소가 실패하더라도 페이로드에 대한 암호학적 보호를 잃지 않고 시스템이 살아남도록 하는 것이다. 예를 들어 단일 정보 조각을 RSA, ECDSA, Falcon 알고리즘으로 병렬 디지털 서명하면, 세 디지털 서명 알고리즘 중 두 개가 실패하더라도 살아남을 수 있는 메커니즘을 제공할 수 있다. 768비트 키를 사용하는 RSA 디지털 서명과 같은 특정 암호학적 보호가 손상된 경우에도, 시스템은 손상되지 않은 암호학적 보호를 계속 활용하여 정보를 보호할 수 있다. 개발자는 1년 이상 보호해야 할 수 있는 모든 서명된 콘텐츠에 대해 이 기능을 활용할 것이 강력히 권장된다.

이 명세는 두 형태의 민첩성을 모두 제공한다. 하나의 알고리즘에서 다른 알고리즘으로 쉽게 전환할 수 있게 하는 암호 민첩성을 제공한다. 또한 일반적으로 병렬로 여러 암호 알고리즘을 동시에 사용할 수 있게 하는 암호 계층화를 제공하여, 정보를 보호하는 데 사용된 것들 중 어느 것이든 다른 것에 의존하거나 다른 것을 요구하지 않고 사용할 수 있게 하면서도, 디지털 증명 형식을 개발자가 사용하기 쉽게 유지한다.

증명은 proofValue를 포함하며, 그 안에는 암호학적 증명과 관련된 여러 매개변수가 포함될 수 있다. 예를 들어 Data Integrity ECDSA Cryptosuites v1.0 명세의 선택적 공개 알고리즘은 선택적으로 공개 가능한 각 항목마다 하나씩, 여러 암호학적 서명을 proofValue 안에 포함한다. 이는 애플리케이션 개발자가 이 기술을 더 쉽고 안전하게 사용할 수 있도록 하기 위해 수행되었다.

이 명세는 명세 작성자가 애플리케이션 계층에서 거의 필요하지 않은 정보를 추상화하기 위해 단일 값을 사용할 것을 강력히 권장한다. 이미지를 표현하는 data: URL이 많은 이미지 렌더링 매개변수를 하나의 값으로 캡슐화하는 것처럼, proofValue 속성(및 기타 유사한 속성)은 애플리케이션 개발자에게 유용하지 않은 정보를 추상화하여, 애플리케이션에 중요한 필드를 식별하기 쉽게 만든다. 이러한 방식으로 정보를 추상화하면 개발자가 다루기 쉬운 데이터 구조가 되며, 예를 들어 중요한 속성을 추가하거나 제거하는 프로그래밍 오류로 인해 암호 계층에 부정적인 영향을 주는 우발적 손상에 덜 취약해진다.

이 명세의 데이터 무결성 설계는 일반적으로 암호 계층에만 유용한 정보를 단일 속성으로 추상화하여, 애플리케이션 개발자의 부담을 줄이고 시스템의 보안을 향상시킨다.

때때로 암호학적 보호 과정에서 보호되는 데이터를 변환하는 것이 유익하다. 이러한 "인라인" 변환은 특정 유형의 암호학적 보호가 그것이 담긴 데이터 형식에 구애받지 않도록 할 수 있다. 예를 들어 일부 Data Integrity cryptographic suites는 RDF Dataset Canonicalization [RDF-CANON]을 사용하며, 이는 초기 표현을 정규 형식 [N-QUADS]으로 변환한 뒤, 이를 직렬화하고 해시 처리하며 디지털 서명한다. 보호된 데이터를 표현하는 어떤 구문이든 이 정규 형식으로 변환될 수 있는 한, 디지털 서명은 검증될 수 있다. 이를 통해 정보에 대한 동일한 디지털 서명을 JSON, CBOR, YAML 및 기타 호환 구문으로 표현할 수 있으며, 각 구문마다 암호학적 증명을 만들 필요가 없다.

다양한 구문에서 동일한 디지털 서명을 표현할 수 있는 것은 유익하다. 시스템은 종종 자신이 동작하는 네이티브 데이터 형식을 가지고 있기 때문이다. 예를 들어 어떤 시스템은 JSON 데이터를 기준으로 작성되고, 다른 시스템은 CBOR 데이터를 기준으로 작성된다. 변환이 없으면 내부적으로 CBOR로 데이터를 처리하는 시스템도 디지털 서명된 데이터 구조를 JSON으로 저장해야 한다 (또는 그 반대). 이는 데이터를 이중으로 저장하게 만들고, 데이터베이스에 저장된 서명되지 않은 표현이 서명된 표현에서 우발적으로 벗어나는 경우 보안 공격 표면을 증가시킬 수 있다. 변환을 사용하면 디지털 증명이 네이티브 데이터 형식 안에 존재할 수 있어, 시간이 지남에 따라 달리 감지하기 어려운 데이터베이스 드리프트를 방지하는 데 도움이 된다.

이 명세는 "인라인" 데이터 변환을 활용하여 서명된 정보의 중복을 요구하지 않도록 설계되었다. 애플리케이션 개발자는 자신의 애플리케이션의 네이티브 데이터 형식으로 암호학적으로 보호된 데이터를 다루고, 암호학적 증명을 보호되는 데이터와 분리하여 저장하지 않을 것이 강력히 권장된다. 개발자는 또한 애플리케이션 저장소에 기록되고 읽힐 때 암호학적으로 보호된 데이터가 변조되지 않았음을 정기적으로 확인할 것이 강력히 권장된다.

RDF Dataset Canonicalization [RDF-CANON]과 같은 일부 변환에는 공격자가 과도한 처리 사이클을 소비하게 만드는 데 사용할 수 있는 입력 데이터 세트에 대한 완화책이 있다. 이러한 공격 유형은 dataset poisoning이라고 하며, 모든 현대 RDF Dataset canonicalizers는 이러한 종류의 나쁜 입력을 감지하고 처리를 중단해야 한다. RDF Dataset Canonicalization의 테스트 스위트에는 이러한 완화책이 모든 적합한 구현에 존재하는지 보장하기 위해 오염된 데이터셋이 포함되어 있다. 일반적으로 변환을 사용하는 cryptographic suite 명세는 이러한 종류의 공격을 완화해야 하며, 구현자는 자신이 사용하는 소프트웨어 라이브러리가 이러한 완화책을 강제하는지 확인할 것이 강력히 권장된다. 이러한 공격은 고의로 연결을 느리게 하여 서버의 연결을 고갈시키는 HTTP 클라이언트와 같은 리소스 고갈 공격과 같은 일반 범주에 속한다. 구현자는 방어적 보안 전략을 구현할 때 이러한 종류의 공격을 고려하는 것이 권장된다.

어떤 데이터 무결성 증명으로 보호되는 데이터는 변환된 데이터이다. 변환된 데이터는 특정 cryptosuite가 지정한 변환 알고리즘에 의해 생성된다. 이 보호 메커니즘은 입력 데이터에 어떤 종류의 변환도 수행하지 않는 일부 더 전통적인 디지털 서명 메커니즘과 다르다. 변환의 이점은 5.6 변환 절에 자세히 설명되어 있다.

예를 들어 cryptosuites인 ecdsa-jcs-2019 및 eddsa-jcs-2022는 JSON Canonicalization Scheme (JCS)을 사용하여 데이터를 정규화된 JSON으로 변환한 뒤, 이를 암호학적으로 해시 처리하고 디지털 서명한다. 이 접근 방식의 한 가지 이점은 공백, 탭, 줄바꿈과 같이 서명되는 정보의 의미에 영향을 주지 않는 서식 문자를 추가하거나 제거해도 디지털 서명이 무효화되지 않는다는 것이다. 더 전통적인 디지털 서명 메커니즘에는 이러한 기능이 없다.

cryptosuites인 ecdsa-rdfc-2019 및 eddsa-rdfc-2022와 같은 다른 것들은 RDF Dataset Canonicalization을 사용하여 데이터를 정규화된 N-Quads [N-QUADS]로 변환한 뒤, 이를 암호학적으로 해시 처리하고 디지털 서명한다. 이 접근 방식의 한 가지 이점은 암호학적 서명이 JSON, YAML, CBOR과 같은 다양한 구문으로 이식 가능하며, 서명을 무효화하지 않는다는 것이다. 더 전통적인 암호학적 서명 메커니즘에는 이러한 기능이 없다.

구현자와 개발자는 데이터 무결성 증명을 포함하는 정보를, 그 증명이 검증되었고, 반환된 모든 데이터가 성공적으로 보호되었음을 확인한 소프트웨어 라이브러리의 반환값으로 검증된 데이터가 제공되지 않는 한 신뢰하지 않을 것이 강력히 권장된다.

애플리케이션 데이터의 검사 가능성은 시스템 효율성과 개발자 생산성에 영향을 준다. base 인코딩된 바이너리 데이터와 같이 암호학적으로 보호된 애플리케이션 데이터가 데이터베이스와 같은 애플리케이션 하위 시스템에서 쉽게 처리되지 않으면, 암호학적으로 보호된 정보를 다루는 데 드는 노력이 증가한다. 예를 들어 데이터베이스에 네이티브로 저장되고 색인될 수 있는 암호학적으로 보호된 페이로드는 다음과 같은 더 단순한 시스템을 낳는다.

• 보호된 정보를 변경하지 않고 기존 업계 표준 데이터베이스 기능을 활용하는 이점을 얻는다.
• 데이터의 한 사본은 메시지와 디지털 서명을 보존하고, 다른 사본은 메시지만 저장 및 색인하며 시스템 동작을 구동하는 식의 데이터 중복 복잡성을 피한다.
• 여러 중첩 base 인코딩 페이로드를 가진 중첩 디지털 서명 데이터를 직렬화하고 역직렬화하는 것처럼, 보호된 정보를 구조적으로 수정해야 하는 맞춤형 해결책의 복잡성을 피한다.

마찬가지로, 여러 상위 네트워크 시스템에서 처리할 수 있는 암호학적으로 보호된 페이로드는 보안 아키텍처를 적절히 계층화할 수 있는 능력을 높인다. 예를 들어 상위 시스템이 들어오는 페이로드를 반복적으로 디코딩할 필요가 없으면, 공격에 적극적으로 대응하도록 상위 하위 시스템을 특화하여 시스템이 처리 부하를 분산할 수 있는 능력이 증가한다. 실질적인 조치를 취하기 전에 디지털 서명은 항상 확인되어야 하지만, 투명한 페이로드에 대해서는 식별자 기반 속도 제한, 서명 만료 확인, nonce/challenge 확인과 같은 다른 상위 검사를 수행하여 명백히 나쁜 요청을 거부할 수 있다.

또한 개발자가 시스템의 데이터를 쉽게 볼 수 없다면, 시스템 정확성을 쉽게 감사하거나 디버그하는 능력이 저해된다. 예를 들어 애플리케이션 개발자에게 base 인코딩된 애플리케이션 데이터를 잘라 붙여 넣도록 요구하면 개발이 더 어려워지고, 모든 메시지가 수동으로 운영되는 base 디코딩 도구를 거쳐야 하므로 명백한 버그를 놓칠 가능성이 높아진다.

그러나 데이터를 불투명하게 만드는 것이 올바른 설계 결정인 경우도 있다. 다른 애플리케이션 하위 시스템에서 처리할 필요가 없는 데이터와, 애플리케이션 개발자가 수정하거나 접근할 필요가 없는 데이터는 불투명 형식으로 직렬화될 수 있다. 예에는 디지털 서명 값, 암호학적 키 매개변수, 그리고 암호 라이브러리에서만 접근할 필요가 있고 애플리케이션 개발자가 수정할 필요가 없는 기타 데이터 필드가 포함된다. 또한 저장 시 암호화를 수행하는 데이터베이스처럼, 기본 하위 시스템이 불투명 데이터의 기본 복잡성을 애플리케이션 개발자에게 노출하지 않는 경우에는 데이터 불투명성이 적절한 예도 있다. 이러한 경우 애플리케이션 개발자는 투명한 애플리케이션 데이터 형식을 기준으로 계속 개발하고, 데이터베이스가 애플리케이션 데이터를 장기 저장소로 암호화 및 복호화하는 복잡성을 관리한다.

이 명세는 애플리케이션 데이터가 네이티브 형식에 남아 있고 불투명해지지 않으며, 디지털 서명과 같은 다른 암호학적 데이터는 불투명한 바이너리 인코딩 형식으로 유지되는 아키텍처를 제공하고자 한다. cryptographic suite 구현자는 자신의 suite를 설계할 때 데이터 불투명성의 적절한 사용을 고려하고, 애플리케이션 데이터를 불투명하게 만드는 것과 애플리케이션 계층에서 암호학적 데이터에 대한 접근을 제공하는 것 사이의 설계 절충을 평가할 것이 강력히 권장된다.

구현자는 검증 방법의 정의에서 제어 식별자 문서로 이동한 다음, 그 제어 식별자 문서가 또한 검증 방법에 대한 참조를 포함하는지 확인함으로써, 검증 방법이 특정 controller에 바인딩되어 있는지 보장한다. 이 과정은 검증 방법 검색 알고리즘에 설명되어 있다.

구현이 증명을 검증할 때, 증명 생성에 사용된 검증 방법이 제어 식별자 문서에 나열되어 있는지뿐 아니라, 검증 중인 증명을 생성하는 데 사용되도록 의도되었는지도 검증하는 것이 필수적이다. 이 과정은 "검증 관계 검증"으로 알려져 있다.

검증 관계를 검증하는 과정은 Controlled Identifiers v1.0 명세의 3.3 Retrieve Verification Method 절에 개략적으로 설명되어 있다.

이 과정은 개인 암호 키와 같은 암호학적 자료가 애플리케이션에 의해 의도하지 않은 목적으로 오용되지 않도록 보장하는 데 사용된다. 암호학적 자료 오용의 예는 검증 가능한 자격 증명을 발급하는 데 사용되도록 의도된 개인 암호 키가 대신 웹사이트에 로그인하는 데 사용되는 경우(즉, 인증에 사용되는 경우)이다. 검증 관계를 확인하지 않는 것은 위험한데, 일부 암호학적 자료의 제한 및 보호 프로필이 그 의도된 사용에 따라 결정될 수 있기 때문이다. 예를 들어 일부 애플리케이션은 한 가지 목적에만 암호학적 자료를 사용하도록 신뢰될 수 있고, 일부 암호학적 자료는 노트북의 암호화되지 않은 파일보다 데이터 센터의 하드웨어 보안 모듈에 저장되는 식으로 더 보호될 수 있다.

구현이 증명을 검증할 때, 증명 목적이 의도된 사용과 일치하는지 검증하는 것이 필수적이다.

이 과정은 증명이 애플리케이션에 의해 의도하지 않은 목적으로 오용되지 않도록 보장하는 데 사용되며, 이는 증명 생성자에게 위험하기 때문이다. 오용의 예는 검증 가능한 자격 증명에서 주장을 보호하기 위한 목적으로 명시된 증명이, 대신 웹사이트에 로그인하기 위한 인증에 사용되는 경우이다. 이 경우 증명 생성자는 무한한 수의 다른 당사자에게 배포될 것으로 예상한 여러 검증 가능한 자격 증명에 증명을 첨부했다. 웹사이트가 그러한 증명을 의도된 목적 대신 인증으로 잘못 수락하면, 이러한 당사자 중 누구든지 증명 생성자로 웹사이트에 로그인할 수 있다.

정규화와 같은 변환이 수행되는 방식은 시스템의 보안 특성에 영향을 줄 수 있다. 최선의 정규화 메커니즘 선택은 사용 사례에 달려 있다. 종종 원하는 보안 요구 사항을 만족하는 가장 단순한 메커니즘이 최선의 선택이다. 이 절은 이 명세에서 언급하는 두 가지 주요 정규화 메커니즘, 즉 JSON Canonicalization Scheme [RFC8785] 및 RDF Dataset Canonicalization [RDF-CANON] 중에서 구현자가 선택하는 데 도움이 되는 간단한 지침을 제공하려고 한다.

애플리케이션이 JSON만 사용하고 어떤 형태의 RDF 의미론에도 의존하지 않는다면, JSON Canonicalization Scheme [RFC8785]을 사용하는 cryptography suite를 사용하는 것이 매력적인 접근 방식이다.

애플리케이션이 JSON-LD를 사용하고 문서의 의미론을 보호해야 한다면, RDF Dataset Canonicalization [RDF-CANON]을 사용하는 cryptography suite를 사용하는 것이 매력적인 접근 방식이다.

구현자는 JWT [RFC7519] 및 CWT [RFC8392]와 같이, 데이터 안에 증명을 임베드하는 대신 암호학적 봉투로 감싸 데이터를 보호하며 변환을 수행하지 않는 다른 메커니즘도 사용할 수 있음을 조언받는다. 이러한 접근 방식은 이 명세에 자세히 설명된 접근 방식이 제공하는 일부 이점을 희생하는 대신, 일부 사용 사례에서 단순성의 장점을 가진다.

이 명세에서 사용하는 알고리즘 과정 중 하나는 정규화이며, 이는 변환의 한 유형이다. 정규화는 의미론적으로 동등한 다양한 방식으로 표현될 수 있는 정보를 입력으로 받아, 모든 출력을 "정규 형식"이라고 하는 하나의 방식으로 표현하는 과정이다.

정규화를 활용하는 결과 데이터 무결성 증명의 보안은 알고리즘의 정확성에 크게 의존한다. 예를 들어 정규화 알고리즘이 서로 다른 의미를 가진 두 입력을 같은 출력으로 변환한다면, 작성자의 의도가 검증자에게 잘못 표현될 수 있다. 이는 적대자에 의해 공격 벡터로 사용될 수 있다.

또한 입력의 의미론적으로 관련된 정보가 출력에 존재하지 않는다면, 공격자는 증명 검증이 실패하지 않게 하면서 그러한 정보를 메시지에 삽입할 수 있다. 이는 암호학적으로 메시지에 서명할 때 일반적으로 사용되는 또 다른 변환인 암호학적 해싱과 유사하다. 공격자가 다른 입력에서 동일한 암호학적 해시를 생성할 수 있다면, 그 암호학적 해시 알고리즘은 안전하다고 간주되지 않는다.

구현자는 입력을 해싱 과정으로 변환하는 데 사용할 모든 정규화 알고리즘이 적절히 검토되었는지 보장할 것을 강력히 권장한다. 적절한 검토에는 최소한 알고리즘 정확성에 대한 동료 검토를 거친 수학적 증명과의 연관성이 포함된다. 여러 구현과 표준화 조직의 전문가 검토가 선호된다. 구현자는 정보 정규화에 대한 공식 교육을 받았거나 알고리즘 정확성에 대한 동료 검토 수학적 증명을 만들 수 있는 현장 전문가에게 접근할 수 있는 경우가 아니라면, 새로운 메커니즘을 발명하거나 사용하는 것을 강력히 피해야 한다.

이 명세는 적합한 보호 문서의 증명을 검증할 때 네트워크 요청이 필요하지 않도록 설계되었다. 그러나 독자는 JSON-LD contexts 및 검증 방법이 네트워크 연결을 통해 가져올 수 있는 URL을 포함할 수 있다는 점에 유의할 수 있다. 이 우려는 검증 중 또는 검증 후 네트워크에서 로드될 수 있는 모든 URL에 존재한다.

가능한 한 구현자는 이러한 정보를 영구적으로 또는 적극적으로 캐시하여, 네트워크를 통해 이러한 URL을 가져와야 할 수 있는 구현의 공격 표면을 줄일 것이 강력히 권장된다. 예를 들어 JSON-LD contexts에 대한 캐싱 기법은 2.4 컨텍스트와 어휘 절에 설명되어 있으며, did:key [DID-KEY]와 같은 일부 검증 방법은 네트워크에서 전혀 가져올 필요가 없다.

특정 HTTP URL 기반 검증 방법 인스턴스를 처음 만나는 경우처럼 캐시된 정보를 사용할 수 없는 경우, 구현자는 네트워크에서 리소스를 가져올 수 있는 모든 과정에서 서비스 거부 공격을 완화하기 위해 방어적 조치를 사용할 것이 주의된다.

이 명세에서 설명하는 문서 보호 기술은 일반화된 성격을 가지므로, 그 사용의 보안상 함의가 독자에게 즉시 명확하지 않을 수 있다. 완전한 소프트웨어 시스템에서 고려해야 할 수 있는 보안 우려의 종류를 이해하기 위해, 구현자는 이 기술이 검증 가능한 자격 증명 생태계 [VC-DATA-MODEL-2.0]에서 어떻게 사용되는지 읽을 것이 강력히 권장된다. 자세한 내용은 Verifiable Credential Security Considerations 절을 참조하라.

디지털 서명된 페이로드에 여러 검증자가 보는 데이터가 포함되어 있으면, 그것은 상관관계의 지점이 된다. 그러한 데이터의 예로 쇼핑 로열티 카드 번호가 있다. 상관 가능한 데이터는 검증자에 의해 추적 목적으로 사용될 수 있으며, 이는 때때로 개인정보 보호 기대를 위반할 수 있다. 일부 데이터가 추적에 사용될 수 있다는 사실은 즉시 명확하지 않을 수 있다. 그러한 상관 가능한 데이터의 예에는 정적 디지털 서명 또는 이미지의 암호학적 해시가 포함되지만, 이에 한정되지는 않는다.

상관 가능한 추적 데이터가 전혀 없으면서도 주어진 상호작용에서 페이로드가 신뢰할 수 있다는 일정 수준의 보증을 제공하는 디지털 서명된 페이로드를 만들 수 있다. 이러한 특성은 비연결성이라고 하며, 디지털 서명된 페이로드에 상관 가능한 데이터가 사용되지 않도록 보장하면서도 일정 수준의 신뢰를 제공한다. 그 충분성은 각 검증자가 결정해야 한다.

모든 사용 사례가 비연결성을 요구하거나 허용하는 것은 아니라는 점을 이해하는 것이 중요하다. 위험 물질을 운송하고 저장하는 조직과 개인을 상관시키는 것처럼, 규제 또는 안전상의 이유로 연결성과 상관관계가 필요한 사용 사례가 있다. 비연결성은 특정 상호작용에 대해 개인정보 보호 기대가 있을 때 유용하다.

일정 수준의 비연결성을 제공할 수 있는 메커니즘은 적어도 두 가지가 있다. 첫 번째 방법은 메시지에 사용된 어떤 데이터 값도 미래 메시지에서 다시 반복되지 않도록 보장하는 것이다. 두 번째는 반복되는 데이터 값이 충분한 군중 개인정보 보호를 제공하여, 해당 상호작용에서 일정 수준의 개인정보 보호를 기대하는 엔터티를 상관시키는 것이 실질적으로 불가능해지도록 보장하는 것이다.

비연결성을 달성하기 위해 다양한 방법을 사용할 수 있다. 이러한 방법에는 메시지가 상관관계 목적으로 사용할 수 있는 정보가 없는 단일 사용 bearer token이 되도록 보장하는 것, 충분한 수준의 군중 개인정보 보호를 보장하는 속성을 사용하는 것, 그리고 메시지를 제시하는 엔터티가 제시되는 메시지의 신뢰를 손상시키지 않으면서 새로운 서명을 다시 생성할 수 있게 하는 cryptosuites를 사용하는 것이 포함된다.

선택적 공개는 이전에 서명된 메시지(즉, 그 생성자가 서명한 메시지)의 수신자가 그 일부의 검증 가능성을 해치지 않고 메시지의 일부만 공개할 수 있게 하는 기법이다. 예를 들어 자동차를 렌트하기 위한 목적으로 디지털 운전면허증을 선택적으로 공개할 수 있다. 이는 면허증에서 발급 기관, 면허 번호, 생년월일, 허가된 자동차 등급만 공개하는 것을 포함할 수 있다. 이 경우 면허 번호는 상관 가능한 정보이지만, 운전자의 전체 이름과 주소가 공유되지 않기 때문에 어느 정도의 개인정보 보호가 보존된다는 점에 유의하라.

모든 소프트웨어 또는 cryptosuites가 선택적 공개를 제공할 수 있는 것은 아니다. 메시지 작성자가 그 메시지가 수신자에 의해 선택적으로 공개 가능하기를 원한다면, 특정 메시지에서 선택적 공개를 활성화해야 하며, 둘 다 이를 지원하는 cryptosuite를 사용해야 한다. 작성자는 메시지의 특정 부분을 공개하도록 의무화할 수도 있다. 메시지의 일부 내용을 선택적으로 공개하려는 수신자는 이 기법을 수행할 수 있는 소프트웨어를 사용해야 한다. 선택적 공개를 지원하는 cryptosuite의 예는 bbs-2023이다.

비연결성을 보존하지 않는 방식으로 정보를 선택적으로 공개하는 것도 가능하다. 예를 들어 배송과 관련된 검사 결과를 공개하고자 할 수 있으며, 여기에는 규제 요구 사항 때문에 상관 가능해야 할 수 있는 배송 식별자 또는 로트 번호가 포함된다. 그러나 전체 검사 결과의 공개는 필요하지 않을 수 있고, pass/fail 상태만 선택적으로 공개하는 것으로 충분하다고 판단될 수 있다. 개인정보를 보호하면서 정보를 공개하는 방법에 대한 자세한 내용은 6.1 비연결성 절을 참조하라.

2.1.2 증명 체인에 정의된 previousProof 기능을 사용할 때, 구현은 하나 이상의 이전 증명 위에 디지털 서명해야 하며, 이를 보호된 페이로드에 포함해야 한다. 이는 필연적으로 이전 증명을 추가한 각 엔터티와 관련된 정보를 노출한다.

최소한 공개 키와 같은 이전 증명의 검증 방법은 증명 체인에서 다음 증명의 생성자가 보게 된다. 이전 증명의 생성자가 증명 체인에 포함될 의도가 없었다면 이는 개인정보 보호 우려가 될 수 있지만, 어떤 종류의 문서에든 부인 방지 디지털 서명을 추가할 때 피할 수 없는 결과이다.

그룹 서명과 같은 더 고급 암호학적 메커니즘을 사용하여 메시지 서명자의 신원을 숨기는 것이 가능하며, Data Integrity cryptographic suite가 이러한 개인정보 보호 우려를 완화하는 것도 가능하다.

증명 검증 중 또는 그 이후 네트워크에서 로드될 수 있는 모든 URL에는 지문화 우려가 존재한다. 이 명세는 적합한 보호 문서의 증명을 검증할 때 네트워크 요청이 필요하지 않도록 설계되었다. 그러나 독자는 JSON-LD contexts 및 검증 방법이 네트워크 연결을 통해 가져올 수 있는 리소스 URL을 포함할 수 있으며, 이로 인해 지문화 우려가 발생할 수 있다는 점에 유의할 수 있다.

예를 들어 적합한 보호 문서의 생성자는 JSON-LD contexts 및 검증 방법에 대해 문서별 고유 URL을 만들 수 있다. 그러한 문서를 검증할 때 검증자가 네트워크에서 해당 정보를 가져오면, 문서의 생성자에게 그 적합한 보호 문서에 대한 관심을 드러내게 되며, 이는 문서 생성자가 아닌 모든 엔터티의 개인정보 보호 기대와 불일치를 초래할 수 있다.

구현자는 URL 캐싱 및 네트워크에서 URL을 가져올 때 방어적으로 구현하는 것에 관한 5.14 네트워크 요청 절의 지침을 따를 것이 강력히 권장된다. 요청을 수행하는 클라이언트를 드러내지 않고 네트워크에서 리소스를 가져오기 위해 Oblivious HTTP와 같은 기법을 사용하는 것이 권장된다. 또한 적합한 보호 문서의 생성자가 개인정보 보호 기대를 위반할 수 있는 방식으로 지문화 URL을 사용하는지 판단하기 위해 휴리스틱을 사용할 수도 있다. 이러한 휴리스틱은 지문화 URL이 의심되는 문서를 처리할 수 있는 엔터티에게 경고를 표시하는 데 사용될 수 있다.

변환, 즉 정규화가 수행되는 방식은 시스템의 개인정보 보호 특성에 영향을 줄 수 있다. 최선의 정규화 메커니즘 선택은 사용 사례에 달려 있다. 이 절은 개인정보 보호 관점에서 이 명세에서 언급하는 두 가지 주요 정규화 메커니즘, 즉 JSON Canonicalization Scheme [RFC8785] 및 RDF Dataset Canonicalization [RDF-CANON] 중에서 구현자가 선택하는 데 도움이 되는 간단한 지침을 제공하려고 한다.

애플리케이션이 보호된 문서에서 정보를 선택적으로 공개할 필요가 없고, JSON-LD도 활용하지 않는다면, JSON Canonicalization Scheme [RFC8785]은 매력적인 접근 방식이다.

애플리케이션이 JSON-LD를 사용하고 보호된 문서에서 정보의 선택적 공개가 필요할 수 있다면, RDF Dataset Canonicalization [RDF-CANON]을 사용하는 cryptography suite를 사용하는 것이 매력적인 접근 방식이다.

구현자는 SD-JWTs [SD-JWT]와 같이, 변환을 수행하지 않고 데이터 안에 증명을 임베드하는 대신 암호학적 봉투로 감싸 데이터를 보호하는 다른 선택적 공개 메커니즘도 사용할 수 있음을 조언받는다. 이 접근 방식은 이 명세에 자세히 설명된 접근 방식이 제공하는 일부 이점을 희생하는 대신, 일부 사용 사례에서 단순성의 장점을 가진다.

이 명세에서 설명하는 문서 보호 기술은 일반화된 성격을 가지므로, 그 사용의 개인정보 보호상 함의가 독자에게 즉시 명확하지 않을 수 있다. 완전한 소프트웨어 시스템에서 고려해야 할 수 있는 개인정보 보호 우려의 종류를 이해하기 위해, 구현자는 이 기술이 검증 가능한 자격 증명 생태계 [VC-DATA-MODEL-2.0]에서 어떻게 사용되는지 읽을 것이 강력히 권장된다. 자세한 내용은 Verifiable Credential Privacy Considerations 절을 참조하라.

이 명세는 암호학적 증명의 유효 기간과 관련된 날짜와 시간을 표현할 수 있게 한다. 증명이 처리되고 허용 가능한 시간 범위를 벗어난 것으로 감지되는 경우, 이 정보는 개인에게 간접적으로 노출될 수 있다. 이러한 날짜와 시간을 개인에게 노출할 때 구현자는 표시 소프트웨어에서 날짜와 시간을 표현할 때의 문화적 규범과 로케일을 고려할 것이 강력히 권장된다. 이러한 고려 사항에 더해, 정보를 받는 개인의 인지적 부담을 줄이는 방식으로 시간 값을 표시하는 것이 권장되는 모범 사례이다.

예를 들어 특정 디지털 서명 정보 집합의 만료 날짜를 전달할 때, 구현자는 정확성을 최적화하는 표현보다 이해하기 쉬운 언어를 사용하여 만료 시각을 표시할 것이 강력히 권장된다. 만료 시간을 "This ticket expired three days ago."라고 표시하는 것이 "This ticket expired on July 25th 2023 at 3:43 PM."과 같은 표현보다 선호된다. 전자는 후자보다 이해하기 쉬운 상대 시간을 제공하며, 후자의 시간은 개인이 머릿속으로 계산해야 하고 그러한 계산을 할 수 있다고 전제한다.