Verifiable Credential Data Integrity 1.0

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

객체에 데이터 무결성 증명을 표현할 때는 proof 속성을 사용해야 한다. 검증가능한 크리덴셜 내의 proof 속성은 명명된 그래프다. 존재한다면 그 값은 단일 객체이거나 객체의 비순서 집합이어야 하며, 아래 속성들을 사용하여 표현된다:

id

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

type

증명의 구체적 타입은 URL [URL]로 대응되는 문자열로 명시해야 한다. 증명 타입의 예로 DataIntegrityProof와 Ed25519Signature2020이 있다. 증명 타입은 증명을 보안하고 검증하는 데 어떤 다른 필드가 필요한지를 결정한다.

proofPurpose

증명이 생성된 이유는 URL [URL]로 대응되는 문자열로 명시해야 한다. 증명 목적은 증명이 의도된 목적 이외의 목적에 적용되어 오용되는 것을 막는 안전장치 역할을 한다. 예를 들어 이 값이 없으면 증명 생성자가 로그인 과정(authentication) 중에 보통 검증가능한 크리덴셜을 생성하는 데 사용되는 암호학적 자료(assertionMethod)를 사용하도록 속아, 의도한 행위(단지 웹사이트에 로그인하는 것) 대신 자신이 결코 만들려 하지 않았던 검증가능한 크리덴셜이 생성되는 결과가 될 수 있다.

verificationMethod

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

cryptosuite

증명을 검증하는 데 사용할 수 있는 암호 스위트에 대한 식별자. 더 자세한 정보는 3. 암호 스위트를 참고하라. 증명 type이 DataIntegrityProof이면 cryptosuite를 명시해야 하며, 그 외의 경우 cryptosuite를 명시할 수 있다. 명시된다면 그 값은 문자열이어야 한다.

created

증명이 생성된 날짜와 시간은 선택 사항이며, 포함된다면 값의 끝에 Z로 표기되는 협정 세계시(UTC)로, 또는 UTC 기준 시간대 오프셋과 함께, [XMLSCHEMA11-2] dateTimeStamp 문자열로 명시해야 한다. 적합 프로세서는 오프셋 없이 잘못 직렬화된 시간 값을 소비하기로 선택할 수 있다. 오프셋이 없는 잘못 직렬화된 시간 값은 UTC로 해석되어야 한다.

expires

expires 속성은 선택 사항이며, 존재한다면 증명이 언제 만료되는지를 명시한다. 존재한다면 값의 끝에 Z로 표기되는 협정 세계시(UTC)로, 또는 UTC 기준 시간대 오프셋과 함께, [XMLSCHEMA11-2] dateTimeStamp 문자열이어야 한다. 적합 프로세서는 오프셋 없이 잘못 직렬화된 시간 값을 소비하기로 선택할 수 있다. 오프셋이 없는 잘못 직렬화된 시간 값은 UTC로 해석되어야 한다.

domain

domain 속성은 선택 사항이다. 이는 증명이 사용되도록 의도된 하나 이상의 보안 도메인을 전달한다. 명시된다면 그 연관된 값은 문자열이거나 문자열의 비순서 집합이어야 한다. 검증자는 그 값을 사용하여 증명이 자신이 동작하고 있는 보안 도메인에서 사용되도록 의도되었는지 확인하는 것이 좋다. domain 매개변수의 명시는 검증자가 증명 생성자에게 알려진 보안 도메인 내에서 동작하는 챌린지-응답 프로토콜에서 유용하다. 도메인 값의 예로는 domain.example(DNS 도메인), https://domain.example:8443 (웹 출처), mycorp-intranet(맞춤 텍스트 문자열), b31d37d4-dd59-47d3-9dd8-c973da43b63a(UUID)가 있다.

challenge

domain이 명시된 경우 증명에 포함하는 것이 좋은 문자열 값. 그 값은 특정 도메인과 시간 구간에 대해 한 번 사용된다. 이 값은 재전송 공격을 완화하는 데 사용된다. challenge 값의 예로는 1235abcd6789, 79d34551-ae81-44ae-823b-6dadbab9ebd4, ruby가 있다.

proofValue

명시된 verificationMethod를 사용하여 디지털 증명을 검증하는 데 필요한 base 인코딩된 이진 데이터를 표현하는 문자열 값. 그 값은 이진 데이터를 표현하기 위해 Controlled Identifiers v1.0 규격의 2.4 Multibase 절에 기술된 헤더와 인코딩을 사용해야 한다. 이 값의 내용은 특정 암호 스위트에 의해 결정되며 그 암호 스위트에 대한 증명 추가 알고리즘이 생성한 증명 값(proof value)으로 설정된다. 디지털 증명을 검증하는 데 필요한 데이터를 인코딩하기 위해, 이 속성 대신 암호 스위트가 명시한 다른 인코딩을 갖는 대체 속성이 사용될 수 있다.

previousProof

previousProof 속성은 선택 사항이다. 존재한다면 그것은 문자열 값이거나 문자열 값의 비순서 목록이어야 한다. 각 값은 또 다른 데이터 무결성 증명을 식별하며, 현재 증명이 검증된 것으로 간주되려면 그것들이 모두 또한 검증되어야 한다. 이 속성은 2.1.2 증명 체인 절에서 사용된다.

nonce

