비트스트링 상태 목록 v1.0

초록

이 명세는 비트스트링을 사용하여 검증 가능한 자격 증명의 정지 또는 폐기와 같은 상태 정보를 공개하기 위한 개인정보 보호, 공간 효율성 및 고성능 메커니즘을 설명한다.

이 절은 비규범적이다.

발급자가 검증 가능한 자격 증명 [VC-DATA-MODEL-2.0]에 대해 검증자가 자격 증명이 정지되었거나 폐기되었는지 확인할 수 있는 위치로 연결하는 것은 종종 유용하다. 상태 목록을 설계, 공개 및 처리할 때 고려되는 개인정보 보호 및 성능 고려 사항에는 여러 가지가 있다.

그러한 개인정보 보호 고려 사항 중 하나는 검증 가능한 자격 증명과 상태가 공개되는 URL 사이에 일대일 매핑이 있을 때 발생한다. 이러한 유형의 매핑은 URL을 공개하는 웹사이트가 상태가 확인될 때 보유자, 시간 및 검증자를 상관시킬 수 있게 한다. 이는 예를 들어 술집에 들어갈 때 연령 확인 자격 증명을 제공하는 것과 같이, 보유자가 검증자와 가지는 상호작용 유형을 발급자가 발견할 수 있게 할 수 있다. 어떤 시설에 들어갈 때 운전면허증의 발급자에게 추적되는 것은 오늘날 많은 사람이 갖는 개인정보 보호 기대를 위반한다.

마찬가지로, 상태 목록을 설계할 때 검토되는 성능 고려 사항도 있다. 그러한 고려 사항 중 하나는 목록이 어디에 공개되는지와, 정보를 가져오는 서버와 클라이언트 모두에 대역폭 및 처리 관점에서 어떤 부담을 주는지이다. 개인정보 보호 기대를 충족하기 위해, 큰 자격 증명 집합의 상태를 단일 목록으로 묶어 그룹 개인정보 보호에 도움이 되도록 하는 것이 유용하다. 그러나 상태 정보가 수억 명의 보유자 집단 전체에서 자격 증명당 수백 바이트에 달한다면, 그렇게 하는 것은 서버와 클라이언트 모두에 불가능한 부담을 줄 수 있다.

이 문서의 나머지 부분은 웹의 아키텍처와 호환되고, 공간 효율성이 높으며, 콘텐츠 전송 네트워크에 잘 맞는, 강력한 개인정보 보호 특성을 가진 고도로 압축 가능한 비트스트링 기반 상태 목록 메커니즘을 제안한다. 이 명세를 사용하여 여러 유익한 개인정보 보호 및 성능 목표를 달성하는 예로, 100,000개의 검증 가능한 자격 증명에 대해 최악의 경우 대략 12,500바이트 크기의 상태 목록을 만들 수 있다. 수백 개의 자격 증명이 폐기된 경우, 목록의 크기는 수백 바이트 미만이면서 100,000명으로 이루어진 그룹 안에서 개인정보 보호를 제공한다.

이 절은 비규범적이다.

이 절은 이 명세에서 설명하는 상태 목록 메커니즘이 활용하는 핵심 개념을 개괄한다. 가장 기본적인 수준에서, 발급자가 발급한 모든 검증 가능한 자격 증명의 상태 정보는 목록의 항목으로 표현된다. 각 발급자는 자신이 발급한 모든 검증 가능한 자격 증명의 목록을 관리한다. 각 검증 가능한 자격 증명은 그 목록의 항목과 연결된다. 단일 비트가 "revoked" 또는 "suspended"와 같은 상태를 지정할 때, 그 비트가 설정되어 있으면(1) 해당 상태는 true로 예상되고, 설정되어 있지 않으면(0) false로 예상된다.

비트스트링을 사용하는 이점 중 하나는 평균적인 경우 많은 수의 자격 증명이 폐기되지 않은 상태로 남아 있으므로, 매우 압축 가능한 데이터 형식이라는 점이다. 이는 동일한 값을 가진 긴 비트 구간을 보장하며, 따라서 GZIP [RFC1952]과 같은 실행 길이 압축 기법을 사용하여 매우 잘 압축될 수 있다. 기본 상태 목록 크기는 131,072개 항목이며, 이는 단일 비트 값 16 KB에 해당한다. 소수의 검증 가능한 자격 증명만 폐기된 경우, GZIP은 비트스트링을 수백 바이트로 압축한다.

비트스트링을 사용하는 또 다른 이점은 많은 수의 검증 가능한 자격 증명 상태를 같은 목록에 배치할 수 있게 한다는 점이다. 이 명세는 최소 목록 길이 131,072를 사용한다. 이 크기는 평균적인 경우 충분한 양의 그룹 개인정보 보호를 보장한다. 더 나은 그룹 개인정보 보호가 필요하면, 비트스트링을 더 크게 만들 수 있다.

이미지 상단에 상자 목록이 있으며 그중 두 개가 폐기된 자격 증명을
나타내기 위해 빨간색으로 표시된 다이어그램. 상자 오른쪽의 텍스트는
16킬로바이트라고 표시된다. 페이지 하단에서 상자들이 GZIP으로
원통형으로 압축되는 모습은 압축 결과 최종 크기가 135바이트가
되었음을 보여 준다. — 그림 1 이 절에서 개괄한 개념의 시각적 묘사.

참고: 상태 정보는 검증 가능한 자격 증명에 관한 것이다

특정 검증 가능한 자격 증명과 연결된 상태 정보는 검증 가능한 자격 증명 자체에 관한 것이며, 교육 학위와 같은 기본 또는 뒷받침 자격 증명에는 적용되지 않을 수 있다. 예를 들어 이러한 교육 학위의 경우, 검증 가능한 자격 증명을 만드는 데 사용된 디지털 서명 메커니즘이 손상되었기 때문에 해당 검증 가능한 자격 증명이 폐기될 수 있지만, 이를 뒷받침하는 교육 학위는 여전히 유효할 수 있다.

이 절은 비규범적이다.

이 문서 전체에서 사용되는 용어는 검증 가능한 자격 증명 데이터 모델 v2.0 명세의 용어 절에 정의되어 있다.

