Bitstring Status List v1.0

요약

이 규격은 비트스트링을 사용하여 검증가능한 크리덴셜의 정지 또는 폐기와 같은 상태 정보를 발행하기 위한, 프라이버시를 보호하고 공간 효율적이며 고성능인 메커니즘을 기술한다.

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

검증가능한 크리덴셜 [VC-DATA-MODEL-2.0]의 발급자가, 검증자가 크리덴셜의 정지 또는 폐기 여부를 확인할 수 있는 위치로 연결하는 것이 유용한 경우가 많다. 상태 목록을 설계, 발행, 처리할 때 이루어지는 다양한 프라이버시 및 성능 고려사항이 있다.

그러한 프라이버시 고려사항 중 하나는 검증가능한 크리덴셜과 상태가 발행되는 URL 사이에 일대일 매핑이 있을 때 발생한다. 이러한 유형의 매핑은 URL을 발행하는 웹사이트가 상태를 확인할 때 보유자, 시각, 검증자를 상관지을 수 있게 한다. 이는 발급자가, 예를 들어 술집에 들어갈 때 연령 검증 크리덴셜을 제시하는 것처럼, 보유자가 검증자와 나누는 상호작용의 유형을 알아낼 수 있게 할 수 있다. 시설에 들어갈 때 운전면허증의 발급자에게 추적당하는 것은 오늘날 많은 사람이 가진 프라이버시 기대를 침해한다.

마찬가지로, 상태 목록을 설계할 때 살펴보게 되는 성능 고려사항이 있다. 그러한 고려사항 중 하나는 목록이 어디에 발행되는지, 그리고 그것이 정보를 가져오는 서버와 클라이언트 양쪽에 대역폭과 처리 관점에서 지우는 부담이다. 프라이버시 기대를 충족하려면, 그룹 프라이버시에 도움이 되도록 대규모 크리덴셜 집합의 상태를 하나의 목록으로 묶는 것이 유용하다. 그러나 상태 정보가 크리덴셜당 수백 바이트에 이르고 보유자가 수억 명에 달하는 경우, 그렇게 하는 것은 서버와 클라이언트 양쪽에 감당할 수 없는 부담을 지울 수 있다.

이 문서의 나머지 부분은 강력한 프라이버시 보호 특성을 갖추고, 웹의 아키텍처와 호환되며, 공간 효율성이 매우 높고, 콘텐츠 배포 네트워크에 잘 어울리는, 고압축이 가능한 비트스트링 기반 상태 목록 메커니즘을 제안한다. 이 규격을 사용하여 여러 유익한 프라이버시 및 성능 목표를 달성하는 예로, 최악의 경우에도 크기가 약 12,500바이트인 100,000개의 검증가능한 크리덴셜용 상태 목록을 만들 수 있다. 수백 개의 크리덴셜이 폐기된 경우, 목록의 크기는 수백 바이트 미만이면서도 100,000명의 그룹 안에서 프라이버시를 제공한다.

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

이 절은 이 규격에서 기술하는 상태 목록 메커니즘이 활용하는 핵심 개념을 개괄한다. 가장 기본적인 수준에서, 발급자가 발급한 모든 검증가능한 크리덴셜의 상태 정보는 목록의 항목으로 표현된다. 각 발급자는 자신이 발급한 모든 검증가능한 크리덴셜의 목록을 관리한다. 각 검증가능한 크리덴셜은 그 목록의 한 항목과 연관된다. 하나의 비트가 "폐기됨" 또는 "정지됨"과 같은 상태를 지정할 때, 그 상태는 비트가 설정되면(1) 참이고 설정되지 않으면(0) 거짓인 것으로 기대된다.

비트스트링을 사용하는 것의 이점 중 하나는, 평균적인 경우 다수의 크리덴셜이 폐기되지 않은 상태로 남기 때문에 매우 압축성이 높은 데이터 형식이라는 점이다. 이는 같은 값을 갖는 긴 비트 구간을 보장하며, 따라서 GZIP [RFC1952]과 같은 런렝스 압축 기법을 사용하여 매우 높은 압축이 가능하다. 기본 상태 목록 크기는 131,072개 항목으로, 단일 비트 값 16 KB에 해당한다. 소수의 검증가능한 크리덴셜만 폐기된 경우, GZIP은 비트스트링을 수백 바이트로 압축한다.