증명 생성자가 제공하는 선택적 문자열 값. 이 필드의 한 가지 용도는 결정론적으로 생성된 서명의 결과인 연결 가능성을 낮춤으로써 프라이버시를 높이는 것이다.

다음과 같이 JSON 문서에 증명을 추가할 수 있다:

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

다음 증명은 eddsa-jcs-2022 암호 스위트 [DI-EDDSA]를 사용하여 위 문서를 보안하는데, 이는 JSON 정규화 스킴(JCS) [RFC8785]을 사용하여 입력 데이터를 변환한 다음 에드워즈 디지털 서명 알고리즘(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 데이터셋 정규화 스킴 [RDF-CANON]을 사용하여 입력 데이터를 변환한 다음 타원 곡선 디지털 서명 알고리즘(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"
  }]
}

자신의 목적을 기술하는 증명은 그것이 다른 목적으로 오용되는 것을 막는 데 도움이 된다. 증명 목적은 검증자가 증명 생성자의 의도를 알 수 있게 하여, 메시지가 우발적으로 다른 목적으로 남용되지 않게 한다. 예를 들어 단지 (아마도 널리 공유될 의도로) 어써션을 하기 위해 서명된 메시지가 서비스에 인증하거나 (무언가를 하기 위해 역량을 호출하는 것과 같은) 어떤 행위를 취하기 위한 메시지로 남용되는 경우다.

증명 목적이 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

증명이, 널리 쓰이는 암호화 라이브러리가 사용하는 타원 곡선 Diffie-Hellman 키 합의와 같은 키 합의 프로토콜에 사용됨을 나타낸다.

capabilityDelegation

증명이 역량을 위임하는 데에만 사용될 수 있음을 나타낸다. 더 자세한 내용은 Authorization Capabilities [ZCAP] 규격을 참고하라.

capabilityInvocation

증명이 역량을 호출하는 데에만 사용될 수 있음을 나타낸다. 더 자세한 내용은 Authorization Capabilities [ZCAP] 규격을 참고하라.

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

적합 보안 문서가 참조하는 자원이 문서가 보안된 이후 변경되지 않았음을 확인할 수 있도록, 구현자는 id 속성을 포함하는 임의의 객체에 digestMultibase라는 이름의 속성을 포함할 수 있다. 존재한다면 digestMultibase 값은 단일 문자열 값이거나 문자열 값의 리스트이어야 하며, 각각은 Multibase 인코딩된 Multihash 값이다.

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들을 이미 해석된 것으로 취급해야 하며, 그 해석된 문서는 아래의 해당 해시 값과 일치한다:

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

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

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

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

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

애플리케이션별 어휘와 규격의 작성자는 자신의 JSON-LD 컨텍스트와 어휘 파일이 위에서 기술한 캐싱 접근법이나 기능적으로 동등한 메커니즘을 사용하여 영구적으로 캐시 가능하도록 보장하는 것이 좋다.

구현체는 개발 중에는 애플리케이션별 JSON-LD 컨텍스트 파일을 네트워크에서 로드할 수 있으나, 프로덕션 환경에서는 보안 및 프라이버시 특성을 높이기 위해 적합 보안 문서가 사용하는 JSON-LD 컨텍스트 파일을 영구적으로 캐시하는 것이 좋다. 처리 속도 목표는 위에서 기술한 것과 같은 캐싱 접근법이나 기능적으로 동등한 메커니즘을 통해 달성될 수 있다.

어떤 발급자로부터든 어떤 컨텍스트를 사용해서든 임의의 검증가능한 크리덴셜이나 데이터 무결성이 보호된 다른 문서를 보유할 수 있는 디지털 지갑과 같은 일부 애플리케이션은, 프로덕션 환경에서 JSON-LD 컨텍스트 파일과 같은 외부에 링크된 자원을 로드할 수 있어야 할 수 있다. 이는 시간이 지남에 따라 생태계에서 사용자 선택권, 확장성, 탈중앙화된 업그레이드를 높일 것으로 기대된다. 그러한 애플리케이션의 작성자는 추가 고려사항을 위해 이 문서의 보안 및 프라이버시 절을 읽을 것을 권한다.

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

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

다양한 애플리케이션에서 연결 데이터 사용이 증가함에 따라, 연결 데이터 문서의 진정성과 무결성을 검증할 수 있어야 할 필요가 있다. 이 규격은 확장성과 조합성 같은 연결 데이터 기능을 희생하지 않으면서, 수학적 증명의 사용을 통해 데이터 문서에 인증과 무결성 보호를 더한다.

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

유효성 검사 과정에서, 증명에 사용된 검증 방법이 검증가능한 크리덴셜의 issuer나 검증가능한 프레젠테이션의 holder와 연관되어 있음을 보장하는 것이 중요한 일부 사용 사례가 있다. 그러한 연관을 확인하는 한 가지 방법은, 증명의 검증 방법의 controller 속성 값이 각각 issuer나 holder를 식별하는 데 사용된 URL 값과 일치하고, 그 검증 방법이 증명의 목적에 비추어 허용 가능한 검증 관계 아래에 표현되어 있음을 보장하는 것이다. 이 특정 연관은 각각 issuer나 holder가 증명을 검증하는 데 사용된 검증 방법의 제어자임을 나타낸다.