비규범으로 표시된 절뿐만 아니라, 이 명세의 모든 저작 지침, 다이어그램, 예제 및 참고도 비규범적이다. 이 명세의 그 밖의 모든 것은 규범적이다.

이 문서의 핵심 단어 MAY, MUST, MUST NOT, OPTIONAL, SHOULD, 그리고 SHOULD NOT은 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 그때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.

적합한 문서는 2. 데이터 모델 절의 관련 규범 요구 사항을 따르는 데이터 모델의 모든 구체적 표현이다.

적합한 처리기는 3. 알고리즘 절의 관련 규범 진술에 따라 적합한 문서를 생성하거나 소비하는 소프트웨어 및/또는 하드웨어로 구현된 모든 알고리즘이다. 적합한 처리기는 비트스트링 항목 크기 1만 지원하도록 선택할 수 있다 MAY. 적합한 처리기는 부적합 문서가 소비될 때 오류를 생성해야 한다 MUST.

디지털 자격 증명과 연결된 상태 정보를 표현하는 방법은 많다. 이러한 메커니즘에는 Certificate Revocation Lists (CRL) [RFC5280], Online Certificate Status Protocol (OCSP) [RFC2560], Bloom Filters [RFC8932] 및 cryptographic accumulators [ALLOSAUR]가 포함된다. 이 명세는 다른 메커니즘과 다른 다양한 요구 사항에 맞게 최적화한다. 이러한 요구 사항에는 다음이 포함된다.

상태 기술 비교
기능	CRL	OCSP	Bloom	Accumulator	Bitstring
조정 가능한 그룹 개인정보 보호를 제공한다	✓	✗	✓	✓	✓
각 자격 증명에 대해 서명된 단언을 요구하지 않는다	✓	✗	✓	✓	✓
검증자가 가져올 때 발급자 추적에 저항한다	✓	✓	✓	✓	✓
폐기 수가 많아도 캐싱이 공간 효율적이다	✗	✗	✓	✓	✓
매우 압축 가능하다(>90% 평균 압축)	✗	✗	✓	✓	✓
업데이트가 효율적이다(빠르며 전체 집단을 업데이트할 필요가 없다)	✓	✗	✓	✗	✓
IETF가 승인한 암호학적 기본 요소를 사용한다	✓	✓	✓	✗	✓
거짓 양성이 없다	✓	✓	✗	✓	✓
보유자가 전달할 수 있다 (stapling)	✗	✓	✗	✓	✓
검증 가능한 자격 증명과 함께 사용하도록 쉽게 프로파일링할 수 있다	✗	✗	✗	✗	✓

발급자가 검증 가능한 자격 증명에 대한 상태 정보를 가능하게 하려는 경우, 이 절에서 설명하는 데이터 모델을 사용하는 credentialStatus 속성을 추가할 수 있다 MAY. 이 절의 데이터 모델의 모든 표현은 [VC-DATA-MODEL-2.0]에 정의된 적합한 검증 가능한 자격 증명으로 표현되어야 한다 MUST.

속성 설명

id 상태 목록 항목의 선택적 식별자. id 속성에 대한 제약은 Verifiable Credentials Data Model 명세 [VC-DATA-MODEL-2.0]에 나열되어 있다. 존재하는 경우, 값은 검증 가능한 자격 증명과 연결된 상태 정보를 식별하는 URL일 것으로 예상된다. 이는 상태 목록의 URL이어서는 안 된다 MUST NOT. 이 값은 검증 또는 유효성 검사 과정에서 사용되지 않으며, statusListCredential 값과 관련될 필요가 없다. 필요한 경우, 데이터베이스에 저장될 때와 같이 BitstringStatusListEntry 객체를 고유하게 식별하는 데 사용할 수 있다.

type type 속성은 BitstringStatusListEntry이어야 한다 MUST.

statusPurpose

상태 항목의 목적은 문자열이어야 한다 MUST. 문자열의 값은 임의적이지만, 다음 값들은 의도된 목적에 사용되어야 한다 MUST.

값	설명
`refresh`	업데이트된 검증 가능한 자격 증명이 자격 증명의 refresh service 기능을 통해 사용 가능함을 알리는 데 사용된다. 이 상태는 검증 가능한 자격 증명을 무효화하지 않으며 되돌릴 수 없다.
`revocation`	검증 가능한 자격 증명의 유효성을 취소하는 데 사용된다. 이 상태는 되돌릴 수 없다.
`suspension`	검증 가능한 자격 증명의 수락을 일시적으로 방지하는 데 사용된다. 이 상태는 되돌릴 수 있다.
`message`	검증 가능한 자격 증명의 상태와 관련된 임의의 메시지를 전달하는 데 사용된다.

statusListIndex statusListIndex 속성은 0보다 크거나 같은 임의 크기의 정수여야 하며 MUST, 10진수 문자열로 표현된다. 이 값은 검증 가능한 자격 증명의 상태 위치를 식별한다. 구현은 그 위치에서 할당의 최신성이나 그룹의 크기와 같은 추론을 쉽게 도출할 수 없도록 인덱스를 무작위로 할당해야 한다 SHOULD.

statusListCredential statusListCredential 속성은 검증 가능한 자격 증명에 대한 URL이어야 한다 MUST. URL이 역참조되면, 결과로 얻은 검증 가능한 자격 증명은 BitstringStatusListCredential 값을 포함하는 type 속성을 가져야 한다 MUST.

statusSize statusSize는 상태 항목의 크기를 비트 단위로 나타낸다. statusSize는 제공될 수 있다 MAY. credentialStatus의 속성으로 statusSize가 없으면, statusSize는 1로 처리되어야 한다 MUST. 존재하는 경우, statusSize는 0보다 큰 정수여야 한다 MUST. statusSize가 제공되고 1보다 크면, credentialStatus.statusMessage 속성이 존재해야 하며 MUST, 상태 메시지의 수는 가능한 값의 수와 같아야 한다 MUST.

statusMessage

