검증가능한 크리덴셜은 무엇인가?

물리적 환경에서 크리덴셜은 다음과 같은 정보로 구성될 수 있다.

• 크리덴셜 주체의 식별과 관련된 정보(예: 사진, 이름 또는 식별 번호)
• 발행 기관과 관련된 정보(예: 시 정부, 국가 기관 또는 인증 기관)
• 크리덴셜 유형과 관련된 정보 (예: 네덜란드 여권, 미국 운전 면허증 또는 건강 보험증)
• 발행 기관이 주체에 대해 주장하는 특정 속성과 관련된 정보 (예: 국적, 운전 할 자격이 있는 차량의 클래스 또는 생년월일)
• 크리덴셜이 파생된 방법에 대한 증거
• 크리덴셜의 제약 조건과 관련된 정보(예: 만료 날짜 또는 사용 약관).

검증가능한 크리덴셜은 물리적 크리덴셜이 나타내는 것과 동일한 모든 정보를 나타낼 수 있다. 검증가능한 크리덴셜은 디지털 서명과 같은 기술을 추가하여 물리적 크리덴셜보다 신뢰할 수 있고 변조확인이 가능하도록(Tamper-evident) 만들 수 있다.

검증가능한 크리덴셜의 보유자는 검증가능한 프레젠테이션을 생성한 다음 검증가능한 프레젠테이션을 검증자와 공유하여 특정 특성을 가진 검증가능한 크리덴셜을 보유하고 있음을 증명할 수 있다.

검증가능한 크리덴셜과 검증가능한 프레젠테이션은 신속하게 전송 가능하므로, 먼 거리에서 신뢰를 구축하려고 할 때 물리적 크리덴셜보다 더 편리하다.

본 사양의 목표는 디지털 크리덴셜 표현의 용이성을 향상시키려는 것이지만, 그와 더불어 개인 정보 보호 목표와의 균형을 맞추고자 한다. 디지털 정보의 지속성과 이질적인 디지털 데이터 소스를 수집하고 상호 연관시킬 수 있다는 용이성은, 검증가능하면서도 쉽게 기계가 읽을 수 있는 크리덴셜의 사용이 개인 정보 보호를 악화시킬 수 있다는 우려를 야기한다. 본 문서의 섹션 에서 이러한 여러 문제를 간략하게 다룬다. 또한 문서 전체적으로 영지식증명(Zero-knowledge Proof)과 같은 프라이버시 향상 기술을 사용하여 어떻게 이 데이터 모델을 활용할 수 있는지에 대한 예제도 제공한다.

생태계 개요

본 섹션에서는 검증가능한 크리덴셜이 유용할 것으로 예상되는 생태계에서 핵심 행위자들의 역할과 그들 간의 관계에 대해 설명한다. 역할은 여러 가지 방법으로 구현할 수 있는 추상화된 개념이다. 역할의 분리는 표준화를 위한 인터페이스와 프로토콜을 시사한다. 이 사양에서는 다음과 같은 역할이 등장한다:

보유자 holder

하나 이상의 검증가능한 크리덴셜을 보유하고 그것으로부터 검증가능한 프레젠테이션을 생성하는 역할. 보유자의 사례로는 학생, 직원, 고객 등이 있다.

발급자 issuer

하나 이상의 주체에 대한 클레임을 확증하고, 이러한 클레임으로부터 검증가능한 크리덴셜을 생성하며, 보유자에게 검증가능한 크리덴셜을 전달하는 역할. 발급자의 사례로는 회사, 비영리 단체, 무역 협회, 정부, 개인 등이 있다.

주체 subject

클레임의 대상이 되는 엔터티. 주체의 사례로는 인간, 동물 그리고 사물이 있다. 대부분의 경우 검증가능한 크리덴셜의 보유자가 주체이지만 경우에 따라서는 그렇지 않을 수도 있다. 예를 들면, 부모(보유자)는 자녀(주체)의 검증가능한 크리덴셜을 보유하거나, 애완동물 주인(보유자)이 애완동물(주체)의 검증가능한 크리덴셜을 보유할 수 있다. 이러한 특수한 경우에 대한 자세한 내용은 부록 참조.

검증자 verifier

검증 절차를 위해 하나 이상의 검증가능한 크리덴셜, 혹은 검증가능한 프레젠테이션을 받는 역할. 검증자의 사례로는 직원, 보안 담당자, 웹사이트 등이 있다.

검증가능한 데이터 레지스트리 verifiable data registry

검증가능한 크리덴셜 스키마, 폐기 레지스트리, 발급자 공개 키 등과 같은 식별자, 키 및 기타 관련 데이터의 생성 및 확인을 중재하는 역할. 검증가능한 데이터 레지스트리에는 신뢰할 수 있는 데이터베이스, 분산된 데이터베이스, 정부 ID 데이터베이스 및 분산 원장이 포함된다. 종종 하나의 생태계에서 사용되는 검증가능한 데이터 레지스트리 유형이 여러 개 있는 경우가 있다.

위의 그림 은 본 명세서에서 설명하는 개념의 기반을 형성하는 생태계의 예제이다. 보호된 환경이나 독점 시스템과 같은 다른 생태계도 존재하며, 다른 생태계에서도 검증가능한 크리덴셜은 이점을 제공한다.

유스케이스와 요구 사항

검증가능한 크리덴셜 유스케이스 문서[[VC-USECASES]]는 독자가 유용하게 사용할 수 있는 여러 가지 주요 주제를 간략하게 설명한다:

• 위에서 소개한 역할에 대한 보다 자세한 설명
• 교육, 금융, 의료, 소매, 전문 라이센스 및 정부와 같은 시장에서 확인된 요구 사항
• 생태계의 역할에 의해 수행되는 일반적인 작업과 관련된 요구 사항
• 워킹 그룹에서 식별한 공통 시퀀스 및 흐름

유스케이스를 문서화하고 분석한 결과, 본 사양에 대해 다음과 같은 바람직한 생태계 특성이 확인되었다:

• 검증가능한 크리덴셜은 변조 검증이 가능하고 개인 정보 보호에 중요한 방식으로 발급자가 작성한 진술을 나타낸다.
• 보유자는 다른 발급자의 검증가능한 크리덴셜 컬렉션을 단일 아티팩트인 검증가능한 프레젠테이션으로 수집한다.
• 발급자는 모든 주체에 대해 검증가능한 크리덴셜을 발급할 수 있다.
• 발급자, 보유자 또는 검증자로서 행동하는 것은 당사자 간에 신뢰 관계이기 때문에 어떤 당국의 등록이나 승인이 필요하지 않다.
• 검증가능한 프레젠테이션을 통해 모든 검증자는 어느 발급자가 발급한 검증가능한 크리덴셜이라도 그 신뢰성을 확인할 수 있다.
• 보유자는 누구에게나 검증가능한 크리덴셜을 받을 수 있다.
• 보유자는 어떤 사용자 에이전트를 통하더라도 모든 발급자 및 검증자와 상호 작용할 수 있다.
• 보유자는 검증가능한 프레젠테이션을 공유할 수 있으며, 이 검증가능한 프레젠테이션은 발급자에게 검증자의 신원을 공개하지 않고도 검증할 수 있다.
• 보유자는 검증가능성에 영향을 미치지 않고 발급자가 저장위치 또는 액세스 시기에 대해 전혀 알지 못하면서도 검증가능한 크리덴셜을 저장할 수 있다.
• 보유자는 클레임의 신뢰성에 영향을 미치지 않고 발급자에 해당 조치를 공개하지 않고 검증가능한 프레젠테이션을 모든 검증자에게 제출할 수 있다.
• 검증자는 모든 발급자의 클레임 증명을 포함하는 모든 보유자의 검증가능한 프레젠테이션을 검증할 수 있다.
• 검증은 발급자와 검증자 간의 직접적인 상호 작용에 의존하지 않는다.
• 검증은 어떤 발급자에게도 검증자의 신원을 공개하지 않아야한다.
• 발급자가 선택적 공개를 지원하는 소프트웨어가 없는 경우에도, 이 사양은 선택적 공개를 지원하는 검증가능한 크리덴셜을 발급할 수 있는 수단을 제공해야 한다.
• 발급자는 선택적 공개를 지원하는 검증가능한 크리덴셜을 발급할 수 있다.
• 단일 검증가능한 크리덴셜이 선택적 공개를 지원하는 경우 보유자는 전체 검증가능한 크리덴셜을 공개하지 않고 클레임을 제시할 수 있다.
• 검증가능한 프레젠테이션은 검증가능한 크리덴셜의 특성을 공개하거나 검증자가 요청한 파생된 조건자를 충족할 수 있다. 파생된 조건자는 보다 큰, 보다 적은, 같음, 집합 등 부울 조건이다.
• 발급자는 폐기할 수 있는 검증가능한 크리덴셜을 발급할 수 있다.
• 검증가능한 크리덴셜 및 검증가능한 프레젠테이션은 하나 이상의 기계 판독 가능한 데이터 형식으로 직렬화할 수 있어야 한다. 직렬화 및/또는 직렬화 해제 프로세스는 결정적이고 양방향이며 무손실이어야 한다. 검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 모든 직렬화는 최종 프로세스에서 이 문서에 정의된 일반 데이터 모델로 변환할 수 있어야 하며, 그에 따라 검증가능한 크리덴셜을 상호 운용 가능한 방식으로 처리할 수 있다. 또한 직렬화된 양식은 데이터 또는 콘텐츠의 손실 없이 데이터 모델에서 생성될 수 있어야 한다.
• 데이터 모델과 직렬화는 최소한의 조정으로 확장할 수 있어야 한다.
• 발급자에 의한 폐기는 주체, 보유자, 특정 검증가능한 크리덴셜 또는 검증에 대한 식별 정보를 공개하지 않아야한다.
• 발급자는 폐기 사유를 공개할 수 있다.
• 검증가능한 크리덴셜을 폐기하는 발급자는 암호화 무결성에 의한 폐기(예: 서명 키가 손상된 경우)와 상태 변경에 의한 폐기(예: 운전 면허증이 일시 중단됨)를 구분해야 한다.
• 발급자는 검증가능한 크리덴셜을 갱신하는 서비스를 제공할 수 있다.

클레임

클레임은 주체에 대한 진술이다. 주체는 클레임을 할 수 있으며, 주체-속성-값 관계를 사용하여 표현한다.

위 에 설명된 클레임의 데이터 모델은 강력하며 다양한 구문을 표현하는 데 사용될 수 있다. 예를 들어, 특정 대학을 졸업한 사람은 아래 과 같이 표현될 수 있다.

독립된 클레임을 합쳐서 주체에 대한 정보를 나타내는 그래프를 표현할 수 있다. 아래 의 예시는 Pat이 Sam을 알고 있으며 Sam이 교수로 채용되었다는 클레임을 추가하여 이전 클레임을 확장한다.

이 시점에서, 클레임의 개념과 정보 그래프를 소개한다. 클레임을 신뢰하기 위하여 더 많은 정보가 그래프에 추가될 것으로 예상한다.

크리덴셜

크리덴셜은 동일한 엔터티가 만든 하나 이상의 클레임 집합이다. 크리덴셜에는 발급자, 유효기한, 대표 이미지, 검증 목적으로 사용할 공개키, 해지 메커니즘 등과 같은 크리덴셜의 속성을 설명하는 식별자 및 메타데이터도 포함될 수 있다. 메타데이터는 발급자가 서명한 것일 수 있다. 검증가능한 크리덴셜은 누가 이를 발급했는지 암호학적으로 증명하는 위변조 방지 클레임 및 메타데이터 집합이다.

검증가능한 크리덴셜의 예로는 전자 직원 신분증, 전자 출생 증명서, 전자 교육 증명서가 있다.

크리덴셜 식별자는 종종 크리덴셜의 특정 인스턴스를 식별하는 데 사용된다. 이러한 식별자는 상관 관계에 사용될 수도 있다. 상관 관계를 최소화하려는 보유자는 크리덴셜 식별자를 밝히지 않는 선택적 공개 체계를 사용하는 것이 좋다.

위 는 검증가능한 크리덴셜의 기본 구성 요소를 보여 주지만, 클레임이 정보 그래프로 구성되고 검증가능한 크리덴셜로 구성되는 방식에 대한 세부 정보를 추상화 한다. 하단의 은 검증가능한 크리덴셜을 더 완벽하게 묘사한 것으로 일반적으로 두 개 이상의 정보 그래프로 구성된다. 첫 번째 그래프는 크리덴셜 메타데이터와 클레임을 포함하는 검증가능한 크리덴셜을 표시한다. 두 번째 그래프는 일반적으로 전자 서명인 디지털 프루프를 표현한다.

결혼 증명서와 같은 크리덴셜을 소유할 수 있으며, 포함되지 않아도 되는 다른 주체에 대한 여러 가지 클레임을 포함할 수 있다.

크리덴셜이 발급된 엔터티에 대한 어떠한 클레임도 포함하지 않는 크리덴셜을 가질 수 있다. 예를 들어, 특정 강아지에 대한 클레임을 포함하는 소유자에게 발급되는 크리덴셜이다.

프레젠테이션

프라이버시 향상은 본 규격서의 핵심 디자인 기능이다. 따라서, 본 기술을 사용하는 엔터티는 주어진 상황에 적절한 자신의 페르소나 부분만 표현할 수 있어야 한다. 페르소나의 부분 집합 표현을 검증가능한 프레젠테이션이라고 한다. 다른 페르소나의 예시는 개인의 전문 페르소나, 온라인 게임 페르소나, 가족 페르소나, 시크릿 페르소나가 있다.

검증가능한 프레젠테이션은 하나 이상의 검증가능한 크리덴셜의 데이터를 표현하며, 데이터의 소유권을 검증할 수 있는 방식으로 포장된다. 검증가능한 크리덴셜이 직접 제공되면 검증가능한 프레젠테이션이 된다. 암호학적 방식으로 검증할 수 있지만 검증가능한 크리덴셜를 포함하지 않는 검증가능한 크리덴셜에서 파생된 데이터 형식도 검증가능한 프레젠테이션일 수 있다.

프레젠테이션의 데이터는 종종 같은 주체에 관한 것 이지만 여러 발급자가 발급했을 수 있다. 이 정보의 집합은 일반적으로 개인, 조직, 엔터티의 관점을 표현한다.