문서 작성자와 구현자는 created와 expires 속성을 사용하여 표현되는 증명의 유효 기간과, validFrom과 validUntil 속성을 사용하여 표현되는 크리덴셜의 유효 기간의 차이를 이해할 것을 권한다. 이 속성들이 때때로 동일한 유효 기간을 표현할 수도 있지만, 다른 때에는 일치하지 않을 수도 있다. 증명을 검증할 때는, 관심 시점(현재 시각일 수도 있고 다른 어떤 시각일 수도 있다)이 증명의 유효 기간 이내 (즉, created와 expires 사이)에 있음을 보장하는 것이 중요하다. 검증가능한 크리덴셜을 유효성 검사할 때는, 관심 시점이 크리덴셜의 유효 기간 이내 (즉, validFrom과 validUntil 사이)에 있음을 보장하는 것이 중요하다. 증명의 유효 기간이나 크리덴셜의 유효 기간 중 어느 하나를 검사하지 못하면, 거부되었어야 할 데이터를 받아들이는 결과가 될 수 있음에 유의하라.

마지막으로, 구현자는 검증가능한 크리덴셜에 연관된 폐기 정보와, 검증 방법의 폐기 및 만료 시각 사이에 차이가 있음을 이해할 것을 강력히 권한다. 검증 방법의 폐기 및 만료 시각은 각각 revocation과 expires 속성을 사용하여 표현되며, 비밀키가 침해되거나 만료되는 것과 같은 사건과 관련되고, 제어자의 보안 관행이나 그들이 언제 침해되었을 수 있는지와 같은 세부 사항을 드러낼 수 있는 타이밍 정보를 제공할 수 있다. 검증가능한 크리덴셜의 폐기 정보는 credentialStatus 속성을 사용하여 표현되며, 개인이 검증가능한 크리덴셜에 의해 부여된 권한을 잃는 것과 같은 사건과 관련되고, 타이밍 정보를 제공하지 않아 프라이버시를 향상시킨다.

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

이 설계 패턴을 활용하는 암호 스위트를 지정할 때, proof 값은 다음 형태를 취한다:

type

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

cryptosuite

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

proofValue

2.1 증명 절에 명시된 대로 proofValue 속성을 사용해야 한다.

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

다음 알고리즘은 증명 또는 증명 집합/체인을 담은 보안 문서에서 시작하여, 증명 집합이나 증명 체인에 증명을 점진적으로 추가하는 방법을 지정한다. 필요한 입력은 보안 데이터 문서(맵 securedDocument), 암호 스위트(암호 스위트 인스턴스 suite), 옵션 집합(맵 options)이다. 출력은 새로운 보안 데이터 문서(맵)다. 이 알고리즘이 문자열을 인코딩할 때는 언제나 UTF-8 인코딩을 사용해야 한다.

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

   이 단계는 명명된 그래프에 대한 참조를 추가하며, 증명 그래프에 담긴 모든 클레임의 사본을 추가한다. 이 단계는 현재 증명을 적용하기 전에 일치하는 증명들을 문서에 결속하므로 매우 중요하다. 문서에 대한 proof 값은 이 알고리즘의 이후 단계에서 갱신된다.

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

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

mediaType

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

documentBytes

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

cryptosuite

암호 스위트 인스턴스

expectedProofPurpose

proof가 검증자가 기대하는 이유로 증명 생성자에 의해 생성되었음을 보장하는 데 사용되는 선택적 문자열. 흔한 값은 2.2 증명 목적을 참고하라

domain

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

challenge

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

이 알고리즘은 항목이 다음과 같은 구조체인 검증 결과(verification result)를 반환한다:

verified

true 또는 false

verifiedDocument

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

mediaType

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

warnings

ProblemDetails의 리스트, 기본값은 빈 리스트

errors

ProblemDetails의 리스트, 기본값은 빈 리스트

어떤 단계가 "오류를 일으켜야 한다"라고 말하면, 이는 verified 값이 false이고 비어 있지 않은 errors 리스트를 가진 검증 결과가 반환되어야 한다는 뜻이다.

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

   verified

   cryptosuiteVerificationResult.verified

   verifiedDocument

   cryptosuiteVerificationResult.verifiedDocument

   mediaType

   mediaType

증명 집합이나 증명 체인에서, 보안 데이터 문서는 증명의 리스트(allProofs)를 담은 proof 속성을 가진다. 다음 알고리즘은 allProofs의 모든 증명을 검증함으로써 달성되는, 보안 데이터 문서의 진정성과 무결성을 확인하는 한 가지 방법을 제공한다. 특히 allProofs에 담긴 증명의 부분집합만 검증하고자 할 때는 다른 접근법도 가능하다. 증명의 부분집합만 검증하기 위해 다른 접근법을 취한다면, 그 부분집합에서 previousProof를 가진 어떤 증명이든 그것이 참조하는 증명들도 검증된 것으로 간주되어야만 그 증명이 검증된 것으로 간주될 수 있음에 유의하는 것이 중요하다.

필요한 입력은 보안 데이터 문서(securedDocument)다. allProofs의 각 증명에 대응하는 검증 결과의 리스트가 생성되고, 하나의 결합된 검증 결과가 출력으로 반환된다. 구현체는 결합된 검증 결과와 함께 다른 검증 결과 중 어느 것이나 및/또는 다른 메타데이터를 반환할 수 있다.