비트스트링을 사용하는 또 다른 이점은 다수의 검증가능한 크리덴셜 상태를 같은 목록에 담을 수 있다는 점이다. 이 규격은 최소 목록 길이로 131,072를 사용한다. 이 크기는 평균적인 경우 적절한 수준의 그룹 프라이버시를 보장한다. 더 나은 그룹 프라이버시가 필요하면, 비트스트링을 더 크게 만들 수 있다.

이미지 상단에 상자 목록이 있고 그중 두 개가 빨간색으로 폐기된
크리덴셜을 나타내는 다이어그램. 상자 오른쪽 옆의 텍스트에는 16킬로바이트라고
적혀 있다. 페이지 하단에서 상자들이 GZIP으로 압축되어 원기둥으로 표현된
그림은 압축 결과 최종 크기가 135바이트가 되었음을 보여준다. — 그림 1 이 절에서 설명한 개념을 시각적으로 표현한 것.

참고: 상태 정보는 검증가능한 크리덴셜에 관한 것이다

특정 검증가능한 크리덴셜과 연관된 상태 정보는 그 검증가능한 크리덴셜 자체에 관한 것이며, 학위와 같이 그 밑바탕이 되거나 뒷받침하는 크리덴셜에는 적용되지 않을 수 있다. 예를 들어 그러한 학위의 경우, 뒷받침하는 학위는 여전히 유효한데도 디지털 서명을 생성하는 데 사용된 검증가능한 크리덴셜이 폐기되는 것이 가능하다.

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

이 문서 전반에서 사용되는 용어는 Verifiable Credentials Data Model v2.0 규격의 용어 절에 정의되어 있다.

비규범적이라고 표시된 절뿐 아니라, 이 규격의 모든 저작 지침, 다이어그램, 예시, 참고(note)도 비규범적이다. 이 규격의 그 밖의 모든 것은 규범적이다.

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

적합 문서(conforming document)란 2. 데이터 모델 절의 관련된 규범적 요구사항을 따르는 데이터 모델의 구체적 표현이다.

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

디지털 크리덴셜과 연관된 상태 정보를 표현하는 방법은 다양하다. 그러한 메커니즘으로는 인증서 폐기 목록(CRL) [RFC5280], 온라인 인증서 상태 프로토콜(OCSP) [RFC2560], 블룸 필터(Bloom Filter) [RFC8932], 암호 누산기(cryptographic accumulator) [ALLOSAUR] 등이 있다. 이 규격은 다른 메커니즘과는 다른 다양한 요구사항에 최적화되어 있다. 이러한 요구사항에는 다음이 포함된다:

상태 기술 비교
특성	CRL	OCSP	Bloom	Accumulator	Bitstring
조정 가능한 그룹 프라이버시 제공	✓	✗	✓	✓	✓
크리덴셜마다 서명된 어서션이 필요하지 않음	✓	✗	✓	✓	✓
발급자 추적에 강함(검증자가 가져올 때)	✓	✓	✓	✓	✓
폐기가 많을 때 캐싱이 공간 효율적임	✗	✗	✓	✓	✓
높은 압축성(평균 압축률 >90%)	✗	✗	✓	✓	✓
업데이트가 효율적임(빠르며 전체 집단이 업데이트할 필요 없음)	✓	✗	✓	✗	✓
IETF가 승인한 암호 프리미티브 사용	✓	✓	✓	✗	✓
거짓 양성 없음	✓	✓	✗	✓	✓
보유자가 전달할 수 있음(스테이플링)	✗	✓	✗	✓	✓
검증가능한 크리덴셜과 함께 사용하도록 쉽게 프로파일링됨	✗	✗	✗	✗	✓