위 은 검증가능한 프레젠테이션의 구성 요소를 보여주지만, 간략하게 검증가능한 크리덴셜이 정보 그래프로 구성되어 검증가능한 프레젠테이션으로 구성되는 방법에 대한 세부 사항을 요약한다. 하단의 은 검증가능한 프레젠테이션을 더 완벽하게 묘사한 것으로, 일반적으로 최소 4 개의 정보 그래프로 구성된다. 첫 번째 그래프는 프레젠테이션 메타데이터가 포함된 검증가능한 프레젠테이션을 표현한다. 그래프의 verifiablePresentation 속성은 크리덴셜 메타데이터 및 클레임을 포함하는 하나 이상의 검증가능한 크리덴셜 (각각 독립 그래프)을 표현한다. 세 번째 그래프는 일반적으로 전자서명인 크리덴셜 그래프 프루프 를 표현한다. 네 번째 그래프는 일반적으로 전자서명인 프레젠테이션 그래프 프루프 를 표현한다.

비즈니스 페르소나와 같은 프레젠테이션을 가질 수 있다. 비즈니스 페르소나는 종종 연관되어 있지만 필요하지 않은 다른 주체에 대한 여러 크리덴셜을 사용한다.

완전한 수명주기 예제

이전 섹션에서는 그래픽 개념을 사용하여 클레임, 검증가능한 크리덴셜 및 검증가능한 프레젠테이션 등의 개념을 소개했다. 이 섹션에서는 이 사양에서 지원하는 구체적인 구문 중 하나로 표현 된 데이터 모델의 단순하지만 완전한 수명주기 예제를 제공한다. 에서 크리덴셜 및 프레젠테이션의 수명주기는 종종 다음과 같은 공통 경로를 취한다:

1. 하나 이상의 검증가능한 크리덴셜 발급
2. 크리덴셜 저장소 (예 : 디지털 지갑)에 검증가능한 크리덴셜 저장
3. 검증자를 위해 검증가능한 크리덴셜을 검증가능한 프레젠테이션으로 구성
4. 검증자에 의한 검증가능한 프레젠테이션의 검증

이 수명주기를 설명하기 위해 대학에서 동문 할인을 사용하는 예를 사용한다. 아래 예에서 Pat은 대학교로부터 동문 검증가능한 크리덴셜을 받고, 검증가능한 크리덴셜을 디지털 지갑에 저장한다.

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  // specify the identifier for the credential
  "id": "http://example.edu/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "AlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://example.edu/issuers/565049",
  // when the credential was issued
  "issuanceDate": "2010-01-01T19:73:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  // digital proof that makes the credential tamper-evident
  // see the NOTE at end of this section for more detail
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}
        

Pat은 동문 할인을 받으려 한다. 티켓 판매 시스템인 검증자는 "Example University"의 모든 동창생이 스포츠 행사에 대한 시즌 티켓 할인을 받는다. Pat은 모바일 장치를 사용하여 시즌 티켓 구매 프로세스를 시작한다. 이 프로세스의 단계는 동문 검증가능한 크리덴셜을 요청하며 이 요청은 Pat의 디지털 지갑으로 라우팅된다. 전자 지갑은 Pat에게 이전에 발급 된 검증가능한 크리덴셜을 제공 할 것인지 묻는다. Pat은 동문 검증가능한 크리덴셜을 선택하여 검증가능한 프레젠테이션으로 구성한다. 검증가능한 프레젠테이션이 검증자에게 전송되고 검증된다.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  // the verifiable credential issued in the previous example
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:73:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/keys/1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  // digital signature by Pat on the presentation
  // protects against replay attacks
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    // 'challenge' and 'domain' protect against replay attacks
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}
        

위에서 사용한 proof 메커니즘에 대해 더 자세히 알고 싶은 구현자는 섹션 에서 다음 사양을 자세히 알아볼 수 있다. 링크 된 데이터 증명 [[LD-PROOFS]], 링크 된 데이터 서명 [[LD-SIGNATURES]], 2018 RSA 서명 제품군 [[LDS-RSA2018]] 및 JSON 웹 서명 (JWS) 인코딩되지 않은 페이로드 옵션 [[RFC7797]]. 증명 메커니즘 목록은 검증 가능한 신임 정보 확장 레지스트리 [[VC-EXTENSION-REGISTRY]]에 있다.

프라이버시의 범주

익명부터 강하게 식별되는 범위에 이르는 프라이버시의 범주가 있음을 인지하는 것은 중요하다. 사례에 의하면, 사람들은 제공하고자하는 정보와 제공되는 정보에서 파생된 정보에 대해 서로 다른 안도감의 단계를 가지고 있다

예를 들어, 대부분의 사람들은 주류를 구입할 때 익명을 유지하기를 원하는데 그 이유는 필요한 규제 확인은 전적으로 그 사람이 특정 연령 이상인지 여부에 달려있기 때문이다. 그 대신, 의사가 환자를 위해 작성한 의료 처방전의 경우, 처방을 이행하는 약국은 의료 전문자와 환자를 강하게 식별해야 한다. 따라서 모든 사례에 적합한 하나의 프라이버시 접근법은 없다. 프라이버시 해결책은 사례에 따라 다르다.

주류를 구입할 때 익명을 유지하려는 경우에도, 상인에게 적절한 보증을 제공하기 위해 사진 신분증이 필요할 수 있다. 상인은 (당신이 특정 연령 이상이라는 것 이외에) 당신의 이름이나 다른 세부 정보를 알 필요가 없지만, 많은 경우 나이 증명은 규정을 충족하기에 아직 불충분하다.

검증가능한 크리덴셜 데이터 모델은 전체 프라이버시 범주를 지원하기 위해 노력하고 있으며, 어떤 특정 트랜잭션에 대해서도 올바른 수준의 익명성에 대한 철학적 입장을 취하지 않는다. 다음 섹션은 프라이버시에 적대적인 특정 시나리오들을 피하려는 구현자들을 위한 지침을 제공한다.

개인식별정보

credential.credentialSubject 필드에 저장된 검증가능한 크리덴셜 관련 데이터는 검증자와 공유할 경우 프라이버시 침해를 허용할 수 있다. 정부에서 발행한 식별자, 배송지 주소, 성명 등과 같은 개인식별정보는 개체를 특정하거나 추적하고 상관관계를 확인하는데 쉽게 사용될 수 있다. 비록 생일과 우편번호의 조합 같이 개인을 식별별하는데 쓸 수 없을 것 같은 정보라도 매우 강력한 상관관계 및 재식별화(De-anonymizing)의 가능성을 가지고 있다.

구현자는 이러한 종류의 특성을 가진 데이터를 공유할 경우 보유자에게 경고할 것을 강력하게 권고한다. 발급자는 가능하면 프라이버시를 보호하는 검증가능한 크리덴셜을 제공할 것을 강력하게 권고한다. 예를들면, 검증자가 개체의 성인 여부를 확인하고자 하면, 생년월일을 담은 검증가능한 크리덴셜을 발행하는 대신 ageOver 검증가능한 크리덴셜을 발행하는 것이다.

검증가능한 크리덴셜은 종종 개인식별정보(PII)를 포함하고 있기 때문에, 구현자는 검증가능한 크리덴셜을 저장하고 전송하는 과정에서 접근하지 말아야 할 사람들로부터 데이터를 보호하기 위한 메커니즘을 사용하도록 해야 한다. 고려할 수 있는 매커니즘은 전송계층보안(TLS, Transport Layer Security) 또는 그 외에 데이터 전송시에는 데이터를 암호화하고 전송 중이 아니더라도 검증가능한 크리덴셜의 데이터를 암호화하거나 접근 제어하는 수단이 있을 수 있다.