존재하는 경우, statusMessage 속성은 배열이어야 하며 MUST, 그 길이는 statusSize가 나타내는 가능한 상태 메시지의 수와 같아야 한다 MUST (예: statusSize가 1비트이면 statusMessage 배열은 2개 요소를 가져야 하고 MUST, statusSize가 2비트이면 4개 요소, statusSize가 3비트이면 8개 요소 등이다). statusSize가 1이면 statusMessage는 존재할 수 있고 MAY, statusSize가 1보다 크면 존재해야 한다 MUST. statusMessage 배열이 존재하지 않으면, 1 및 0의 status 비트 값과 연결된 메시지 값은 각각 "set" 및 "unset"이다. statusMessage 배열이 존재하는 경우, 각 요소는 아래에 설명된 두 속성을 포함해야 하며 MUST, 추가 속성을 포함할 수 있다 MAY.

status, 0x가 접두사로 붙은 상태의 16진수 값을 나타내는 문자열
message, 소프트웨어 개발자가 디버깅을 지원하는 데 사용하는 문자열이며 최종 사용자에게 표시해서는 안 된다 SHOULD NOT.

구현자는 statusMessage 배열의 객체에 추가 값을 더할 수 있다 MAY. 구현자는 연결된 상태 값에 대해 해당 상태가 정의되어 있지 않지만 미래에 정의될 수 있음을 나타내기 위해 값에 undefined 문자열 값을 사용할 수 있다 MAY. 다양한 상태 메시지를 처리하는 방법에 대한 규칙은 이 문서의 규범 요구 사항 범위 밖에 있지만, 구현자가 다양한 상태 코드를 처리하기 위한 규칙을 문서화할 것으로 가정한다.

statusReference

구현자는 statusReference 속성을 포함할 수 있다 MAY. 존재하는 경우, 그 값은 상태와 관련된 자료로 역참조되는 URL 또는 URL 배열 [URL]이어야 한다 MUST. message의 statusPurpose를 사용하는 구현자는 statusReference를 제공할 것이 강력히 권장된다.

참고: 참조 주변의 세부 사항

statusReference는 자격 증명의 상태 해석에 관련된 비즈니스 사례에 대한 어느 정도의 이해가 필요할 수 있을 때 특히 중요하다.

상태 목록 항목은 statusPurpose 속성을 사용하여 검증 가능한 자격 증명과 연결된 상태의 목적을 표현하는 데 사용할 수 있다.

상태 목적으로 revocation 또는 suspension을 사용하는 것은 상태의 의미를 포함하며, revocation은 상태 비트가 검증 가능한 자격 증명이 폐기되었는지 여부를 표현함을 나타내고, suspension은 상태 비트가 검증 가능한 자격 증명이 정지되었는지 여부를 표현함을 나타낸다. 아래 예제는 이러한 상태 목적의 사용을 보여 준다.

예제 1: 단순 항목을 사용하는 StatusListCredential 예제

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.com/credentials/23894672394",
  "type": ["VerifiableCredential", "EmployeeIdCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2024-04-05T14:27:42Z",
  "credentialStatus": [{
    "id": "https://example.com/credentials/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/credentials/status/3"
  }, {
    "id": "https://example.com/credentials/status/4#23452",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "suspension",
    "statusListIndex": "23452",
    "statusListCredential": "https://example.com/credentials/status/4"
  }],
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "Person",
    "employeeId": "A-123456"
  }
}

상태 목적으로 message를 사용하면 발급자가 검증 가능한 자격 증명의 상태에 관한 임의 개수의 사용자 정의 설명 메시지를 정의할 수 있다. 발급자는 검증 가능한 자격 증명 발급 시점에 statusSize, statusMessage 및 선택적 statusReference 속성을 통해 특정 항목 (즉, 특정 검증 가능한 자격 증명)과 연결될 수 있는 메시지 집합에 대해 약속한다. 이는 보유자가 자신이 소지하고 있는 특정 검증 가능한 자격 증명에 어떤 종류의 정보가 연결될 수 있는지 알도록 보장하기 위한 것이며, 그 자격 증명을 나중에 받는 검증자가 이를 발견할 수 있다.

참고

statusListIndex가 검증 가능한 자격 증명과 목록 안의 그 상태 사이의 유일한 연결이라는 점에 유의하는 것이 중요하다. credentialSubject.id와 같은 다른 속성은 이 목적에 사용되지 않는다.

예제 2: 더 복잡한 항목을 사용하는 StatusListCredential 예제

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://example.com/credentials/2947478373",
  "type": ["VerifiableCredential", "BillOfLadingExampleCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2024-04-05T03:52:31Z",
  "credentialStatus": {
    "id": "https://example.com/credentials/status/8#492847",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "message",
    "statusListIndex": "492847",
    "statusSize": 2,
    "statusListCredential": "https://example.com/credentials/status/8",
    "statusMessage": [
        {"status":"0x0", "message":"pending_review"},
        {"status":"0x1", "message":"accepted"},
        {"status":"0x2", "message":"rejected"},
        ...
    ],
    "statusReference": "https://example.org/status-dictionary/"
  },
  "credentialSubject": {
    "id": "did:example:6789",
    "type": "BillOfLading",
    ...
  }
}

상태 목록 검증 가능한 자격 증명이 공개될 때, 이는 [VC-DATA-MODEL-2.0]에 정의된 적합한 문서여야 하며 MUST, 이 절의 데이터 모델을 표현해야 한다. 다음 절은 상태 목록을 캡슐화하는 검증 가능한 자격 증명의 형식을 설명한다.

상태 목록은 검증 가능한 자격 증명 내부에 표현되어, 보유자가 이를 검증자에게 직접 제공할 수 있게 한다. 때때로 "certificate stapling"이라고 불리는 이 메커니즘은 검증자가 상태 목록을 가져오기 위해 발급자에게 연락할 필요가 없도록 보장함으로써 보유자의 개인정보 보호를 향상시킨다. 그래도 검증자는 예를 들어 더 최신의 상태 목록 버전을 원한다면, 그 진정성을 검증할 수 있는 경우에도 보유자가 제공한 상태 목록을 무시하도록 선택할 수 있다.