1. allProofs를 securedDocument.proof로 설정한다.
2. verificationResults를 빈 리스트로 설정한다.
3. allProofs의 각 proof에 대해 다음 단계를 수행한다:
   1. matchingProofs를 빈 리스트로 둔다.
   2. proof가 previousProof 속성을 담고 있고 그 속성의 값이 문자열이면, previousProof의 값과 일치하는 id 속성 값을 가진 allProofs의 원소를 matchingProofs에 추가한다. id 값이 previousProof의 값과 같은 증명이 allProofs에 존재하지 않으면, 오류를 일으켜야 하며 PROOF_VERIFICATION_ERROR 오류 유형을 전달하는 것이 좋다. previousProof 속성이 리스트이면, 그 리스트의 원소의 값과 일치하는 id 속성 값을 가진 allProofs의 각 원소를 추가한다. previousProof 리스트의 어떤 원소가 allProofs의 어떤 원소의 id 속성 값과도 일치하지 않는 id 속성 값을 가지면, 오류를 일으켜야 하며 PROOF_VERIFICATION_ERROR 오류 유형을 전달하는 것이 좋다.
   3. inputDocument를 proof 값이 제거된 securedDocument의 사본으로 둔 다음 inputDocument.proof를 matchingProofs로 설정한다.
      참고: 문서와 이전 증명 보안

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

   4. inputDocument에 대해 4.4 증명 검증 절의 알고리즘 4단계부터 8단계까지 실행한다. 예외가 일어나지 않으면 cryptosuiteVerificationResult를 verificationResults에 덧붙인다.
4. successfulVerificationResults를 빈 리스트로 설정한다.
5. combinedVerificationResult를 빈 구조체로 둔다. 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를 반환한다.

암호학은 비밀의 사용을 통해 정보를 보안한다. 필요한 비밀을 알면 특정 정보에 접근하는 것이 계산적으로 쉬워진다. 계산적으로 어려운 무차별 대입 노력이 비밀을 성공적으로 추측하면 동일한 정보에 접근할 수 있다. 모든 현대 암호학은 계산적으로 어려운 접근법이 시간이 지나도 계속 어렵게 유지될 것을 요구하는데, 과학과 수학의 돌파구로 인해 이것이 항상 성립하지는 않는다. 즉 암호학에는 유통기한이 있다.

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

매개변수 기반 버전 관리는 암호 스위트에 채택된 특정 암호 매개변수를 명시한다. 예를 들어 RSASSA-PKCS1-v1_5-SHA1과 같은 식별자를 사용할 수 있다. 이 방식의 이점은 잘 훈련된 암호학자가 그 식별자로 관여하는 모든 매개변수를 알아낼 수 있다는 것이다. 이 방식의 단점은 이런 종류의 식별자를 사용하는 사람들 대부분이 잘 훈련되어 있지 않아, 앞서 언급한 식별자가 더 이상 사용하기에 안전하지 않은 암호 스위트임을 이해하지 못한다는 것이다. 게다가 이런 지식 부족은 소프트웨어 개발자가 암호 스위트 식별자의 파싱을 일반화하여 어떤 암호 프리미티브 조합이든 허용되게 만들고, 그 결과 보안이 낮아지게 할 수 있다. 이상적으로는 암호 스위트를 대신 특정하고 허용 가능한 암호 매개변수 프로파일로 소프트웨어에 구현한다.

숫자 기반 버전 관리는 1.0이나 2.1 같은 주 버전 번호와 부 버전 번호를 명시할 수 있다. 숫자 기반 버전 관리는 특정한 순서를 전달하며 더 높은 버전 번호가 더 낮은 버전 번호보다 더 뛰어나다는 것을 시사한다. 이 접근법의 이점은 덜 전문적인 개발자가 이해하지 못할 수 있는 복잡한 매개변수를, 업그레이드가 적절할 수 있음을 전달하는 더 단순한 모델로 제거한다는 것이다. 이 접근법의 단점은 소프트웨어 버전 번호 증가가 흔히 소프트웨어가 계속 작동하는 데 업그레이드를 요구하지는 않기 때문에, 업그레이드가 필요한지가 분명하지 않다는 것이다. 이는 개발자가 특정 버전의 사용이 안전하다고, 실제로는 그렇지 않은데도 생각하게 만들 수 있다. 이상적으로는 소프트웨어에 암호 스위트를 사용하는 개발자에게 그 스위트의 지속적 보안을 위한 정기적 검토가 필요하다는 추가 신호가 주어질 것이다.

날짜 기반 버전 관리는 특정 암호 스위트의 특정 출시 날짜를 명시한다. 연도와 같은 날짜의 이점은 그 날짜가 비교적 오래되었는지 새로운지가 개발자에게 즉시 분명하다는 것이다. 오래된 날짜를 보면 개발자가 더 새로운 암호 스위트를 찾아 나서게 될 수 있는데, 매개변수 기반이나 숫자 기반 버전 관리 방식은 그렇지 않을 수 있다. 날짜 기반 버전의 단점은 어떤 암호 스위트는 5~10년 동안 만료되지 않을 수도 있어, 개발자가 더 새로운 암호 스위트를 찾아 나섰다가 더 새로운 것을 찾지 못하게 될 수 있다는 것이다. 이것이 불편할 수는 있지만, 더 안전한 생태계 행동을 낳는 불편이다.

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