식별자 기반 상관관계

검증가능한 크리덴셜의 주체는 credential.credentialSubject.id 필드를 사용하여 식별된다. 주체를 식별하기 위해 사용되는 식별자는 식별자의 수명이 길고 하나 이상의 웹 도메인을 넘나들며 사용될 경우 더 큰 상관관계의 위험을 야기한다.

유사하게, 크리덴셜 식별자(credential.id)를 공개하는 것은러 검증자가 결탁하거나 혹은 발급자와 검증자가 결탁하여 보유자와의 상관관계를 파악할 수 있는 상황으로 이끌 수 있다. 만약 보유자가 상관관계를 줄이고 싶다면, 검증가능한 프레젠테이션을 하는 동안 식별자를 숨기는 검증가능한 크리덴셜 스킴을 사용해야 한다. 그러한 스킴은 보유자가 식별자를 생성하고 사용자로부터 식별자를 숨기는 것을 허용하는 한편 식별자를 검증가능한 크리덴셜 안에 포함하고 서명할 수 있도록 유지한다.

만약 강력한 상관관계 방지 속성이 요구되는 검증가능한 크리덴셜 체계인 경우, 식별자는 다음 중 하나를 만족하도록 강력히 권고된다:

• 단일 기원(Single origin)으로 향함
• 단일 사용(Single use)
• 한번도 사용되지 않았지만 짧은 수명의 단일 사용 전달자 토큰으로 교체됨

서명 기반의 상관관계

검증가능한 크리덴셜의 내용은 credential.proof 필드를 사용하여 보호한다. 이 필드의 속성들은 같은 값이 하나 이상의 세션 혹은 도메인에서 사용되고 그 값이 변하지 않을 경우 더 큰 상관관계의 위험을 만들 수 있다. verificationMethod, create, proofPurpose, jws 필드가 이에 속한다.

만약 강력한 상관관계 방지(Anti-Correlation) 속성이 필요할 경우, 제3자 쌍 서명, 영지식증명 또는 집단 서명 등의 기술을 사용하여 매번 서명값과 메타데이터를 재생성하는 것을 권장한다.

비록 상관관계 방지용 서명을 사용하더라도, 검증가능한 크리덴셜에는 사용된 암호 기술의 상관관계 방지 속성을 무력화시킬 수 있는 정보가 여전히 포함될 수 있다

수명이 긴 식별자 기반의 상관관계

Verifiable credentials might contain long-lived identifiers that could be used to correlate individuals. These types of identifiers include subject identifiers, email addresses, government-issued identifiers, organization-issued identifiers, addresses, healthcare vitals, verifiable credential-specific JSON-LD contexts, and many other sorts of long-lived identifiers. 검증가능한 크리덴셜은 개인의 상관관계를 파악하는데 사용될 수 있는 수명이 긴 식별자를 포함할 수 있다. 이러한 종류의 식별자에는 주체 식별자, 이메일 주소, 정부 발행 식별자, 조직 발행 식별자, 주소, 헬스케어 바이탈, 검증가능한 크리덴셜 특화 JSON-LD 컨텍스트, 그리고 수 많은 종류의 수명이 긴 식별자가 포함된다.

보유자에게 소프트웨어를 제공하는 조직은 개인의 상관관계를 파악하는데 사용되는 정보가 포함된 검증가능한 크리덴셜의 필드를 식별하여, 이 정보가 공유될 때 보유자에게 경고해야 한다

디바이스 핑거프린팅

인터넷과 웹상에서 개인을 추적하고 상관관계를 파악하는데 사용되는 검증가능한 크리덴셜 외부의 메커니즘들이 있다. 이러한 메커니즘은 인터넷 프로토콜(IP) 주소 추적, 웹 브라우저 핑거프린팅, 에버쿠키(evercookie), 광고 네트워크 추적기, 모바일 네트워크 위치 정보, 인앱 GPS API 등을 포함한다. 검증가능한 크리덴셜을 사용하는 것이 이러한 기술을 사용하는 것을 막지는 못한다. 또한, 이러한 기술들이 검증가능한 크리덴셜과 결합되어 사용되면 새로운 상관관계를 파악할 수 있는 정보들을 발견할 수도 있다. 예를 들어, 생일과 GPS 위치를 결합하면 다수의 웹사이트에서 개인에 대한 강력한 상관관계를 파악하는데 사용될 수 있다.

개인정보보호를 중요하게 여기는 시스템에서 검증가능한 크리덴셜을 사용하는 경우, 이러한 추적 기술들의 사용을 방지하도록 하는 것이 권장한다. 경우에 따라서는 보유자를 대신하여 검증가능한 크리덴셜을 전송하는 기기에서 추적 기술들이 비활성화 하는 것도 요구될 수 있다.