발급자가 검증가능한 크리덴셜에 대한 상태 정보를 활성화하고자 할 때, 이 절에서 기술하는 데이터 모델을 사용하는 credentialStatus 속성을 추가할 수 있다. 이 절의 데이터 모델을 표현하는 모든 것은 [VC-DATA-MODEL-2.0]에 정의된 대로 적합한 검증가능한 크리덴셜로 표현되어야 한다.

속성 설명

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

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

statusPurpose

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

값	설명
`refresh`	크리덴셜의 갱신 서비스(refresh service) 기능을 통해 갱신된 검증가능한 크리덴셜이 제공됨을 알리는 데 사용된다. 이 상태는 검증가능한 크리덴셜을 무효화하지 않으며 되돌릴 수 없다.
`revocation`	검증가능한 크리덴셜의 유효성을 취소하는 데 사용된다. 이 상태는 되돌릴 수 없다.
`suspension`	검증가능한 크리덴셜의 수락을 일시적으로 방지하는 데 사용된다. 이 상태는 되돌릴 수 있다.
`message`	검증가능한 크리덴셜의 상태와 관련된 임의의 메시지를 전달하는 데 사용된다.

statusListIndex statusListIndex 속성은 0 이상의 임의 크기 정수로, 10진수 문자열로 표현되어야 한다. 그 값은 검증가능한 크리덴셜 상태의 위치를 식별한다. 구현체는 할당의 최신성이나 그룹의 크기와 같은 추론이 그 위치로부터 쉽게 도출될 수 없도록 인덱스를 무작위로 할당하는 것이 좋다.

statusListCredential statusListCredential 속성은 검증가능한 크리덴셜을 가리키는 URL이어야 한다. 그 URL을 역참조하면, 결과로 얻는 검증가능한 크리덴셜은 BitstringStatusListCredential 값을 포함하는 type 속성을 가져야 한다.

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

statusMessage

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

status, 0x가 접두된 상태의 16진수 값을 나타내는 문자열
message, 소프트웨어 개발자가 디버깅을 돕기 위해 사용하는 문자열로, 최종 사용자에게 표시하지 않는 것이 좋다.

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

statusReference

구현자는 statusReference 속성을 포함할 수 있다. 존재하는 경우, 그 값은 상태와 관련된 자료로 역참조되는 URL 또는 URL 배열 [URL]이어야 한다. 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]에 정의된 적합 문서여야 한다. 다음 절은 상태 목록을 캡슐화하는 검증가능한 크리덴셜의 형식을 기술한다.

상태 목록은 보유자가 검증자에게 직접 제공할 수 있도록 검증가능한 크리덴셜 안에 표현된다. 때때로 "인증서 스테이플링(certificate stapling)"이라 불리는 이 메커니즘은 검증자가 상태 목록을 가져오기 위해 발급자에게 연락할 필요가 없도록 보장함으로써 보유자의 프라이버시를 높인다. 그럼에도 검증자는 예를 들어 더 최신 버전의 상태 목록을 원할 경우, 보유자가 제공한 상태 목록이 그 진정성을 검증할 수 있더라도 이를 무시하기로 선택할 수 있다.

발급자와 검증자는 검증가능한 크리덴셜의 발급자와 연관된 BitstringStatusListCredential의 발급자가 서로 다를 수 있음에 유의해야 한다. 원본 크리덴셜에 대한 권한과, 그러한 크리덴셜을 폐기하거나 그 상태를 달리 변경할 권한을 분리하는 것이 적절하도록 만드는 기술적, 법적, 제도적, 정치적, 기타 이유가 있을 수 있다. 따라서 BitstringStatusListEntry를 포함하는 검증가능한 크리덴셜의 issuer 값은 BitstringStatusListCredential의 issuer 값과 다를 수 있다.

속성 설명

id 상태 목록을 포함하는 검증가능한 크리덴셜은 대응하는 BitstringStatusListEntry의 statusListCredential에 지정된 값과 일치하는 id 속성을 표현할 수 있다(2.1 BitstringStatusListEntry 참고).

type 상태 목록을 포함하는 검증가능한 크리덴셜은 BitstringStatusListCredential 값을 포함하는 type 속성을 표현해야 한다.

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

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