암호 라이브러리 구현자는 흔히 암호 알고리즘 설계자와 규격 작성자가 만든 규격을 받아, 자신의 라이브러리를 사용하는 애플리케이션 개발자가 모든 옵션을 이용할 수 있도록 그것을 구현한다. 이는 특정 애플리케이션 개발자가 주어진 암호 배포에 어떤 기능 조합을 필요로 할지 모르기 때문일 수 있다. 흔히 모든 옵션이 애플리케이션 개발자에게 노출된다.

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

이 규격은 애플리케이션 개발자를 암호 라이브러리 구현자보다, 암호 규격 작성자보다, 암호 알고리즘 설계자보다 우선하여 보호하는 이해관계자 우선순위를 정한다. 이러한 우선순위를 고려하여 다음 권고가 이루어진다:

• 암호 알고리즘 설계자는 암호 라이브러리 구현자가 자신의 소프트웨어 라이브러리에 대해 더 쉽게 감사 가능한 보안 공격 표면을 갖도록, 옵션과 매개변수의 수를 가능한 한 적게 최소화할 것을 권장받는다 [RFC7696].
• 암호 규격 작성자는 가능하다면 암호 민첩성을 보장하면서도 하위 소프트웨어 라이브러리에 대한 감사 가능한 보안 공격 표면을 최소로 유지하도록, 옵션과 매개변수의 수를 가능한 한 적게 더욱 최소화할 것을 권장받는다.
• 암호 라이브러리 구현자는 가능하다면 알려진 정상 옵션·매개변수 조합을 애플리케이션 개발자에게 제공할 것을 권장받는다. 이상적으로는 타원 곡선 디지털 서명과 같은 임의의 알고리즘 클래스에 대해 두 개의 사전 설정 기본 구성이 있고, 이 사전 설정을 사용할 때 매개변수와 옵션을 세부 조정할 수 없을 것이다. 라이브러리 옵션은 전문가가 라이브러리 사용을 세부 조정하도록 제공될 수 있지만, 일반 애플리케이션 개발자층이 그 옵션을 사용하는 것은 지양되어야 한다.
• 암호 라이브러리 구현자는 폐기 예정이거나 실험적인 암호 기능을 제공할 수 있으나, 라이브러리 옵션과 같은 방법으로 개발자가 명시적으로 요청할 때에만, 그리고 라이브러리가 그 애플리케이션에 대해 폐기 예정이거나 실험적인 암호학이 활성화되었다는 경고를 생성하도록 하여, 그렇게 할 것을 권장받는다.
• 애플리케이션 개발자는 여러 사전 설정 암호 라이브러리 구성 중에서 선택하고, 암호 옵션과 매개변수를 수정하거나 실험적이거나 폐기 예정인 암호학을 사용하는 것을 피할 것을 권장받는다.

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

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

암호 스위트에 권장되는 명명 규칙은, 서명 알고리즘 식별자에, (암호 스위트가 호환되지 않는 구현 옵션을 지원하는 경우) 하이픈으로 구분된 옵션 식별자를 붙이고, 그 뒤에 하이픈과 그 스위트가 제안된 대략적인 연도의 표기를 붙여 구성한 문자열이다.

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

[DI-ECDSA]는 ECDSA 디지털 서명에 기반하고, [DI-EDDSA]와 동일한 호환되지 않는 두 정규화 접근법을 지원하며, 두 대안적 타원 곡선 및 해시 집합을 통해 서로 다른 두 보안 수준(128비트와 192비트)을 지원하지만, 암호 스위트 이름은 두 개뿐이다: ecdsa-rdfc-2019와 ecdsa-jcs-2019. 보안 수준과 그에 대응하는 곡선 및 해시는 검증에 사용되는 공개키의 멀티키 형식으로부터 결정된다.

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

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

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

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

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

이 규격은 규격 작성자가 애플리케이션 계층에서 거의 필요하지 않은 정보를 단일 값으로 추상화할 것을 강력히 권한다. 이미지를 표현하는 data: URL이 많은 이미지 렌더링 매개변수를 단일 값으로 캡슐화하는 것과 매우 유사하게, proofValue 속성(그리고 다른 유사한 속성들)은 애플리케이션에 중요한 필드의 식별을 단순화하기 위해 애플리케이션 개발자에게 유용하지 않은 정보를 추상화한다. 이런 식으로 정보를 추상화하면 개발자가 다루기 더 쉬우면서도, 예컨대 중요한 속성을 추가하거나 제거하여 암호 계층에 부정적 영향을 주는 프로그래밍 오류로 인한 우발적 손상에 덜 취약한 데이터 구조가 된다.

The design of data integrity in this specification abstracts information that is generally only useful to the cryptographic layer into a single property to ease the burden on application developers and to enhance the security of the system.

때때로 암호학적 보호 과정에서 보호되는 데이터를 변환하는 것이 유익하다. 그러한 "인라인" 변환은 특정 유형의 암호학적 보호가 그것이 담긴 데이터 형식에 구애받지 않게 할 수 있다. 예를 들어 일부 데이터 무결성 암호 스위트는 RDF 데이터셋 정규화 [RDF-CANON]를 활용하는데, 이는 초기 표현을 정규 형식 [N-QUADS]으로 변환한 다음 이를 직렬화하고, 해싱하고, 디지털 서명한다. 보호되는 데이터를 표현하는 어떤 구문이든 이 정규 형식으로 변환될 수 있는 한, 그 디지털 서명은 검증될 수 있다. 이는 정보에 대한 동일한 디지털 서명을 모든 구문마다 암호학적 증명을 만들 필요 없이 JSON, CBOR, YAML, 그리고 기타 호환 구문으로 표현할 수 있게 한다.

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

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