추상 클레임 선호(Flavor Abstract Claim

검증가능한 크리덴셜을 받는 사람이 필요 이상으로 개인식별정보를 노출하지 않으면서도 다양한 상황에서 활용할 수 있도록 하기 위해 발급자는 크리덴셜의 정보를 예상되는 목적에 필요한 최소한의 정보로 제한하는 것을 고려해야 한다. 개인식별정보를 크리덴셜에 포함하지 않도록 하는 방법 중 하나는 주체에 대한 특정한 정보를 제공하지 않으면서도 검증자의 요구를 만족시키는 추상 속성을 사용하는 것이다.

예를 들면, 본 문서는 강력한 개인식별정보인 생일을 사용하는 대신 ageOver 속성을 사용한다. 만약 특정 시장의 소매업자가 일반적으로 구매자에게 특정 나이 이상을 요구하는 경우, 그 시장에서 신뢰받는 발급자는 주체의 생일에 대한 클레임을 포함하는 검증가능한 크리덴셜을 제공하기 보다는 주체가 그 조건을 만족한다고 주장하는 검증가능한 크리덴셜을 제공하는 것을 선택할 것이다. 이로인해 개인 소비자가 특정 개인식별정보를 드러내지 않으면서도 구매를 할 수 있게 된다.

데이터 최소화 원칙

한 컨텍스트에서 유출된 정보가 다른 컨텍스트로 유출되면 개인정보보호 위반이 발생한다. 이러한 위반을 방지하기 위해 허용되는 모범 사례는 요청 및 수신한 정보를 최소한으로 제한하는 것 이다. 데이터 최소화 접근법은 미국의 HIPAA (Health Insurance Portability and Accountability Act) 및 EU의 GDPR (General Data Protection Regulation)을 포함한 여러 관할권의 규정에 의해 요구된다.

발급자를 위한 데이터 최소화가 뜻하는 것은 검증가능한 크리덴셜의 사용을 예상하여 잠재적 검증자가 요구하는 최소값으로 제한하는 것을 의미한다. 검증자의 경우 데이터 최소화는 서비스 접근에 요구 또는 정보의 범위를 제한하는 것을 의미한다.

예를 들어, 면허 번호, 키, 몸무게, 생일, 주소가 포함된 운전 면허증은 개인이 특정 연령 이상임을 확인하는데 필요한 것보다 많은 정보가 포함된 크리덴셜이다.

발급자가 정보를 원자화하거나 선택적 공개를 허용하는 서명 체계를 사용하는 것이 가장 좋은 사례이다. 예를 들어, 운전면허 발급자는 운전 면허에 나타나는 모든 속성이 포함된 검증가능한 크리덴셜과 개인의 생일과 같은 단일 속성만 포함되는 검증가능한 크리덴셜 집합을 발급할 수 있다. 또한, 더 추상적인 검증가능한 크리덴셜을 발행할 수 있다 (예 : ageOver 특성만 포함하는 검증가능한 크리덴셜). 한 가지 가능한 적용 방법은 발급자가 검증가능한 크리덴셜의 익명 사용을 촉진하는 일회용 무기명 크리덴셜을 검색하기 위한 보안 HTTP 엔드포인트를 제공하는 것이다. 부적절하거나 위험을 발견한 구현자는 선택적 공개를 사용하여 발급자에 대한 의존성을 제거하고 발급자의 일시적인 상관 위험을 줄여야 한다.

검증자는 특정 트랜젝션이 발생하는데 꼭 필요한 정보만 요청해야 한다. 이는 두 종류의 이유로 중요하다:

• 불필요한 매우 민감한 정보를 처리하는 검증자의 책임을 줄임
• 특정 트랜젝션에 필요한 정보만 요구함으로써 개인의 프라이버시를 향상

최소 공개 원칙을 실행하는 것은 가능하지만, 단일 또는 다중 세션 동안 특정 사례에서 개인의 강력한 식별을 피하는 것은 불가능할 수 있다. 본 표준의 저자는 실제 시나리오에서 원칙을 달성하는 것은 어려울 수 있다고 강요하지 않는다.

무기명 크리덴셜

무기명 크리덴셜은 콘서트 티켓과 같은 개인정보보호 강화 정보로, 보유자에게는 자신에 대한 민감한 정보를 공개하지 않고도 특정 자원에 대한 크리덴셜을 부여 할 수 있다. 무기명 크리덴셜은 종종 무기명 크리덴셜 공유가 문제가 되지 않거나 경제적 또는 평판의 손실이 크지 않은 저 위험 사례에서 사용된다.

무기명 크리덴셜인 검증가능한 크리덴셜은 credentialSubject 속성에 중첩된 id 속성을 사용하여 표현된 주체 식별자를 지정하지 않으면 가능하다. 예를 들어 다음과 같은 검증가능한 크리덴셜은 무기명 크리덴셜이다:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    // 무기명 크리덴셜에 ‘id’ 속성이 지정되어 있지 않음
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": { ... }
}
      

무기명 크리덴셜은 개인정보보호를 강화할 수 있지만, 무기명 크리덴셜 보유자가 예상한 것보다 더 많은 정보를 실수로 공개하지 않도록 신중하게 만들어야 한다. 예를 들어, 다수의 사이트에서 동일한 무기명 크리덴셜을 반복적으로 사용하면 사이트들이 담합하여 잠재적으로 보유자를 추적하거나 연동시킬 수 있다. 또한 생년월일 및 우편 번호와 같이 식별할 수 없는 것처럼 보이는 정보를 사용하여 동일한 무기명 크리덴셜 또는 세션에서 함께 사용될 경우, 개인을 통계적으로 식별할 수 있다.

무기명 크리덴셜 발급자는 무기명 크리덴셜이 다음과 같은 개인정보보호 강화를 제공하는지 확인해야 한다:

• 가능하면 일회용
• 개인 식별정보를 포함하지 않음
• 과도하게 상관되지 않음

민감한 정보가 포함된 무기명 크리덴셜이 발행, 요청되거나 하나 이상의 세션에서 두 가지 이상의 무기명 크리덴셜을 결합되거나 상관 관계 위험이 있는 경우, 소프트웨어는 보유자에게 경고해야 한다. 모든 상관 관계 위험을 감지하는 것은 불가능하지만 일부는 확실하게 감지할 수 있다.

검증자는 보유자와의 상관 관계를 파악하는데 사용할 수 있는 무기명 크리덴셜을 요청하지 말아야 한다.

유효성 검사

검증가능한 크리덴셜을 처리할 때 검증자는 의 유효성 검증 및 다양한 특정 비즈니스 프로세스 점검에 나열된 검사를 수행해야 한다. 유효성 검사는 아래 항목이 포함된다:

• 보유자의 전문 라이센스 상태.
• 라이센스 갱신 또는 폐기 날짜.
• 개인의 하위 자격.
• 보유자와 상호 작용을 시도하는 개체와 관계가 있는 경우.
• 보유자와 관련된 지리적 위치 정보.

이러한 검사를 수행하면 정보 유출로 인해 보유자의 개인정보보호 위반이 발생할 수 있다. 예를 들어 폐기 목록 확인과 같은 간단한 조작으로 특정 비즈니스가 보유자와 상호작용 한다는 것을 발급자에게 알릴 수 있다. 이는 발급자들은 담합과 연동을 개인들에 대한 정보 없이 할 수 있다.

발급자는 크리덴셜마다 검증과정에서 개인정보보호 위반이 발생할 수 있는 구간에 크리덴셜마다 고유한 폐기 목록과 같은 메커니즘을 사용하지 않아야 한다. 보유자에게 소프트웨어를 제공하는 조직은 크리덴셜 검증 과정 중에 개인정보보호 위반으로 이어질 수 있는 정보가 포함된 경우 경고해야 한다. 검증자는 개인정보 침해를 유발하거나 개인정보보호 정책을 위반하는 크리덴셜을 거부해야 한다.

저장소 제공자와 데이터 마이닝

보유자가 발급자로부터 검증가능한 크리덴셜을 받으면 검증가능한 크리덴셜은 어딘가에 저장되어야 한다 (예: 크리덴셜 저장소). 보유자는 검증가능한 크리덴셜의 정보가 본질적으로 민감하고, 고도로 개인화되어 데이터 마이닝의 가치 높은 대상이 된다는것을 경고받는다. 검증가능한 크리덴셜의 무료 저장을 홍보하는 서비스는 실제로 개인 데이터를 마이닝하여 개인 및 조직에 대한 개인화된 프로필을 구축하려는 조직에 판매하는 것일 수 있다.

보유자들은 크리덴셜 저장소의 서비스 약관, 특히 서비스 제공 업체에 검증가능한 크리덴셜을 저장하는 사람들을 위한 상관 관계 및 데이터 마이닝으로부터 보호에 대한 부분을 알고있어야 한다.

데이터 마이닝 및 프로파일링에 대한 몇가지 효과적인 방법은 다음과 같다:

• 사용자의 정보를 제 3자에게 판매하지 않는 서비스 제공자.
• 서비스 제공 업체가 크리덴셜의 내용을 볼 수 없도록 검증가능한 크리덴셜을 암호화하는 소프트웨어.
• 검증가능한 크리덴셜을 사용자가 제어하는 장치에 로컬로 저장하고 예상보다 많은 정보를 업로드하거나 분석하지 않는 소프트웨어

크리덴셜의 수집

동일한 주체에 대해 두 개의 정보를 보유하면, 그 정보가 다른 채널을 통해 전달되는 경우에도 그 주체에 대해 두 개의 합계보다 더 많은 정보를 노출하게 된다. 검증가능한 크리덴셜을 수집하는것은 프라이버시 위험이며 이 생태계의 모든 참가자들은 데이터 수집의 위험성을 알고있어야 한다.