credentialSubject.type 상태 목록인 크리덴셜 주체의 type은 BitstringStatusList이어야 한다.

credentialSubject.statusPurpose

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

값	설명
`refresh`	크리덴셜의 갱신 서비스(refresh service) 기능을 통해 갱신된 검증가능한 크리덴셜이 제공됨을 알리는 데 사용된다. 이 상태는 검증가능한 크리덴셜을 무효화하지 않으며 되돌릴 수 없다.
`revocation`	검증가능한 크리덴셜의 유효성을 취소하는 데 사용된다. 이 상태는 되돌릴 수 없다.
`suspension`	검증가능한 크리덴셜의 수락을 일시적으로 방지하는 데 사용된다. 이 상태는 되돌릴 수 있다.
`message`	검증가능한 크리덴셜과 연관된 상태 메시지를 나타내는 데 사용된다. 상태 메시지 설명은 `credentialSubject.statusMessages`에 정의되어야 한다. 이 `statusPurpose` 값을 사용할 때는 `credentialSubject.statusSize`가 지정되어야 한다.

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

credentialSubject.ttl ttl은 리프레시가 시도되는 것이 좋은 시점까지의 "수명(time to live)"을 밀리초 단위로 나타내는 선택 속성이다. 존재하지 않으면 기본값을 가정하지 않는다. 이 값은 BitstringStatusList의 유효 기간을 재정의하거나 대체하지 않는다. 상태 목록을 발행하는 구현체는 HTTP Cache-Control 헤더와 같은 프로토콜별 캐싱 정보를 이 필드의 값과 정렬하는 것이 좋다.

아래 예시는 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가 발생되어야 한다.

BitstringStatusListCredential을 생성할 때는 다음 과정, 또는 정확히 동일한 출력을 만드는 과정을 따라야 한다. 이 알고리즘은 issued credentials 목록을 입력으로 받아 오류를 던지거나 상태 목록 크리덴셜을 출력으로 반환한다.

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

발급자는 상태 목록 크리덴셜을, 캐시할 수 있고 누가 그것을 가져가는지 추적하지 않는 방식으로 — 예를 들어 Oblivious HTTP를 통하거나, 발급자가 운영하지 않는 콘텐츠 배포 네트워크를 통하거나, 접근 로그를 데이터 분석가나 시스템 관리자가 접근할 수 없는 업무 프로세스를 통해 — 발행하는 것이 좋다.

BitstringStatusListCredential에 포함된 검증가능한 크리덴셜의 유효성을 검사할 때는 다음 과정, 또는 정확히 동일한 출력을 만드는 과정을 따라야 한다. 이 알고리즘은 상태 목록 검증가능한 크리덴셜을 입력으로 받아 오류를 던지거나 상태 목록 크리덴셜을 출력으로 반환한다.

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가 발생되어야 한다.
result를 빈 맵으로 둔다.
result의 status 키를 status로 설정하고, result의 purpose 키를 statusPurpose의 값으로 설정한다.
status가 0이면 result의 valid 키를 true로 설정하고, 그렇지 않으면 false로 설정한다.
statusPurpose가 message이면, result의 message 키를 statusMessages 배열에 표시된 대로 그 value에 대응하는 message로 설정한다.
result를 반환한다.

statusListCredential URL이 역참조될 때, 서버 구현체는 특정 시점 기준의 상태 목록을 역참조하는 메커니즘을 제공할 수 있다. 발급자가 그러한 메커니즘을 제공하면, 검증자가 매시간, 매일, 매주 등 발급자가 선택한 정밀도로 상태 변화를 판단할 수 있게 된다. 그러한 기능이 지원되고 URL 스킴이 쿼리 파라미터를 지원하면, 쿼리 파라미터의 이름은 timestamp여야 하고 그 값은 유효한 URL 인코딩된 [XMLSCHEMA11-2] dateTimeStamp 문자열 값이어야 한다. 그러한 timestamp 파라미터가 붙은 URL을 역참조한 결과는 주어진 시점에 존재했던 상태 목록을 담은 상태 목록 크리덴셜이거나 STATUS_RETRIEVAL_ERROR 중 하나여야 한다. 결과가 오류이면, 검증자의 유효성 검사 규칙이 그러한 조치를 허용하는 한, 구현체는 다른 timestamp 값으로 또는 timestamp 값 없이 검색을 다시 시도할 수 있다.