발급자와 검증자는 검증 가능한 자격 증명의 발급자와 관련된 BitstringStatusListCredential의 발급자가 같지 않을 수 있음을 유의해야 한다. 원래 자격 증명에 대한 권한과, 그러한 자격 증명을 폐기하거나 그 밖의 방식으로 상태를 변경할 권한을 분리하는 것이 적절할 수 있게 하는 기술적, 법적, 제도적, 정치적 및 기타 이유가 있다. 따라서 BitstringStatusListEntry를 포함하는 검증 가능한 자격 증명의 issuer 값은 BitstringStatusListCredential의 issuer 값과 다를 수 있다 MAY.

속성 설명

id 상태 목록을 포함하는 검증 가능한 자격 증명은 해당 BitstringStatusListEntry에 대한 statusListCredential에 지정된 값과 일치하는 id 속성을 표현할 수 있다 MAY (2.1 BitstringStatusListEntry 참조).

type 상태 목록을 포함하는 검증 가능한 자격 증명은 BitstringStatusListCredential 값을 포함하는 type 속성을 표현해야 한다 MUST.

validFrom 상태 목록이 유효한 가장 이른 시점. 이 속성은 Verifiable Credentials Data Model 명세의 4.6절: 유효 기간에 정의되어 있다.

validUntil 상태 목록이 유효한 가장 늦은 시점. 이 속성은 Verifiable Credentials Data Model 명세의 4.6절: 유효 기간에 정의되어 있다.

credentialSubject.type 상태 목록인 자격 증명 주체의 type은 BitstringStatusList이어야 한다 MUST.

credentialSubject.statusPurpose

상태 항목의 목적 속성인 statusPurpose의 값은 하나 이상의 문자열이어야 한다 MUST. 각 문자열의 값은 임의적이지만, 다음 값들은 의도된 목적에 사용되어야 한다 MUST.

값	설명
`refresh`	업데이트된 검증 가능한 자격 증명이 자격 증명의 refresh service 기능을 통해 사용 가능함을 알리는 데 사용된다. 이 상태는 검증 가능한 자격 증명을 무효화하지 않으며 되돌릴 수 없다.
`revocation`	검증 가능한 자격 증명의 유효성을 취소하는 데 사용된다. 이 상태는 되돌릴 수 없다.
`suspension`	검증 가능한 자격 증명의 수락을 일시적으로 방지하는 데 사용된다. 이 상태는 되돌릴 수 있다.
`message`	검증 가능한 자격 증명과 연결된 상태 메시지를 나타내는 데 사용된다. 상태 메시지 설명은 `credentialSubject.statusMessages`에 정의되어야 한다 MUST. 이 `statusPurpose` 값이 사용될 때 `credentialSubject.statusSize`가 지정되어야 한다 MUST.

credentialSubject.encodedList 자격 증명 주체의 encodedList 속성은 관련된 검증 가능한 자격 증명 상태 값 범위에 대한 GZIP 압축 [RFC1952] 비트스트링 값의 Multibase 인코딩 base64url (패딩 없음) [RFC4648] 표현이어야 한다 MUST. 압축 해제된 비트스트링은 최소 16KB 크기여야 한다 MUST. 비트스트링은 0(0) 값을 가진 첫 번째 인덱스가 비트스트링의 가장 왼쪽 비트에 위치하고, 비트스트링 길이보다 하나 작은 값(bitstring_length - 1)을 가진 마지막 인덱스가 비트스트링의 가장 오른쪽 비트에 위치하도록 인코딩되어야 한다 MUST. 비트스트링 인코딩에 대한 추가 정보는 7.1 비트스트링 인코딩 절에서 확인할 수 있다.

credentialSubject.ttl ttl은 갱신을 시도해야 하는 SHOULD 전까지의 "time to live"를 밀리초 단위로 나타내는 OPTIONAL 속성이다. 존재하지 않으면 기본값은 가정되지 않는다. 이 값은 BitstringStatusList의 유효 기간을 재정의하거나 대체하지 않는다. 상태 목록을 공개하는 구현은 HTTP Cache-Control 헤더와 같은 프로토콜별 캐싱 정보를 이 필드의 값과 정렬해야 한다 SHOULD.

아래 예제는 특정 검증 가능한 자격 증명의 상태를 결정하는 데 필요한 정보를 검증자에게 제공하기 위해 BitstringStatusListEntry가 BitstringStatusListCredential와 함께 어떻게 사용되는지 보여 준다.

예제 3: BitstringStatusListCredential 예제

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://example.com/credentials/status/3",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:example:12345",
  "validFrom": "2021-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "https://example.com/status/3#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  }
}

다음 절은 이 문서에서 설명하는 상태 목록을 생성하고 유효성 검사하는 데 사용되는 알고리즘을 개괄한다.

이 절의 알고리즘 구현이 2. 데이터 모델 절에 정의된 속성을 처리할 때, 그 값이 관련 "MUST" 문장을 준수하지 않아 잘못된 형식이면, MALFORMED_VALUE_ERROR가 발생해야 한다 MUST.

BitstringStatusListCredential를 생성할 때 다음 과정 또는 정확히 같은 출력을 생성하는 과정을 따라야 한다 MUST. 알고리즘은 issued credentials 목록을 입력으로 받고, 오류를 던지거나 상태 목록 자격 증명을 출력으로 반환한다.

issued credentials를 발급된 모든 검증 가능한 자격 증명의 목록이라고 하자.
statusListCredential를 encodedList 속성이 설정되지 않은, 서명되지 않은 BitstringStatusListCredential라고 하자.
issued credentials를 비트스트링 생성 알고리즘에 전달하여 compressed bitstring을 생성한다.
encodedList를 compressed bitstring으로 설정한다.
statusListCredential에 대한 증명을 생성하고, 검증 가능한 자격 증명에 나열된 엔드포인트에 공개한다.

발급자는 상태 목록 자격 증명을 캐시할 수 있고, 누가 그 상태 목록 자격 증명을 가져오는지 추적하지 않는 방식으로 공개해야 한다 SHOULD. 예를 들어 Oblivious HTTP, 발급자가 운영하지 않는 콘텐츠 전송 네트워크, 또는 데이터 분석가나 시스템 관리자가 접근 로그에 접근할 수 없는 비즈니스 프로세스를 통해 공개할 수 있다.