RDF 데이터셋 정규화 [RDF-CANON]와 같은 일부 변환은, 공격자가 과도한 처리 사이클을 소비하는 데 사용할 수 있는 입력 데이터셋에 대한 완화책을 갖추고 있다. 이 부류의 공격을 데이터셋 오염(dataset poisoning)이라고 하며, 모든 현대 RDF 데이터셋 정규화기는 이런 종류의 잘못된 입력을 감지하고 처리를 중단해야 한다. RDF 데이터셋 정규화의 테스트 스위트는 그러한 완화책이 모든 적합 구현체에 존재하도록 보장하기 위해 그러한 오염된 데이터셋을 포함한다. 일반적으로 말해, 변환을 사용하는 암호 스위트 규격은 이런 종류의 공격을 완화해야 하며, 구현자는 자신이 사용하는 소프트웨어 라이브러리가 이러한 완화책을 강제하는지 확인할 것을 강력히 권장받는다. 이러한 공격은 연결을 고의로 느리게 하여 서버의 연결을 고갈시키는 HTTP 클라이언트와 같은 모든 자원 고갈 공격과 같은 일반 범주에 속한다. 구현자는 방어적 보안 전략을 구현할 때 이런 종류의 공격을 고려할 것을 권한다.

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

예를 들어 ecdsa-jcs-2019와 eddsa-jcs-2022 같은 암호 스위트는 JSON Canonicalization Scheme (JCS)를 사용하여 데이터를 정규화된 JSON으로 변환한 다음, 이를 암호학적으로 해싱하고 디지털 서명한다. 이 접근법의 한 가지 이점은 공백, 탭, 개행처럼 서명되는 정보의 의미에 영향을 주지 않는 서식 문자를 추가하거나 제거해도 디지털 서명이 무효화되지 않는다는 것이다. 더 전통적인 디지털 서명 메커니즘은 이 능력이 없다.

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

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

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

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

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

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

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

이 규격은 애플리케이션 데이터가 네이티브 형식으로 남아 불투명해지지 않으면서, 디지털 서명과 같은 다른 암호 데이터는 그 불투명한 이진 인코딩 형태로 유지되는 아키텍처를 제공하려 노력한다. 암호 스위트 구현자는 자신의 스위트를 설계할 때 데이터 불투명성의 적절한 사용을 고려하고, 애플리케이션 데이터를 불투명하게 만드는 것과 애플리케이션 계층에서 암호 데이터에 대한 접근을 제공하는 것 사이의 설계 절충을 저울질할 것을 강력히 권장받는다.

구현자는 검증 방법의 정의에서 제어 식별자 문서로 이동한 다음, 그 제어 식별자 문서도 그 검증 방법에 대한 참조를 담고 있는지 확인함으로써, 검증 방법이 특정 제어자에 결속되어 있음을 보장한다. 이 과정은 검증 방법 조회 알고리즘에 기술되어 있다.

구현체가 증명을 검증할 때는, 증명을 생성하는 데 사용된 검증 방법이 제어 식별자 문서에 나열되어 있는지뿐 아니라, 검증되고 있는 증명을 생성하는 데 사용되도록 의도되었는지도 검증하는 것이 필수적이다. 이 과정을 "검증 관계 유효성 검사"라고 한다.

검증 관계를 유효성 검사하는 과정은 Controlled Identifiers v1.0 규격의 3.3 검증 방법 조회 절에 개괄되어 있다.

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

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

이 과정은 증명이 애플리케이션에 의해 의도되지 않은 목적으로 오용되지 않도록 보장하는 데 사용되는데, 이는 증명 생성자에게 위험하기 때문이다. 오용의 한 예는 목적이 검증가능한 크리덴셜의 어써션을 보안하는 것이라고 밝힌 증명이 대신 웹사이트에 로그인하기 위한 인증에 사용되는 경우다. 이 경우 증명 생성자는 무한한 수의 다른 당사자에게 배포될 것으로 기대한 임의의 수의 검증가능한 크리덴셜에 증명을 첨부했다. 웹사이트가 그러한 증명을 그 의도된 목적 대신 인증으로 잘못 받아들이면, 이 당사자들 중 누구든 증명 생성자로서 웹사이트에 로그인할 수 있다.

정규화와 같은 변환이 수행되는 방식은 시스템의 보안 특성에 영향을 줄 수 있다. 최선의 정규화 메커니즘을 선택하는 것은 사용 사례에 달려 있다. 흔히 원하는 보안 요구사항을 충족하는 가장 단순한 메커니즘이 최선의 선택이다. 이 절은 구현자가 이 규격에서 언급하는 두 주요 정규화 메커니즘, 즉 JSON Canonicalization Scheme [RFC8785]과 RDF 데이터셋 정규화 [RDF-CANON] 사이에서 선택하는 것을 돕기 위해 간단한 지침을 제공하려 시도한다.

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

애플리케이션이 JSON-LD를 사용하고 문서의 의미론을 보안해야 한다면, RDF 데이터셋 정규화 [RDF-CANON]를 사용하는 암호 스위트를 사용하는 것이 매력적인 접근법이다.