예를 들어, 이메일 주소에 대한 크리덴셜이 하나 있고 보유자가 21세 이상이라는 사실에 대한 크리덴셜이 하나 있는 상황에서 두개의 크리덴셜이 다수의 세션에 걸쳐 공유되었다면, 검증자는 이제 그 개인에 대한 고유한 식별자와 연령 관련 정보를 갖게 된다. 이제 시간이 갈수록 그 보유자에 대한 프로필을 생성하기 점점 더 쉬워진다. 여러 사이트에서 크리덴셜 수집을 할수도 있고, 이는 심각한 프라이버시 문제를 초래할 수도 있다.

기술적인 관점에서 볼 때 정보 수집을 방지하는것은 매우 어려운 프라이버시 문제이다. 영지식증명과 같은 새로운 암호화 기술이 수집 및 상관관계 문제에 대한 솔루션으로 제안되고 있지만, 오래 지속되는 식별자와 브라우저 추적 기술의 존재는 가장 현대적인 암호화 기술조차도 능가한다.

상관관계 또는 수집의 프라이버시 영향에 대한 해결책은 본질적으로 기술적인것이 아니라 정책 중심이다. 따라서 보유자가 자신에 대한 정보가 수집되길 바라지않는 경우, 그들이 보내는 검증가능한 프레젠테이션에 표시해야 한다.

사용 패턴들

개인정보보호를 위한 최선의 노력에도 불구하고 실제로 검증가능한 크리덴셜을 사용하면 익명성이 해제되고 프라이버시가 손실될 수 있다. 이 상관관계는 다음과 같은 경우에 발생할 수 있다:

• 동일한 검증가능한 크리덴셜이 동일한 검증자에게 두 번 이상 제공되었을 경우. 검증자는 보유자가 동일한 인물임을 유추할 수 있다.
• 동일한 검증가능한 크리덴셜이 다른 검증자들에게 제공되며, 해당 검증자들들이 공모하거나 제 3자가 두 검증자 모두의 거래기록에 접근가능할 경우. 관찰자는 두 서비스에서 검증가능한 크리덴셜을 제출한 사람이 동일한 사람임을 유추할 수 있다. 즉, 계정들은 같은 사람에 의해 제어되고 있다는 사실을 알 수 있다.
• 크리덴셜의 주체 식별자가 여러 프레젠테이션들 또는 검증자들에게 동일한 경우. 서로 다른 크리덴셜이 제출되었어도 주체 식별자가 같다면 검증자들(그리고 검증 기록을 조회할 수 있는 사람들)은 크리덴셜의 보유자가 동일인물임을 유추할 수 있다.
• 크리덴셜의 기본 정보는 서비스들 전체에서 개인을 식별하는데 사용될 수 있다. 이 경우, 검증자들은 다른 출처의 정보(보유자가 직접 제공한 정보 포함)를 사용하여 크리덴셜의 내용으로 개인을 기존 프로필과 연관시킬 수 있다. 예를 들어, 보유자가 우편번호, 나이, 성별을 포함한 크리덴셜을 제시하면 검증자가 해당 크리덴셜의 주체를 설정된 프로필과 연관시킬 수 있다. 자세한 내용은 [[DEMOGRAPHICS]]를 참조.
• 크리덴셜의 식별자를 중앙화된 폐기 서버에 전달할 경우. 중앙 서버는 상호 작용에서 크리덴셜을 연관시킬 수 있다. 예를 들어 크리덴셜이 이러한 방식으로 나이를 증명하는데 사용되는 경우 중앙 서비스는 크리덴셜이 제공된 모든곳 (모든 주류 상점, 술집, 성인 상점, 복권 구매 등)을 알 수 있다.

어떤 부분들은 다음과 같은 방법으로 비익명화 및 프라이버시 손실을 완화 할 수 있다:

• 크리덴셜의 주체로 전역 고유 식별자를 사용하고 해당 크리덴셜을 재사용 하지 않을것.
• 크리덴셜이 폐기를 지원하는 경우 전세계에 분산된 서비스를 사용하여 폐기할것.
• 크리덴셜의 ID 제출에 의존하지 않는 크리덴셜 폐기 API 설계. 예를 들어, 쿼리 대신 폐기 목록을 사용할 것.
• 개인 식별 정보와 특정 장수식별자와의 연관성을 피할것

이러한 완화 기술이 항상 실용적이거나 필요한 사용법과 호환되는 것은 아님을 이해해야 한다. 때로는 상관관계가 필요하기도 하다.

예를 들어, 일부 처방약 모니터링 프로그램에서는 사용량 모니터링이 필요하다. 집행 주체는 개인이 통제 약품에 대해 복수의 처방을 받기 위해 시스템을 속이는 것이 아님을 확인할 수 있어야 한다. 사용량의 상관관계를 위한 법규나 규정은 개인의 프라이버시 문제보다 중요하다.

검증가능한 크리덴셜은 서비스들 사이에서 의도적으로 연관시키는 경우가 있다. 예를 들어, 동일 페르소나가 다수의 서비스에 로그인 할 때, 각각의 서비스에서 활동들이 의도적으로 동일 인물에게 연결된다. 이러한 각 서비스들이 예상한 방식으로 상관관계를 사용하는 한 프라이버시 문제는 아니다.

크리덴셜을 사용하여 의도하지 않거나 예기치 않은 상관관계가 발생하면 크리덴셜의 프라이버시 위험이 발생한다.

잘못된 당사자에게 정보 공유

어떤 보유자가 어떤 검증자와 정보를 공유하기로 결정했을 때, 그 검증자는 정직하지 못하게 행동하면서 보유자에게 해를 끼치는데 사용할 수 있는 정보를 요청하는 경우가 발생할 수 있다. 예를 들어, 검증자는 은행 계좌 번호를 요청하고 다른 정보와 함께 사용함으로써 보유자나 은행을 속일 수 있다.

발급자는 가능한 많은 정보를 토큰화함으로써, 보유자가 뜻하지 않게 크리덴셜들을 잘못된 검증자에게 전달한 경우에도, 그 상황이 재앙이 되지 않도록 노력해야 한다.

예를 들어 개인의 은행 잔고를 확인하기 위해 은행 계좌 번호를 (검증가능한 크리덴셜에) 포함하는 대신에, 잔액이 얼마 이상인지만 검증자가 확인하는데 사용할 수 있는 토큰을 제공할 수 있다. 이 경우에 은행은 잔액 확인용 토큰이 포함된 검증가능 크리덴셜을 보유자에게 발급할 수 있다. 보유자는 그 검증가능한 크리덴셜을 검증가능한 프레젠테이션에 포함하고, 전자 서명을 이용하여 그 토큰을 신용 조회 기관에 결합시킨다. 검증자는 그들의 전자서명으로 검증가능한 프레젠테이션을 한번 감싸고, 그것을 발급자에게 돌려주므로써 동적으로 계좌 잔액을 확인할 수 있다.

이러한 접근 방식을 이용하여, 보유자가 계좌 잔액 토큰을 잘못된 당사자에게 공유했다 하더라도 공격자는 은행 계좌 번호나 정확한 계좌 잔고를 알 수 없게 된다. 그리고 (보유자의) 카운터 서명에 주어진 유효 기간으로 인해, 몇 분이 지나면 토큰에 대한 접근 권한을 얻지 못하게 된다.