검증자는 가져온 상태 목록을 캐시하는 것이 좋으며, Oblivious HTTP와 같이 발급자로부터 검색 행위를 숨기는 프록시나 기타 메커니즘을 사용하는 것이 좋다.

참고: 발급자 유효성 검사는 사용 사례에 따라 다르다

검증자는 어느 크리덴셜에 담긴 정보든 추가적인 의사결정 목적으로 사용하기 전에, 검증가능한 크리덴셜의 발급자와 연관된 BitstringStatusListCredential의 발급자를 신뢰하는지 확인할 것으로 기대된다. 구현자는 이러한 크리덴셜의 발급자가, 예를 들어 검증가능한 크리덴셜의 원래 발급자가 그 유효성 기록을 유지하지 않는 경우처럼, 서로 다를 수 있음에 유의해야 한다.

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

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

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

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

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

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

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

STATUS_RETRIEVAL_ERROR: 상태 목록 검색에 실패했다. 3.2 유효성 검사 알고리즘절을 참고하라.
STATUS_VERIFICATION_ERROR: 상태 항목의 유효성 검사에 실패했다. 3.2 유효성 검사 알고리즘절을 참고하라.
STATUS_LIST_LENGTH_ERROR: 상태 목록 길이가 무리 프라이버시(herd privacy)에 필요한 최소 길이를 충족하지 않는다. 3.2 유효성 검사 알고리즘절을 참고하라.

2. 데이터 모델 절의 정보를 보안 처리하는 방법은 여러 가지가 있다. 이러한 메커니즘은 Verifiable Credentials Data Model v2.0의 보안 메커니즘(Securing Mechanisms) 절에서 자세히 설명된다.

BitstringStatusListCredential에 대한 참조를 포함하는 검증가능한 크리덴셜을 보안 처리할 때, 구현자는 두 검증가능한 크리덴셜 모두에 대해 동일한 암호 파라미터와 동일한 미디어 타입을 갖는 동일한 보안 메커니즘을 사용하는 것이 좋다.

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이 있다.

운전면허증 식별 번호와 같은 전역 식별자를 포함하는 검증가능한 크리덴셜을 제시하는 경우처럼, 어떤 경우에는 상태 목록 정보를 위한 하나 이상의 전역 식별자를 추가해도 상관관계 피해가 증가하지 않는다. 상관관계에는 전역적으로 고유한 식별자 하나만 있으면 충분하기 때문이다.

전역 식별자가 선택적 공개 또는 연결 불가능한 공개를 사용하는 프레젠테이션에서 사용되면, 프라이버시 기대를 침해할 수 있다. 특정 검증가능한 크리덴셜이, 예를 들어 개인이 특정 연령 이상임을 증명할 때처럼 상관관계가 필요 없는 방식으로 공개될 것으로 예상되는 경우, 발급자는 상태 정보를 선택적으로 공개/은닉할 수 있게 할 것을 권장한다. 검증자는 크리덴셜의 현재 상태를 알아야 하는 상황에서 상태 정보가 공개되도록 요구할 수 있으며, 그러면 보유자는 주어진 거래에 대해 그 정보를 공개하는 데 동의하거나 거부할 수 있다. 모든 경우에, 발급자와 검증자 모두 특정 교환에 필요하거나 그 교환이 요구하지 않는 한, 상관관계를 방지하기 위해 전역 식별자의 사용을 피할 것을 권장한다.

다른 유형의 잠재적 상관관계에 대한 정보는, 독자가 Verifiable Credentials Data Model v2.0 규격의 프라이버시 고려사항 절, 특히 식별자 기반 상관관계, 서명 기반 상관관계, 장기 식별자 기반 상관관계, 메타데이터 기반 상관관계에 관한 하위 절을 연구할 것을 권장한다.

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