BitstringStatusListCredential에 포함된 검증 가능한 자격 증명을 유효성 검사할 때, 다음 과정 또는 정확히 같은 출력을 생성하는 과정을 따라야 한다 MUST. 알고리즘은 상태 목록 검증 가능한 자격 증명을 입력으로 받고 오류를 던지거나 상태 목록 자격 증명을 출력으로 반환한다.

credentialToValidate를 BitstringStatusListEntry인 credentialStatus 항목을 포함하는 검증 가능한 자격 증명이라고 하자.
특정 생태계 명세가 다른 하한을 설정하지 않는 한, minimumNumberOfEntries를 131,072라고 하자.
status purpose를 credentialToValidate의 credentialStatus 항목에 있는 statusPurpose의 값이라고 하자.
statusListCredential URL을 역참조하고, 모든 증명이 성공적으로 검증되는지 보장한다. 역참조가 실패하면 STATUS_RETRIEVAL_ERROR를 발생시킨다. 증명 검증 중 하나라도 실패하면 STATUS_VERIFICATION_ERROR를 발생시킨다.
status purpose가 statusListCredential의 statusPurpose 값과 같은지 검증한다. 참고: statusListCredential은 단일 목록 안에 여러 상태 목적을 포함할 수 있다. 값이 같지 않으면 STATUS_VERIFICATION_ERROR를 발생시킨다.
compressed bitstring을 BitstringStatusListCredential의 encodedList 속성 값이라고 하자.
credentialIndex를 BitstringStatusListEntry의 statusListIndex 속성 값이라고 하자.
compressed bitstring을 비트스트링 확장 알고리즘에 전달하여 revocation bitstring을 생성한다.
revocation bitstring의 길이를 statusSize로 나눈 값이 minimumNumberOfEntries보다 작으면, STATUS_LIST_LENGTH_ERROR를 발생시킨다.
status를 credentialIndex에 size를 곱해 표시된 위치에 있는 bitstring의 값이라고 하자. credentialIndex에 size를 곱한 값이 bitstring 범위 밖의 값이면, RANGE_ERROR가 발생해야 한다 MUST.
result를 빈 map이라고 하자.
result의 status 키를 status로 설정하고, result의 purpose 키를 statusPurpose의 값으로 설정한다.
status가 0이면 result의 valid 키를 true로 설정하고, 그렇지 않으면 false로 설정한다.
statusPurpose가 message이면, statusMessages 배열에 표시된 value의 해당 message를 result의 message 키로 설정한다.
result를 반환한다.

statusListCredential URL이 역참조될 때, 서버 구현은 특정 시점의 상태 목록을 역참조하는 메커니즘을 제공할 수 있다 MAY. 발급자가 이러한 메커니즘을 제공하면, 검증자가 시간별, 일별 또는 주별과 같이 발급자가 선택한 정밀도로 상태 변경을 판단할 수 있다. 그러한 기능이 지원되고, URL 스킴이 쿼리 매개변수를 지원한다면, 쿼리 매개변수의 이름은 timestamp이어야 하며 MUST, 값은 유효한 URL 인코딩 [XMLSCHEMA11-2] dateTimeStamp 문자열 값이어야 한다 MUST. 이러한 timestamp 매개변수화 URL을 역참조한 결과는 주어진 시점에 존재했던 상태 목록을 포함하는 상태 목록 자격 증명이거나 STATUS_RETRIEVAL_ERROR이어야 한다 MUST. 결과가 오류인 경우, 구현은 검증자의 유효성 검사 규칙이 그러한 동작을 허용하는 한, 다른 timestamp 값으로 또는 timestamp 값 없이 검색을 다시 시도할 수 있다 MAY.

검증자는 검색한 상태 목록을 캐시해야 하며 SHOULD, 검색 행동을 발급자에게 숨기는 프록시 또는 Oblivious HTTP와 같은 다른 메커니즘을 사용해야 한다 SHOULD.

참고: 발급자 검증은 사용 사례에 따라 달라진다

검증자는 추가적인 의사 결정 목적을 위해 어느 자격 증명에 포함된 정보를 사용하기 전에, 검증 가능한 자격 증명의 발급자와 관련된 BitstringStatusListCredential의 발급자를 신뢰하는지 보장할 것으로 예상된다. 구현자는 원래 검증 가능한 자격 증명의 발급자가 그 유효성의 기록을 유지하지 않는 경우처럼, 이러한 자격 증명의 발급자가 서로 다를 수 있음을 유의해야 한다.

상태 목록 비트스트링을 생성할 때 다음 과정 또는 정확히 같은 출력을 생성하는 과정을 따라야 한다 MUST. 알고리즘은 issuedCredentials 목록을 입력으로 받고, 오류를 던지거나 compressed bitstring을 출력으로 반환한다.

bitstring을 최소 크기 16KB의 비트 목록이라고 하며, 각 비트는 0(영)으로 초기화된다.
bitstring의 각 값에 대해, issuedCredentials의 자격 증명에 해당하는 statusListIndex 값이 있으면, 그 값을 적절한 상태로 설정한다. 값의 위치는 statusListIndex에 statusSize를 곱하여 계산한다.
bitstring에 GZIP 압축 알고리즘 [RFC1952]을 사용한 뒤, 그 결과를 base64url(패딩 없음)을 사용하여 Multibase 인코딩함으로써 compressed bitstring을 생성한다.
compressed bitstring을 반환한다.

압축된 상태 목록 비트스트링을 확장할 때 다음 과정 또는 정확히 같은 출력을 생성하는 과정을 따라야 한다 MUST. 알고리즘은 compressed bitstring을 입력으로 받고, 오류를 던지거나 uncompressed bitstring을 출력으로 반환한다.

compressed bitstring을 압축된 상태 목록 비트스트링이라고 하자.
compressed bitstring에 Multibase 디코딩 알고리즘을 사용한 뒤, GZIP 압축 해제 알고리즘 [RFC1952]을 사용하여 출력을 확장함으로써 uncompressed bitstring을 생성한다.
uncompressed bitstring을 반환한다.