클레임 발급 빈도

섹션 에 자세히 설명한 것처럼, 사용 패턴은 특정 형태의 행위와 연관될 수 있다. 이러한 연관성은 보유자가 발급자에 대한 지식 없이 검증가능한 크리덴셜을 사용함으로써 일부 완화된다. 그러나 발급자는 그들이 발급하는 검증가능한 크리덴셜을 단기적이고 자동갱신 되도록 만듬으로써 이러한 보호를 의미없게 만들 수 있다.

예를 들어, ageOver 검증가능 크리덴셜은 술집 출입 가능 여부를 판단하는데 유용하다. 만약 발급자가 그러한 검증가능 크리덴셜을 아주 짧은 만료 시기와 자동 갱신 메커니즘으로 발급한다면, 발급자는 보유자의 행위를 보유자에게 부정적인 영향을 미치는 방식으로 연관시킬 수 있다.

보유자에게 소프트웨어를 제공하는 조직들은 보유자가 짧은 수명을 가진 크리덴셜을 반복적으로 사용하는 경우에 보유자에게 행위 연관성이 발생할 수 있음을 경고해야 한다. 발급자는 사용 패턴을 연관시키는 방식의 크리덴셜 발급을 피해야한다.

일회용 크리덴셜 선호

이상적인 사생활 존중 시스템은 검증자와 상호작용하기 위해 필요한 정보만을 보유자가 공개하도록 요구한다. 검증자는 공개 요구사항을 만족하는 정보만을 기록하고, 공개된 정보 중 나머지 민감한 정보는 저장하지 않는다. 많은 경우에 규제적인 부담과 같은 우선순위의 경쟁으로 인해 이런 이상적인 시스템을 채택하는 것이 쉽지 않다. 다른 경우는, 수명이 긴 식별자가 일회성을 저해한다. 그러나 모든 검증가능한 크리덴셜 생태계의 설계는 가능할 때마다 일회용 검증가능한 크리덴셜을 선호함으로써 사생활을 존중하기 위해 노력해야 한다.

일회용 검증가능한 크리덴셜을 사용하는 것은 여러가지 이점이 있다. 첫번째 이점은 검증자 입장에서 검증가능한 크리덴셜에 있는 데이터가 최신이라는 것을 확신할 수 있다는 점이다. 두번째 이점은 보유자 입장에서 만약 수명이 긴 식별자가 검증가능한 크리덴셜에 존재하지 않는다면 검증가능한 크리덴셜 자체는 온라인 상에서 자신을 추적하거나 연관시킬 수 없다는 점을 알게된다는 점이다. 마지막으로 공격자가 훔칠만한 것이 존재하지 않기 때문에 운영되는 전체 생태계가 더 안전해진다는 것이다.

시크릿 브라우징 모드

이상적인 시크릿 브라우징 모드 시나리오에서는, 어떤 개인 개인식별정보(PII, Personally Identifiable Information)도 노출되지 않을 것이다. 많은 크리덴셜들이 개인식별정보를 포함하고 있기 때문에, 소프트웨어를 제공하는 조직들은 시크릿 브라우징 모드에서 크리덴셜과 프레젠테이션을 사용하면 개인식별정보가 노출될 수 있음을 보유자에게 경고해야 한다. 각 브라우저 공급자들마다 시크릿 모드를 처리하는 방식이 다르고, 어떤 브라우저는 이러한 경고 기능을 제공하지 않을 수도 있기 때문에, 구현자들이 이러한 차이점을 인지하고 그에 맞게 솔루션을 구현하는 것이 중요하다.

암호화 스위트와 라이브러리

이 명세서에서 설명한 데이터 모델의 일부 측면은 암호학을 이용하여 보호할 수 있다. 구현자가 크리덴셜과 프레젠테이션을 생성하고 처리함에 있어서 사용되는 암호화 스위트와 라이브러리를 이해하는 것은 중요하다. 암호화 시스템을 구축하고 감사하는 것은 일반적으로 상당한 경험을 필요로 한다. 효과적인 레드팀 구성을 통해 보안성 리뷰에서 나타날 수 있는 편향을 방지할 수 있다.

암호화 스위트와 라이브러리는 일종의 유통기한이 있어서 결국 새로운 공격과 기술 발달에 노출된다. 제품 품질 관리 시스템은 이러한 특성을 고려하여 만료되거나 깨진 암호화 수트와 라이브러리를 간단히 선제적으로 업그레이드가 가능하도록 구성하고, 이미 발급된 크리덴셜을 무효화하고 교체할 수 있는 메커니즘을 보장해야 한다. 주기적인 모니터링은 크리덴셜을 처리하는 시스템의 장기 생존을 보장하는데 중요하다.

내용 무결성 보호

검증가능한 크리덴셜에는 외부에서 자신을 검증하기 위한 검증가능한 크리덴셜을 가르키는 URL들이 종종 포함되어 있다. 외부에 존재하는 이미지, JSON-LD 컨택스트 및 기계판독가능데이터들과 같은 링크된 컨텐츠는 검증가능한 크리덴셜의 증명을 통한 보호에서 벗어나 있기 때문에, 변조로 부터 종종 보호되지 않는다. 예를 들어 다음과 같이 강조표시된 링크들은 컨탠츠 무결성이 보호되지 않지만, 아마도 다음과 같을 것이다.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "https://example.edu/images/58473",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": { ... }
}
      

이 규격에서 내용 무결성 보호를 위해 특정한 방법을 권장하지 않지만, 링크된 내용의 무결성 보호를 원하는 작성자는 내용의 무결성을 강화하는 URL체계를 사용할 것을 권장한다. 이러한 2가치 체계는 [[HASHLINK]]규격과 [[IPFS]]이다. 다음의 예제는 이전의 예를 변형해서 [[HASHLINK]]규격을 이용해 JSON-LD 컨텍스트에 내용 무결성 보호를 추가하고, [[IPFS]] 링크를 사용하여 이미지에 내용 무결성 보호를 추가하였다.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1?hl=z3aq31uzgnZBuWNzUB",
    "https://www.w3.org/2018/credentials/examples/v1?hl=z8guWNzUBnZBu3aq31"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": { ... }
}
      

프로덕션 구현에는 중요한 JSON-LD 컨텍스트의 정적 사본이 제공 될 것으로 예상되므로, 위의 JSON-LD 컨텍스트에 보호가 필요한지 여부는 논란의 여지가 있다.

위의 예는 내용 무결성 보호를 달성하는 한 가지 방법이지만 특정 애플리케이션들에 더 적합한 다른 솔루션들이 있다. 구현자들은 내용 무결성으로 보호되지 않는 외부의 기계판독가능한 내용들에 대한 링크가 어떻게 그들의 어플리케이션에 대한 성공적인 공격을 만들어 낼 수 있는지 이해해야 한다.

서명되지않은 클레임

이 규격은 어떠한 서명이나 증명도 포함하지 않은 크리덴셜을 만들 수 있도록 한다. 이러한 유형의 크리덴셜은 웹 페이지에서 양식을 작성하는 것과 유사한 자가증명, 중간 저장소에 종종 유용하다. 구현자는 이러한 종류의 크리덴셜들은 작성자가 알려지 있지 않거나, 신뢰할 수 없기 떄문에 검증할 수 없다는걸 알아야 한다.

토큰 바인딩