구현자는 또한 JWT [RFC7519]와 CWT [RFC8392]처럼, 증명을 데이터에 내장하는 대신 데이터를 암호학적 봉투로 감싸서 보안하며 변환을 수행하지 않는 다른 메커니즘도 이용 가능함을 안내받는다. 이러한 접근법은 이 규격에 상세히 설명된 접근법이 제공하는 이점 일부를 희생하는 대신, 일부 사용 사례에서 단순성 이점을 갖는다.

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

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

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

구현자는 입력을 해싱 과정으로 변환하는 데 사용될 모든 정규화 알고리즘이 제대로 검증되도록 보장할 것을 강력히 권장받는다. 제대로 된 검증은 최소한 알고리즘 정확성에 대한 동료 심사를 거친 수학적 증명과의 연관을 포함하며, 여러 구현체와 표준 제정 기관 전문가의 검증이 선호된다. 구현자는 정보 정규화에 대한 정식 교육을 받았거나 알고리즘 정확성에 대한 동료 심사를 거친 수학적 증명을 만들어낼 수 있는 해당 분야 전문가에 대한 접근이 있지 않은 한, 새로운 메커니즘을 발명하거나 사용하지 않을 것을 강력히 권장받는다.

이 규격은 적합 보안 문서의 증명을 검증할 때 네트워크 요청이 필요하지 않도록 설계되었다. 그러나 독자는 JSON-LD 컨텍스트와 검증 방법이 네트워크 연결을 통해 검색될 수 있는 URL을 담을 수 있음에 유의할 수 있다. 이 우려는 검증 중이나 후에 네트워크에서 로드될 수 있는 모든 URL에 존재한다.

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

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

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

디지털 서명된 페이로드가 여러 검증자에게 보이는 데이터를 담으면, 그것은 상관관계의 지점이 된다. 그러한 데이터의 예는 쇼핑 적립 카드 번호다. 상관 가능한 데이터는 검증자에 의해 추적 목적으로 사용될 수 있으며, 이는 때때로 프라이버시 기대를 침해할 수 있다. 어떤 데이터가 추적에 사용될 수 있다는 사실이 즉시 분명하지 않을 수 있다. 그러한 상관 가능한 데이터의 예로는 정적 디지털 서명이나 이미지의 암호 해시가 있으나 이에 국한되지 않는다.

상관 가능한 추적 데이터를 전혀 갖지 않으면서도 주어진 상호작용에 대해 페이로드가 신뢰할 만하다는 어느 정도의 확신을 제공하는 디지털 서명된 페이로드를 만드는 것이 가능하다. 이 특성을 연결 불가능성(unlinkability)이라고 하며, 이는 디지털 서명된 페이로드에 상관 가능한 데이터가 전혀 사용되지 않도록 보장하면서도 어느 정도의 신뢰를 제공하는데, 그 충분성은 각 검증자가 판단해야 한다.

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

어느 정도의 연결 불가능성을 제공할 수 있는 메커니즘이 적어도 두 가지 있다. 첫 번째 방법은 메시지에 사용된 어떤 데이터 값도 향후 메시지에서 결코 반복되지 않도록 보장하는 것이다. 두 번째는 반복되는 어떤 데이터 값이든 적절한 무리 프라이버시(herd privacy)를 제공하여, 그 상호작용에서 어느 정도의 프라이버시를 기대하는 엔티티를 상관시키는 것이 사실상 불가능해지도록 보장하는 것이다.

연결 불가능성을 달성하는 데 다양한 방법이 사용될 수 있다. 이러한 방법에는 메시지가 상관관계 목적으로 사용될 수 있는 정보가 없는 일회용 무기명 토큰이 되도록 보장하는 것, 적절한 수준의 무리 프라이버시를 보장하는 속성을 사용하는 것, 그리고 메시지를 제시하는 엔티티가 제시되는 메시지에 대한 신뢰를 훼손하지 않으면서 새로운 서명을 재생성할 수 있게 하는 암호 스위트를 사용하는 것이 포함된다.

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

모든 소프트웨어나 암호 스위트가 선택적 공개를 제공할 수 있는 것은 아니다. 메시지 저작자가 그 메시지를 수신자가 선택적으로 공개할 수 있게 하려면, 특정 메시지에 대해 선택적 공개를 활성화해야 하고 양측 모두 그것이 가능한 암호 스위트를 사용해야 한다. 저작자는 또한 메시지의 특정 부분을 공개하는 것을 필수로 만들 수도 있다. 메시지의 일부 내용을 선택적으로 공개하고자 하는 수신자는 그 기법을 수행할 수 있는 소프트웨어를 활용해야 한다. 선택적 공개를 지원하는 암호 스위트의 예는 bbs-2023이다.

연결 불가능성을 보존하지 않는 방식으로 정보를 선택적으로 공개하는 것도 가능하다. 예를 들어 어떤 화물에 관한 검사 결과를 공개하고자 할 수 있는데, 여기에는 규제 요구사항으로 인해 상관 가능해야 할 수 있는 화물 식별자나 로트 번호가 포함된다. 그러나 합격/불합격 상태만 선택적으로 공개하는 것으로 적절하다고 간주될 수 있으므로 전체 검사 결과의 공개는 필요하지 않을 수 있다. 프라이버시를 보존하면서 정보를 공개하는 것에 대한 더 자세한 정보는 6.1 연결 불가능성 절을 참고하라.