이 명세에서 설명하는 알고리즘은 특정 유형의 오류를 던진다. 구현자는 이러한 오류를 다른 라이브러리나 소프트웨어 시스템에 전달하는 것이 유용하다고 생각할 수 있다. 이 절은 이 명세에서 설명하는 기술을 구현하는 생태계가 오류 발생 시 더 효과적으로 상호운용할 수 있도록, 오류에 대한 특정 URL, 설명 및 오류 코드를 제공한다.

HTTP 인터페이스를 통해 이러한 오류를 노출할 때, 구현자는 오류 데이터 구조를 인코딩하기 위해 Problem Details for HTTP APIs [RFC9457]을 사용해야 한다 SHOULD. [RFC9457]이 사용되는 경우:

오류 객체의 type 값은 https://www.w3.org/ns/credentials/status-list# 값으로 시작하고 아래에 나열된 절의 값으로 끝나는 URL이어야 한다 MUST.
title 값은 오류에 대한 짧지만 구체적인 사람이 읽을 수 있는 문자열을 제공해야 한다 SHOULD.
detail 값은 오류에 대한 더 긴 사람이 읽을 수 있는 문자열을 제공해야 한다 SHOULD.
사람이 읽을 수 있는 모든 문자열은 Problem Details for HTTP APIs의 1절에 설명된 대로, Accept-Language HTTP 헤더 필드를 통한 언어 협상을 사용하여 가장 적절한 리소스를 선택함으로써 현지화되어야 한다 SHOULD.

STATUS_RETRIEVAL_ERROR: 상태 목록 검색에 실패했다. 3.2 유효성 검사 알고리즘 절을 참조하라.
STATUS_VERIFICATION_ERROR: 상태 항목의 유효성 검사에 실패했다. 3.2 유효성 검사 알고리즘 절을 참조하라.
STATUS_LIST_LENGTH_ERROR: 상태 목록 길이가 군중 개인정보 보호에 필요한 최소 길이를 충족하지 않는다. 3.2 유효성 검사 알고리즘 절을 참조하라.

2. 데이터 모델 절의 정보를 보호하는 방법은 여러 가지가 있다. 이러한 메커니즘은 검증 가능한 자격 증명 데이터 모델 v2.0의 Securing Mechanisms 절에서 자세히 설명된다.

BitstringStatusListCredential에 대한 참조를 포함하는 검증 가능한 자격 증명을 보호할 때, 구현자는 두 검증 가능한 자격 증명에 대해 같은 보호 메커니즘, 같은 암호학적 매개변수 및 같은 미디어 타입을 사용해야 한다 SHOULD.

statusListCredential을 역참조할 때, 반환되는 statusListCredential의 콘텐츠는 하나 이상의 증명이 있는 검증 가능한 자격 증명을 표현하기 위한 목적으로 등록된 어떤 미디어 타입이든 될 수 있다.

예를 들어 Data Integrity Proofs로 보호된 검증 가능한 자격 증명은 application/vc 미디어 타입을 가질 수 있고, SD-JWT로 보호된 검증 가능한 자격 증명은 application/sd-jwt 미디어 타입을 가질 수 있다.

일부 구현은 application/ld+json 또는 application/json과 같은 덜 구체적인 미디어 타입을 지원하도록 선택할 수 있다.

HTTP를 통해 역참조할 때, accept 및 content-type 헤더의 사용은 일부 구현이 statusListCredential을 보호하는 데 사용되는 증명 형식을 협상할 수 있게 할 수 있다.

일부 구현은 요청된 미디어 타입을 지원하지 않는다는 신호를 보내기 위해 415 Unsupported Media Type 상태 코드를 사용할 수 있다.

미디어 타입	설명 및 해시
application/ld+json	JSON-LD 형식의 어휘 [JSON-LD11]. SHA2-256 다이제스트: `98b555e914aed27fe6b73dbd655a3d1103d1a26ce1ad709a38435dcbb3451a68`
text/turtle	Turtle 형식의 어휘 [TURTLE]. SHA2-256 다이제스트: `ad4b2142eaa57cf771d91c2b061ebeb4cd17d74c8e87899ea14368df14168844`
text/html	HTML+RDFa 형식의 어휘 [HTML-RDFA]. SHA2-256 다이제스트: `fa3b8be58441dfdf11f5314330d612e0a9b9e94993076f3702418c511de71174`

컨텍스트 URL 및 해시
URL: https://www.w3.org/ns/credentials/status/v1 SHA2-256 다이제스트: `fda5add353231e6a6884a46b12e6c75464281900cb348284d9c360f62381d9f7`

이 절은 비규범적이다.

이 절은 이 명세를 운영 환경에 배포할 때의 일반적인 개인정보 보호 고려 사항과 구체적인 개인정보 보호상 함의를 자세히 설명한다.

독자는 이 절을 읽기 전에 Verifiable Credentials 명세의 개인정보 보호 고려 사항 절에서 제공하는 일반적인 개인정보 보호 조언에 익숙해질 것이 강력히 권장된다.

이 절은 비규범적이다.

이 문서는 최소 폐기 비트스트링 길이를 131,072 또는 압축 해제 16KB로 지정한다. 발급된 검증 가능한 자격 증명의 수가 충분히 많다면, 이는 보유자에게 충분한 양의 그룹 개인정보 보호를 제공하기에 충분하다. 그러나 발급된 검증 가능한 자격 증명의 수가 작은 집단이라면, 비트스트링에 할당된 슬롯 수가 작기 때문에 개인을 상관시킬 수 있는 능력이 증가한다. 예를 들어 지리적 요청이 어디에서 왔는지와 이 정보를 상관시키는 것도 같은 지리적 지역에서 자격 증명을 받은 개인들을 상관시키는 데 도움이 될 수 있다.

이 절은 비규범적이다.

2.1 BitstringStatusListEntry 절에 정의된 상태 목록 항목에는 검증자들 사이에서 주체를 상관시키는 데 사용할 수 있는 여러 전역 식별자가 있다. 이러한 값을 표현할 수 있는 속성에는 id, statusListIndex, 그리고 statusListCredential이 있다.