검증자는 이것이 중간자 공격의 목표가 아닌 검증가능한 프레젠테이션의 수신자인지 확인해야 할 수도 있다. 요청에 의해서 검증가능한 프레젠테이션 응답을 묶은 토큰 바인딩 [[RFC8471]]과 같은 접근 방법으로 프로토콜을 보호할 수 있다. 보안되지 않은 모든 프로토콜은 중간자 공격에 취약하다.

의존하는 클레임들 번들링

발급자가 크리덴셜의 정보를 원자화하거나, 선택적 공개를 허용하는 서명체계를 이용하는 것이 가장 좋다. 원자화의 경우에, 만약 발급자에 의해 안전하게 완료되지 않았다면, 발급자가 의도하지 않은 방식으로 보유자의 다른 크리덴셜과 묶일 수 있다.

예를 들어, 대학은 한사람에게 2종류의 검증가능한 크리덴셜을 발급할 수 있는데, 각 자격증에는 "컴퓨터 부서"의 "담당자" 또는 "경제학과"의 "대학원생"과 같이 주어진 "부서"와 "역할"의 2가지 속성이 각각 포함되어 있다. 만약 이러한 속성들 중 단지 하나만이 크리덴셜에 포함되어 원자화된다면, 대학은 한사람에게 4개의 크리덴셜을 발급해야 한다. 각각의 크리덴셜들은 "직원", "대학원생", "컴퓨터 부서", "경제학과"가 될 것이다. 보유자는 검증자에게 "직원"과 "경제학과"의 검증가능한 크리덴셜을 전송할 수 있으며, 이는 잘못된 클레임이 된다.

매우 동적인 정보

매우 동적인 정보에 대한 검증가능한 크리덴셜을 발급하는 경우, 구현자는 만료기간을 적절하게 설정해야한다. 검증가능한 크리덴셜의 유효기간보다 만료기간이 더 길다면 악용가능한 보안취약성이 발생할 수 있다. 검증가능한 크리덴셜을 통해 표현되는 정보의 만료기간이 유효기간보다 짧으면 보유자와 검증자에게 부담을 준다. 따라서 사용사례와 검증가능한 크리덴셜에 포함된 정보의 예상 수명에 유효기간의 적절한 설정은 중요하다.

장치 분실 및 도용

검증가능한 크리덴셜이 저장된 장치가 분실되거나 도난당했을 때, 공갹자가 피해자의 검증가능한 크리덴셜을 사용하여 시스템에 접속할 수 있다. 이러한 유형의 공격을 완화하는 방법으로는:

• 장치에서 암호, 핀, 패턴 또는 생체인식 화면잠금 보호 활성화.
• 크리덴셜 저장소에 암호, 생체 인식 또는 다중 인증 활성화.
• 암호 키에 액세스할 때 암호, 생체인식 또는 다중 인증 활성화.
• 별도의 하드웨어 기반 서명 장치 사용.
• 상기의 전부 또는 임의의 조합.

데이터 우선 접근

정부에서 발행한 신분증과 같이 오늘날 사용하고 있는 많은 물리적인 인증서들은 인쇄가 너무 작거나, 작지만 고해상도의 이미지에 의존하거나, 시각적 장애를 가진 사람들에게 제공할 수 없는 등의 제약이 포함되어 있는 특징들에 의해 접근성이 매우 열악하다.

데이터모델을 이용해 검증가능한 크리덴셜을 만들때, 데이터 모델 디자이너는 데이터 우선 접근 방식을 사용하는 것이 좋다. 예를 들어, 크리덴셜을 묘사하기 위해 데이터 또는 그래픽 이미지를 사용하기로 선택한 경우, 디자이너는 기관의 이름 또는 전문 자격과 같은 이미지의 모든 요소를 시청자의 해석에 의존하지 말고 기계판독이 가능한 방식으로 표현해야한다. 데이터 우선 접근 방식은 다양한 능력을 가진 사람들을 위해 서로 다른 인터페이스를 구축을 위한 기본 요소를 제공하기 때문에 선호된다.

언어와 기본 방향

데이터 퍼블리셔는 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [[STRING-META]]의 교차 구문 표현식 섹션을 읽고 [[JSON-LD]], [[JSON]] 및 CBOR [[?RFC7049]]와 같이 여러 표현식 구문에서 언어 및 기본 방향 정보를 표현할 수 있도록 하는 것이 좋다.

일반적인 디자인 패턴은 언어 및 선택적으로 특정 기준 방향으로 태그가 지정된 텍스트 문자열을 표현할 때 다음 마크 업 템플릿을 사용하는 것이다.

"property": {
  "value": "The string value",
  "lang": "LANGUAGE"
  "dir": "DIRECTION"
}
      

위의 디자인 패턴을 사용하여 다음 예제는 텍스트 방향을 지정하지 않고 책 제목을 영어로 표현한다.

"title": {
  "value": "HTML and CSS: Designing and Creating Websites",
  "lang": "en"
}
      

다음 예는 오른쪽에서 왼쪽으로 기본 방향으로 아랍어로 표현 된 유사한 제목을 사용한다.

"title": {
  "value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "lang": "ar"
  "dir": "rtl"
}
      

많은 시스템에서 텍스트 문자열의 첫 번째 문자를 사용하여 텍스트 방향을 결정하므로 위의 텍스트는 언어와 방향을 명시적으로 표현하지 않고 왼쪽에서 오른쪽으로 잘못 표시된다.

JSON-LD를 사용하는 구현자는 국제화 된 속성을 정의하는 JSON-LD 컨텍스트를 extend하고 JSON-LD의 범위 지정된 컨텍스트 기능을 사용하여 @value, @language 및 @direction 키워드를 value, lang 및 dir로 별명 지정해야한다. 각기. 이를 수행하는 JSON-LD 컨텍스트 스니펫의 예는 다음과 같다.

"title": {
  "@context": {"value": "@value", "lang": "@language", "dir": "@direction"},
  "@id": "https://www.w3.org/2018/credentials/examples#title"
}
      

Complex Language Markup

여러 언어, 기본 방향 및 주석이 단일 자연 언어 문자열로 사용되는 경우 일반적으로 더 복잡한 메커니즘이 필요하다. HTML과 같은 마크 업 언어를 사용하여 여러 언어와 기본 방향으로 텍스트를 인코딩 할 수 있다. rdf : HTML 데이터 유형을 사용하여 이러한 값을 JSON-LD로 정확하게 인코딩 할 수도 있다.

정보를 HTML로 인코딩하는 기능에도 불구하고 구현자는 다음과 같은 이유로 이 작업을 수행하지 않는 것이 좋다.

• 일부 버전의 HTML 프로세서가 필요하므로 언어 및 기본 방향 정보 처리 부담이 증가한다.
• HTML을 맹목적으로 처리하면 데이터 생성 프로세스 중 공격자가 어느 시점에 삽입 한 script 태그가 실행될 수 있으므로 이 데이터 모델을 사용할 때 보안 공격 영역이 증가한다.

구현자가 특정 사용 사례를 해결하기 위해 HTML 또는 실행 가능한 스크립트를 포함 할 수있는 다른 마크 업 언어를 사용해야한다고 생각하는 경우, 구현자는 공격자가 어떻게 마크 업을 사용하여 마크 업 소비자에 대한 인젝션 공격을 마운트 하는지 분석 후 식별된 공격에 대한 완화를 배포 한다.