2.1.2 증명 체인에 정의된 previousProof 기능을 사용할 때, 구현체는 하나 이상의 이전 증명을 보안 페이로드에 포함하기 위해 그것들에 대해 디지털 서명해야 한다. 이는 불가피하게 이전 증명을 추가한 각 엔티티와 관련된 정보를 노출한다.

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

메시지 서명자의 신원을 숨기기 위해 그룹 서명(group signature)과 같은 더 고급 암호학적 메커니즘을 사용하는 것이 가능하며, 데이터 무결성 암호 스위트가 이 프라이버시 우려를 완화하는 것도 가능하다.

증명 검증 중이나 후에 네트워크에서 로드될 수 있는 모든 URL에 대해 핑거프린팅 우려가 존재한다. 이 규격은 적합 보안 문서의 증명을 검증할 때 네트워크 요청이 필요하지 않도록 설계되었다. 그러나 독자는 JSON-LD 컨텍스트와 검증 방법이 네트워크 연결을 통해 검색될 수 있어 핑거프린팅 우려로 이어지는 자원 URL을 담을 수 있음에 유의할 수 있다.

예를 들어 적합 보안 문서의 생성자는 JSON-LD 컨텍스트와 검증 방법에 대해 문서마다 고유한 URL을 만들 수 있다. 그러한 문서를 검증할 때, 그 정보를 네트워크에서 가져오는 검증자는 그 적합 보안 문서에 대한 자신의 관심을 문서 생성자에게 드러내게 되며, 이는 문서 생성자가 아닌 모든 엔티티에 대해 프라이버시 기대의 불일치로 이어질 수 있다.

구현자는 URL 캐싱과 네트워크에서 URL을 가져올 때 방어적으로 구현하는 것에 관한 5.14 네트워크 요청 절의 지침을 따를 것을 강력히 권장받는다. 요청을 하는 클라이언트를 드러내지 않고 네트워크에서 자원을 검색하기 위해 Oblivious HTTP와 같은 기법을 사용하는 것이 권장된다. 게다가 적합 보안 문서의 생성자가 프라이버시 기대를 침해할 수 있는 방식으로 핑거프린팅 URL을 사용하고 있는지 판단하는 데 휴리스틱이 사용될 수 있다. 이러한 휴리스틱은 핑거프린팅으로 의심되는 URL을 담은 문서를 처리할 수 있는 엔티티에게 경고를 표시하는 데 사용될 수 있다.

정규화라는 변환이 수행되는 방식은 시스템의 프라이버시 특성에 영향을 줄 수 있다. 최선의 정규화 메커니즘을 선택하는 것은 사용 사례에 달려 있다. 이 절은 구현자가 프라이버시 관점에서 이 규격에서 언급하는 두 주요 정규화 메커니즘, 즉 JSON Canonicalization Scheme [RFC8785]과 RDF 데이터셋 정규화 [RDF-CANON] 사이에서 선택하는 것을 돕기 위해 간단한 지침을 제공하려 시도한다.

애플리케이션이 보안 문서에서 정보의 선택적 공개를 수행할 필요가 없고 JSON-LD를 활용하지도 않는다면, JSON Canonicalization Scheme [RFC8785]이 매력적인 접근법이다.

애플리케이션이 JSON-LD를 사용하고 보안 문서에서 정보의 선택적 공개를 요구할 수 있다면, RDF 데이터셋 정규화 [RDF-CANON]를 사용하는 암호 스위트를 사용하는 것이 매력적인 접근법이다.

구현자는 또한 SD-JWT [SD-JWT]처럼, 증명을 데이터에 내장하는 대신 데이터를 암호학적 봉투로 감싸서 보안하며 변환을 수행하지 않는 다른 선택적 공개 메커니즘도 이용 가능함을 안내받는다. 이 접근법은 이 규격에 상세히 설명된 접근법이 제공하는 이점 일부를 희생하는 대신, 일부 사용 사례에서 단순성 이점을 갖는다.

이 규격에 기술된 문서 보안 기술은 본질적으로 일반화되어 있으므로, 그 사용의 프라이버시적 함의가 독자에게 즉시 분명하지 않을 수 있다. 완전한 소프트웨어 시스템에서 고려해야 할 수 있는 프라이버시 우려의 종류를 이해하기 위해, 구현자는 이 기술이 검증가능한 크리덴셜 생태계 [VC-DATA-MODEL-2.0]에서 어떻게 사용되는지 읽어볼 것을 강력히 권장받는다. 더 자세한 정보는 Verifiable Credential Privacy Considerations 절을 참고하라.

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

예를 들어 특정 디지털 서명 정보 집합의 만료 날짜를 전달할 때, 구현자는 만료 시각을 정확성에 최적화된 표현보다는 이해하기 쉬운 표현을 사용하여 제시할 것을 강력히 권한다. 만료 시각을 "이 티켓은 3일 전에 만료되었습니다."로 제시하는 것이 "이 티켓은 2023년 7월 25일 오후 3시 43분에 만료되었습니다."와 같은 문구보다 선호된다. 전자는 후자의 시각보다 이해하기 쉬운 상대적 시간을 제공하는데, 후자는 개인이 머릿속으로 계산을 해야 하고 그런 계산을 할 수 있다고 가정한다.