전역 식별자(예: 운전면허증 식별 번호)를 포함하는 검증 가능한 자격 증명을 제시하는 경우와 같이, 어떤 경우에는 상태 목록 정보에 대해 하나 이상의 전역 식별자를 추가해도 상관관계 피해가 증가하지 않는다. 상관관계에는 하나의 전역적으로 고유한 식별자만으로도 충분하기 때문이다.

전역 식별자가 선택적 공개 또는 비연결 공개를 사용하는 presentation에서 사용되면, 개인정보 보호 기대를 위반할 수 있다. 발급자는 특정 검증 가능한 자격 증명이 개인이 특정 나이 이상임을 증명하는 경우처럼 상관관계가 필요 없는 방식으로 공개될 것으로 예상될 때, 상태 정보를 선택적으로 공개/은폐 가능하게 할 것이 강력히 권장된다. 검증자는 자격 증명의 현재 상태를 알아야 하는 상황에서 상태 정보가 공개되도록 요구할 수 있으며, 보유자는 주어진 거래에 대해 그 정보를 공개하는 데 동의하거나 거부할 수 있다. 모든 경우에 발급자와 검증자 모두는 특정 교환에 필요하거나 요구되는 경우가 아니라면, 상관관계를 방지하기 위해 전역 식별자의 사용을 피할 것이 강력히 권장된다.

잠재적 상관관계의 다른 유형에 대한 정보는 검증 가능한 자격 증명 데이터 모델 v2.0 명세의 개인정보 보호 고려 사항 절, 특히 식별자 기반 상관관계, 서명 기반 상관관계, 장기 식별자 기반 상관관계 및 메타데이터 기반 상관관계 하위 절을 살펴볼 것이 독자에게 강력히 권장된다.

이 절은 비규범적이다.

검증자는 원격 서버에서 가져온 상태 목록을 캐시함으로써, 확인 중인 검증 가능한 자격 증명의 보유자의 개인정보 보호를 향상시킬 수 있다. 콘텐츠를 로컬에 캐시하면, 상태 목록에 대한 검증자 기반 접근 패턴에서 추론할 수 있는 상관 가능한 정보가 줄어든다.

이 절은 비규범적이다.

발급자가 콘텐츠 전송 네트워크를 사용하면, 상태 목록에 대한 요청을 발급자로부터 줄이거나 제거함으로써 보유자의 개인정보 보호를 향상시킬 수 있다. 종종 폐기 목록에 대한 요청은 edge device에서 제공되므로 더 빠르고 서버 부하를 줄이며, 검증자와 보유자를 발급자로부터 가리는 역할도 한다.

이 절은 비규범적이다.

발급자가 상태 목록에서 미끼 값을 사용하는 것은 주체의 개인정보 보호를 향상시키기 위한 메커니즘으로 검토되었다. 미끼 값을 사용하는 알고리즘은 이 명세의 범위 밖이지만, 미끼 값이 상태 목록과 연결된 집단을 정확하게 시뮬레이션하지 않으면 미끼 값의 사용이 개인정보 보호를 해칠 수 있음을 구현자는 유의해야 한다. 미끼 값을 실제 값과 구별할 수 있다면, 집합에서 제공되는 익명성은 그렇게 감지 가능한 미끼 값의 수만큼 줄어든다. 가장 개인정보 보호적인 상태 목록은 전혀 변하지 않는 목록이다. 관찰 가능한 이벤트가 발생하지 않으면 집단의 행동을 판단할 수 없기 때문이다.

집단의 상태 항목을 통계적으로 시뮬레이션하는 것이 얼마나 어려운지, 그리고 검증 가능한 자격 증명이 광범위한 사용 사례를 제공하기 때문에 일반적인 조언을 할 수 없다는 점을 고려하여, 구현자는 상태 목록 항목 인덱스를 무작위로 할당하고, 상태 항목이 변경되는 비율을 최소화할 것, 최적으로는 절대 변경하지 않을 것이 권장된다. 상태 목록 항목의 할당은 상태 목록의 관찰 가능한 변경을 유발하지 않을 때 개인정보를 가장 잘 보존한다.

이 절은 비규범적이다.

일반적으로 이 명세가 제공하는 그룹 개인정보 보호는 악의적인 발급자와 검증자에 의해 우회될 수 있다. 그 개인정보 보호 이점은 발급자와 검증자가 특정 자격 증명의 제시를 추적하거나 공유하지 않으려는 의도가 있을 때에만 실현될 수 있다.

악의적인 검증자는 제시된 자격 증명의 정보를 악의적인 발급자와 공유함으로써 의도적으로 그룹 개인정보 보호를 공격할 수 있다. 이러한 종류의 공모는 일반적으로 발급자와 검증자 사이의 보안 통신 채널을 통해 수행되므로 감지하기 어렵다.

악의적인 발급자는 각 발급된 자격 증명에 대해 고유한 상태 목록을 만들어, 검증자가 매핑된 각 자격 증명을 처리하는 시점을 추적하기 위한 일대일 매핑을 설정함으로써 의도적으로 그룹 개인정보 보호를 공격할 수 있다. 마찬가지로, 주어진 상태 목록으로 추적되는 각 발급된 자격 증명에 서로 다른 암호 키를 사용하여 일대일 매핑을 설정할 수도 있다.

이러한 종류의 공모는 여러 보유자를 지원하는 보유자 소프트웨어 (예: 서버에서 실행되는 보유자 앱)가, 예를 들어 검증 가능한 자격 증명 안에 사용된 일부 전역 식별자가 다른 자격 증명과 충분히 공유되지 않는다는 것을 찾는 옵트인 프로세스를 가지고 있다면 감지될 수 있다. 그러면 보유자는 해당 자격 증명에 고유한 일부 전역 식별자를 포함하는 검증 가능한 자격 증명을 제시할 때 경고를 받을 수 있다. 그러한 옵트인 서비스는 추가적인 개인정보 보호 우려를 나타낼 수 있다. 보유자 소프트웨어를 통한 이러한 잠재적 노출이 가능한 전역 식별자 상관관계에 대한 인식으로 정당화되는지는 그러한 시스템의 사용자만 평가할 수 있다.