검증자는 원격 서버에서 가져온 상태 목록을 캐시함으로써, 검사 대상인 검증가능한 크리덴셜의 보유자의 프라이버시를 높일 수 있다. 콘텐츠를 로컬에 캐시하면, 상태 목록에 대한 검증자 기반 접근 패턴에서 상관지을 수 있는 정보가 덜 추론된다.

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

발급자가 콘텐츠 배포 네트워크를 사용하면 발급자에 대한 상태 목록 요청을 줄이거나 없앰으로써 보유자의 프라이버시를 높일 수 있다. 폐기 목록에 대한 요청은 종종 엣지 장치가 처리하므로 더 빠르고 서버의 부하를 줄이며, 아울러 검증자와 보유자를 발급자로부터 가린다.

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

상태 목록에 미끼 값을 사용하는 발급자의 방식은 주체의 프라이버시를 높이는 메커니즘으로 탐구되어 왔다. 미끼 값을 사용하는 알고리즘은 이 규격의 범위를 벗어나지만, 구현자는 미끼 값이 상태 목록과 연관된 집단을 정확히 시뮬레이션하지 못하면 프라이버시를 해칠 수 있음에 유의해야 한다. 미끼 값을 실제 값과 구별할 수 있으면, 집합이 제공하는 익명성은 미끼로 탐지 가능한 미끼 값의 수만큼 감소한다. 가장 프라이버시를 잘 보호하는 상태 목록은 결코 변하지 않는 목록이다. 관찰 가능한 사건이 발생하지 않으면 집단의 행동을 알 수 없기 때문이다.

집단에 대한 상태 항목을 통계적으로 시뮬레이션하기가 얼마나 어려운지, 그리고 검증가능한 크리덴셜이 광범위한 사용 사례에 쓰이므로 일반적인 조언을 제시할 수 없다는 점을 감안하여, 구현자는 상태 목록 항목 인덱스를 무작위로 할당하고, 상태 항목이 변경되는 비율을 최소화 — 이상적으로는 전혀 변경하지 않도록 — 할 것을 권장한다. 상태 목록 항목의 할당은 상태 목록의 관찰 가능한 변화를 전혀 유발하지 않을 때 프라이버시를 가장 잘 보호한다.

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

일반적으로, 이 규격이 제공하는 그룹 프라이버시 보호는 악의적인 발급자와 검증자에 의해 우회될 수 있다. 그 프라이버시 이점은 발급자와 검증자가 특정 크리덴셜의 프레젠테이션을 추적하거나 공유하지 않으려 할 때에만 실현될 수 있다.

악의적인 검증자는 제시된 크리덴셜의 정보를 악의적인 발급자와 공유함으로써 의도적으로 그룹 프라이버시를 공격할 수 있다. 이러한 유형의 결탁은 일반적으로 발급자와 검증자 사이의 보안 통신 채널을 통해 이루어지므로 탐지하기 어렵다.

악의적인 발급자는 발급된 각 크리덴셜마다 고유한 상태 목록을 만들어, 매핑된 각 크리덴셜을 검증자가 처리하는 시점을 추적할 일대일 매핑을 확립함으로써 의도적으로 그룹 프라이버시를 공격할 수 있다. 마찬가지로, 특정 상태 목록이 추적하는 발급된 각 크리덴셜마다 다른 암호 키를 사용하여 일대일 매핑을 확립할 수도 있다.

이러한 유형의 결탁은, 예를 들어 검증가능한 크리덴셜 내에서 사용된 일부 전역 식별자가 다른 크리덴셜에 의해 충분히 공유되지 않는다는 것을 찾아내는 옵트인 프로세스를 갖춘, 여러 보유자를 처리하는 보유자 소프트웨어(예: 서버에서 실행되는 보유자 앱)에 의해 탐지될 수 있다. 그러면 보유자는 해당 크리덴셜에 고유한 일부 전역 식별자를 포함하는 검증가능한 크리덴셜을 제시할 때 경고를 받을 수 있다. 그러한 옵트인 서비스는 일부 추가적인 프라이버시 우려를 나타낼 수 있다. 보유자 소프트웨어를 통한 이 잠재적 노출이 가능한 전역 식별자 상관관계에 대한 인식으로 정당화되는지는 그러한 시스템의 사용자만이 평가할 수 있다.

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