이 절은 비규범적이다.

검증자가 특정 보유자 또는 주체와 연결된 상태 목록 및 항목 인덱스를 알게 되면, 그 상태 목록이 계속 업데이트되는 한 해당 검증자는 그 상태 항목의 업데이트를 볼 수 있게 된다. 이는 특정 검증 가능한 자격 증명의 상태가 언제 변경되었는지 이해해야 하지만, 발급자에게 특정 검증 가능한 자격 증명에 대한 상태 정보를 직접 요청하지 않거나, 최신 상태 정보를 얻기 위해 보유자와 상호작용할 수 없는 검증자에게 유용하다. 이 기능은 또한 검증자가 검증 가능한 자격 증명의 상태에 대해 거의 실시간 확인을 수행할 수 있는 경우, 보유자 및/또는 주체에게 개인정보 보호 위반을 초래할 수도 있다.

발급자는 실질적으로 동일한 검증 가능한 자격 증명을 비교적 짧은 주기로 폐기하고 재발급함으로써 보유자에게 이러한 개인정보 보호 우려에서 어느 정도의 완화를 제공할 수 있다. 예를 들어 발급자는 3개월마다 검증 가능한 자격 증명을 자동으로 재발급하고, 재발급이 발생할 때 새로운 상태 항목 인덱스를 할당하여 상태가 변경됨에 따라 검증 가능한 자격 증명에 대한 어떤 종류의 장기 모니터링도 끊을 수 있다.

이 절은 비규범적이다.

이 명세는 상태 목록의 특정 항목에 대해 여러 상태 메시지를 제공할 수 있는 수단을 제공한다. 이 메커니즘은 상태 목록의 특정 항목에 대해 더 자세한 정보를 제공할 수 있지만, 그 정보는 추가적인 상관관계 데이터를 제공할 수 있다.

예를 들어 각 상태 메시지가 특정 프로세스의 단계 또는 자격 증명이 폐기되거나 정지된 이유에 대한 더 자세한 정보와 연결되어 있다면, 목록의 변경을 관찰하는 공격자는 개인정보 보호 위반으로 이어질 수 있는 목록 내 엔터티 집단에 관한 정보를 상관시킬 수 있을 수 있다. 집단이 비즈니스 프로세스를 어떻게 진행하는지, 또는 집단의 몇 퍼센트가 특정 상태와 연결될 가능성이 있는지를 이해하면 공격자에게 추가 정보가 제공된다. 그러한 정보가 있으면 피싱 작업은 비즈니스 프로세스의 다음 단계가 무엇인지 예측한 다음, 현재 상태를 알고 있는 엔터티에 선제적으로 연락할 수 있다. 그런 다음 그 정보를 바탕으로, 시간이 지나면서 상태 목록에서 얻은 데이터를 사용하여 대상에게서 더 가치 있는 정보를 피싱하려고 시도할 수 있다.

이러한 이유로, 발급자는 특정 엔터티 또는 집단에 관한 자세한 상태 정보를 공개적으로 게시할 때의 잠재적 파급 효과를 평가할 것이 강력히 권장된다.

이 절은 비규범적이다.

상태 목록이 상태 메시지 기능을 사용할 때, 발급자는 시간이 지남에 따라 자신이 발급하는 검증 가능한 자격 증명과 연결되는 메시지의 유형을 늘릴 수 있게 된다.

이 기능은 주체 또는 보유자가 원래 검증 가능한 자격 증명이 발급될 때는 존재하지 않았던 추가 상태 정보와 연결될 수 있는 잠재적 개인정보 보호 위반을 만든다. 예를 들어 초기 상태 메시지는 "delayed" 및 "canceled"를 전달할 수 있지만, 추가 상태 메시지가 발급자에 의해 추가되어 "delayed due to non-payment" 및 "canceled due to illegal activity"를 전달할 수 있다. 이러한 변경은 자신을 대신해 작동하는 모니터링 소프트웨어가 있어 발급자가 자신의 활동에 관한 추가 정보를 노출하려 한다고 경고하지 않는 한, 주체 또는 보유자에게 명확하지 않을 것이다.

보유자 소프트웨어는 상태 메시지와 연결된 검증 가능한 자격 증명을 사용할 때 보유자 및/또는 주체 정보 노출 수준에 대해 보유자에게 경고하고, 정보 노출 수준이 변경될 때 경고하는 기능을 제공할 수 있다.

비트스트링 상태 목록 v1.0

검증 가능한 자격 증명을 위한 개인정보 보호 상태 정보

초록

이 문서의 상태

1. 소개

1.1 개념적 프레임워크

1.2 용어

1.3 적합성

2. 데이터 모델

2.1 BitstringStatusListEntry

2.2 BitstringStatusListCredential

3. 알고리즘

3.1 생성 알고리즘

3.2 유효성 검사 알고리즘

3.3 비트스트링 생성 알고리즘

3.4 비트스트링 확장 알고리즘

3.5 처리 오류

3.6 보호 알고리즘

4. 미디어 타입

5. 컨텍스트와 어휘

5.1 어휘

5.2 JSON-LD 컨텍스트

6. 개인정보 보호 고려 사항

6.1 폐기 비트스트링 길이

6.2 불필요한 상관관계

6.3 검증자 캐싱

6.4 콘텐츠 전송 네트워크

6.5 미끼 값

6.6 악의적인 발급자와 검증자

6.7 상태 목록 모니터링

6.8 상태 메시지의 상관관계

6.9 상태 메시지의 변경

7. 보안 고려 사항

7.1 비트스트링 인코딩

7.2 유효 기간

8. 접근성 고려 사항

9. 국제화 고려 사항

A. 예제

A.1 폐기 가능한 검증 가능한 자격 증명

A.2 상태 목록 검증 가능한 자격 증명

A.3 하나의 검증 가능한 자격 증명 안의 여러 상태 목록

A.4 단일 목록 안의 여러 상태 항목

B. 개정 이력

C. 참고 문헌

C.1 규범적 참고 문헌

C.2 정보 참고 문헌