검증자가 특정 보유자 또는 주체와 연관된 상태 목록과 항목 인덱스를 알게 되면, 상태 목록이 계속 업데이트되는 한 그 검증자가 해당 상태 항목의 업데이트를 볼 수 있게 된다. 이는 특정 검증가능한 크리덴셜에 대한 상태 정보를 발급자에게 직접 묻지 않고 특정 검증가능한 크리덴셜의 상태가 언제 바뀌었는지를 파악해야 하거나, 최신 상태 정보를 얻기 위해 보유자와 상호작용하는 것이 불가능한 검증자에게 유용하다. 이 기능은 또한 검증자가 검증가능한 크리덴셜의 상태에 대해 거의 실시간으로 확인할 수 있는 경우 보유자 및/또는 주체의 프라이버시 침해를 유발할 수 있다.

발급자는 사실상 동일한 검증가능한 크리덴셜을 비교적 짧은 주기로 폐기하고 재발급함으로써 보유자에게 이 프라이버시 우려로부터 어느 정도의 완화를 제공할 수 있다. 예를 들어, 발급자는 검증가능한 크리덴셜을 3개월마다 자동으로 재발급하고 재발급이 일어날 때 새로운 상태 항목 인덱스를 할당하여, 검증가능한 크리덴셜이 상태를 바꿀 때 이루어지는 어떠한 장기 모니터링도 끊을 수 있다.

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

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

예를 들어, 각 상태 메시지가 특정 프로세스의 한 단계, 또는 크리덴셜이 폐기되거나 정지된 이유에 대한 더 상세한 정보와 연관되어 있으면, 목록의 변화를 관찰하는 공격자는 목록에 있는 엔티티 집단에 대한 정보를 상관지어 프라이버시 침해로 이어질 수 있다. 집단이 비즈니스 프로세스를 어떻게 진행하는지, 또는 집단의 몇 퍼센트가 특정 상태와 연관될 가능성이 있는지를 이해하면 공격자에게 추가 정보를 제공한다. 그러한 정보가 있으면, 피싱 작전은 비즈니스 프로세스의 다음 단계가 무엇인지 예측한 다음 현재 상태가 알려진 엔티티에 선제적으로 접촉할 수 있다. 그런 다음 그 정보를 바탕으로, 시간이 지나며 상태 목록에서 수집한 데이터를 사용하여 대상으로부터 더 값진 정보를 피싱하려 시도할 수 있다.

이러한 이유로, 발급자는 특정 엔티티 또는 집단에 대한 상세한 상태 정보를 공개적인 방식으로 발행하는 것의 잠재적 파장을 평가할 것을 권장한다.

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

상태 목록이 상태 메시지 기능을 사용하면, 발급자가 시간이 지나며 자신이 발급하는 검증가능한 크리덴셜과 연관된 메시지의 유형을 늘리는 것이 가능해진다.

이 기능은 검증가능한 크리덴셜의 주체 또는 보유자가, 원래의 검증가능한 크리덴셜이 발급될 때는 없었던 추가 상태 정보와 연관될 수 있는 잠재적 프라이버시 침해를 만든다. 예를 들어, 초기 상태 메시지는 "지연됨"과 "취소됨"을 전달할 수 있지만, 발급자가 "미납으로 인한 지연"과 "불법 활동으로 인한 취소"를 전달하는 추가 상태 메시지를 더할 수 있다. 이 변화는, 발급자가 자신들의 활동에 대한 추가 정보를 노출하려 한다는 것을 경고해 줄 모니터링 소프트웨어가 그들을 대신하여 작동하지 않는 한, 주체나 보유자에게 드러나지 않을 것이다.

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

Bitstring Status List v1.0

Privacy-preserving status information for Verifiable Credentials

요약

현재 문서의 상태

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. Revision History

C. References

C.1 Normative references

C.2 Informative references