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

물리적 세계에서 크리덴셜은 다음으로 구성될 수 있다:

• 크리덴셜의 주체를 식별하는 것과 관련된 정보 (예: 사진, 이름 또는 식별 번호)
• 발급 기관과 관련된 정보 (예: 시 정부, 국가 기관 또는 인증 기관)
• 이것이 어떤 유형의 크리덴셜인지에 대한 정보 (예: 네덜란드 여권, 미국 운전면허증 또는 건강보험증)
• 발급 기관이 주체에 대해 주장하는 특정 속성이나 속성에 관련된 정보 (예: 국적, 운전 가능한 차량 등급 또는 생년월일)
• 크리덴셜이 어떻게 파생되었는지에 대한 증거
• 크리덴셜에 대한 제약 조건에 관련된 정보 (예: 만료 날짜 또는 사용 약관).

검증가능한 크리덴셜은 물리적 크리덴셜이 나타내는 모든 정보를 표현할 수 있다. 디지털 서명과 같은 기술의 추가로 인해 검증가능한 크리덴셜은 물리적인 크리덴셜보다 변조가 더 어렵고 신뢰할 수 있게 된다.

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

검증가능한 크리덴셜과 검증가능한 프레젠테이션 모두 빠르게 전송될 수 있어, 원격으로 신뢰를 구축하려고 할 때 물리적인 크리덴셜보다 더 편리하다.

이 규격은 디지털 크리덴셜을 쉽게 표현할 수 있도록 하는 동시에, 이 목표를 다수의 프라이버시 보호 목표와 균형을 맞추려고 시도한다. 디지털 정보의 지속성과 이질적인 디지털 데이터 출처를 쉽게 수집하고 연관시킬 수 있다는 점은 검증 가능하고 쉽게 기계 판독이 가능한 크리덴셜의 사용으로 인해 악화될 수 있는 프라이버시 문제이다. 이 문서는 섹션에서 이러한 문제들을 설명하고 해결하려고 시도한다. 영지식 증명과 같은 프라이버시 강화 기술을 사용하여 이 데이터 모델을 사용하는 방법의 예시도 이 문서 전반에 걸쳐 제공된다.

생태계 개요

이 섹션에서는 검증가능한 크리덴셜이 유용할 것으로 예상되는 생태계에서 핵심 참여자의 역할과 그들 간의 관계에 대해 설명한다. 역할은 다양한 방식으로 구현될 수 있는 추상적인 개념이다. 역할의 분리는 표준화를 위한 인터페이스와 프로토콜을 제안한다. 이 규격에서는 다음과 같은 역할을 소개한다:

보유자

하나 이상의 검증가능한 크리덴셜을 소유하고 이로부터 검증가능한 프레젠테이션을 생성함으로써 엔티티가 수행할 수 있는 역할. 보유자의 예로는 학생, 직원 및 고객이 있다.

발급자

하나 이상의 주체에 대한 클레임을 주장하고, 이러한 클레임으로부터 검증가능한 크리덴셜을 만들고, 검증가능한 크리덴셜을 보유자에게 전송함으로써 엔티티가 수행하는 역할. 발급자의 예로는 기업, 비영리 단체, 무역 협회, 정부 및 개인이 있다.

주체

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

검증자

처리를 위해 하나 이상의 검증가능한 크리덴셜을 선택적으로 검증가능한 프레젠테이션 내에서 수신함으로써 엔티티가 수행하는 역할. 검증자의 예로는 고용주, 보안 담당자 및 웹사이트 등이 있다.

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

검증가능한 크리덴셜 사용에 필요할 수 있는 식별자, 키 및 기타 관련 데이터(예: 검증가능한 크리덴셜 스키마, 폐기 레지스트리, 발급자 공개 키 등)의 생성 및 검증을 중재함으로써 시스템이 수행할 수 있는 역할. 일부 구성에서는 주체에 대한 상관관계가 있는 식별자가 필요할 수 있다. 검증가능한 데이터 레지스트리의 예로는 신뢰할 수 있는 데이터베이스, 탈중앙화된 데이터베이스, 정부 ID 데이터베이스 및 분산 원장 등이 있다. 종종 생태계에서는 두 가지 이상의 유형의 검증가능한 데이터 레지스트리가 활용된다.

above provides an example ecosystem in which to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where verifiable credentials also provide benefit.

사용 사례 및 요구사항

검증가능한 크리덴셜 사용 사례 문서 [[VC-USE-CASES]]는 독자에게 유용할 수 있는 여러 가지 주요 주제를 간략히 설명하고 있다:

• 위에서 소개한 역할에 대한 보다 철저한 설명
• 교육, 금융, 의료, 소매, 전문 면허 및 정부와 같은 수직 시장에서 식별된 요구사항
• 생태계의 역할이 수행하는 공통 작업 및 관련 요구 사항
• 작업 그룹에서 식별한 공통 시퀀스 및 흐름

사용 사례 문서의 문서화 및 분석 결과, 이 규격에 대해 다음과 같은 바람직한 생태계 특성이 식별되었다:

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

클레임

클레임은 주체에 대한 진술이다. 주체는 클레임이 만들어질 수 있는 대상이다. 클레임은 주체-속성-값 관계를 사용하여 표현된다.

위의 에 설명된 클레임의 데이터 모델은 강력하며 다양한 진술을 표현하는 데 사용될 수 있다. 예를 들어, 누군가가 특정 대학을 졸업했는지 여부는 아래 와 같이 표현될 수 있다.

개별 클레임은 주체에 대한 정보의 그래프를 표현하기 위해 결합될 수 있다. 아래 에 표시된 예는 Pat이 Sam을 알고 있으며 Sam이 교수로 고용되어 있다는 클레임을 추가하여 이전 클레임을 확장한 것이다.

이 시점에서 클레임과 정보의 그래프 개념이 소개되었다. 클레임을 신뢰할 수 있으려면 그래프에 더 많은 정보가 추가될 것으로 예상된다.

크리덴셜

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

검증가능한 크리덴셜의 예로는 디지털 직원 신분증, 디지털 출생증명서, 디지털 교육 증명서 등이 있다.

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

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

결혼 증명서와 같이 서로 관련이 없어도 되는 다른 주체에 대한 여러 클레임을 포함하는 크리덴셜을 가질 수 있다.

크리덴셜이 발급된 엔티티에 대한 클레임을 전혀 포함하지 않는 크리덴셜을 가질 수 있다. 예를 들어, 특정 개에 대한 클레임만 포함하지만 개의 주인에게 발급되는 크리덴셜이 있다.

프레젠테이션

프라이버시 향상은 이 규격의 핵심 설계 기능이다. 따라서 이 기술을 사용하는 엔티티가 특정 상황에 적합한 페르소나의 일부분만 표현할 수 있는 것이 중요하다. 페르소나의 일부를 표현하는 것을 검증가능한 프레젠테이션이라고 한다. 서로 다른 페르소나의 예로는 한 사람의 직업상 페르소나, 온라인 게임 페르소나, 가족 페르소나 또는 익명 페르소나 등이 있다.

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

프레젠테이션의 데이터는 종종 동일한 주체에 관한 것이지만, 여러 발급자에 의해 발급되었을 수 있다. 이 정보의 집합은 일반적으로 사람, 조직 또는 엔티티의 한 측면을 표현한다.

위의 는 검증가능한 프레젠테이션의 구성 요소를 보여주지만, 검증가능한 크리덴셜이 정보 그래프로 구성되고 이러한 정보 그래프가 검증가능한 프레젠테이션으로 구성되는 방법에 대한 세부 사항은 추상화한다.

아래 는 일반적으로 적어도 네 개의 정보 그래프로 구성되는 검증가능한 프레젠테이션의 보다 완전한 묘사를 보여준다. 첫 번째 정보 그래프인 프레젠테이션 그래프는 프레젠테이션 메타데이터를 포함하는 검증가능한 프레젠테이션 자체를 표현한다. 프레젠테이션 그래프의 verifiableCredential 속성은 하나 이상의 검증가능한 크리덴셜을 참조하며, 각각은 두 번째 정보 그래프, 즉 크리덴셜 메타데이터와 클레임을 포함하는 자체 포함된 크리덴셜 그래프이다. 세 번째 정보 그래프인 크리덴셜 증명 그래프는 일반적으로 디지털 서명인 크리덴셜 그래프 증명을 표현한다. 네 번째 정보 그래프인 프레젠테이션 증명 그래프는 일반적으로 디지털 서명인 프레젠테이션 그래프 증명을 표현한다.

비즈니스 페르소나와 같이 종종 관련이 있지만 반드시 그럴 필요는 없는 여러 주체에 대한 여러 크리덴셜을 사용하는 프레젠테이션을 가질 수 있다.

구체적인 라이프사이클 예시

이전 섹션에서는 그래픽 묘사를 사용하여 클레임, 검증가능한 크리덴셜, 검증가능한 프레젠테이션의 개념을 소개했다. 이 섹션에서는 이 규격에서 지원하는 구체적인 구문 중 하나로 표현된 데이터 모델의 간단하지만 완전한 라이프사이클 예시를 제공한다. 검증가능한 크리덴셜 생태계에서 크리덴셜과 프레젠테이션의 라이프사이클은 일반적으로 다음과 같은 공통 경로를 거친다:

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

이 라이프사이클을 설명하기 위해, 대학에서 동문 할인을 받는 예시를 사용할 것이다. 아래 예시에서 Pat은 대학에서 동문 검증가능한 크리덴셜을 받고, 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:23: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/565049/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:23: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/565049/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 메커니즘에 대해 더 이해하고 싶은 구현자는 섹션과 다음 규격을 읽어보면 더 많은 것을 배울 수 있다: Linked Data Proofs \[\[?LD-PROOFS\]\], Linked Data Cryptographic Suites Registry\[\[?LDP-REGISTRY\]\], JSON Web Signature (JWS) Unencoded Payload Option \[\[RFC7797\]\]. 증명 메커니즘 목록은 검증가능한 크리덴셜 확장 레지스트리 \[\[VC-EXTENSION-REGISTRY\]\]에서 확인할 수 있다.

프라이버시 스펙트럼

가명에서 강력하게 식별된 상태에 이르기까지 프라이버시 스펙트럼이 있다는 점을 인식하는 것이 중요하다. 사용 사례에 따라, 사람들은 자신이 기꺼이 제공하고자 하는 정보와 제공된 정보에서 파생될 수 있는 정보에 대해 서로 다른 편안함을 느낀다.

예를 들어, 대부분의 사람들은 알코올을 구매할 때 익명으로 남기를 원할 것이다. 왜냐하면 요구되는 규제 검사는 오로지 특정 연령 이상인지 여부에 기반하기 때문이다. 반대로, 의사가 환자에게 쓴 의료 처방전의 경우, 처방전을 이행하는 약국은 의료 전문가와 환자를 보다 강력하게 식별해야 한다. 따라서 모든 사용 사례에 적용되는 프라이버시에 대한 단일 접근 방식은 없다. 프라이버시 솔루션은 사용 사례에 따라 다르다.

알코올 구매 시 익명으로 남고 싶어하는 사람들의 경우에도, 상인에게 적절한 보증을 제공하기 위해 사진이 부착된 신분증이 여전히 필요할 수 있다. 상인은 (특정 연령 이상이라는 것 외에) 이름이나 기타 세부 정보를 알 필요가 없을 수 있지만, 많은 경우 단순한 연령 증명만으로는 규정을 충족하기에 여전히 불충분할 수 있다.

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

개인 식별 정보

credential.credentialSubject 필드에 저장된 검증가능한 크리덴셜과 관련된 데이터는 검증자와 공유될 때 프라이버시 침해에 취약하다. 정부 발행 식별자, 배송 주소, 성명과 같은 개인 식별 데이터는 엔티티를 쉽게 식별, 추적 및 연관시키는 데 사용될 수 있다. 생년월일과 우편번호의 조합과 같이 개인 식별이 불가능해 보이는 정보조차도 매우 강력한 상관관계와 익명성 제거 능력을 가지고 있다.

구현자는 이러한 특성을 가진 데이터를 공유할 때 보유자에게 경고하는 것이 강력히 권고된다. 발급자는 가능한 경우 프라이버시를 보호하는 검증가능한 크리덴셜을 제공하는 것이 강력히 권고된다. 예를 들어, 검증자가 엔티티의 나이가 18세 이상인지 여부를 확인하고자 할 때 생년월일 검증가능한 크리덴셜 대신 ageOver 검증가능한 크리덴셜을 발급하는 것이다.

검증가능한 크리덴셜에는 종종 개인 식별 정보(PII)가 포함되어 있으므로, 구현자는 검증가능한 크리덴셜을 저장하고 전송하는 동안 액세스해서는 안 되는 사람들로부터 데이터를 보호하는 메커니즘을 사용하는 것이 강력히 권고된다. 고려될 수 있는 메커니즘에는 전송 계층 보안(TLS) 또는 전송 중 데이터를 암호화하는 다른 수단, 그리고 검증가능한 크리덴셜의 데이터를 보호하기 위한 암호화 또는 데이터 액세스 제어 메커니즘 등이 있다.

식별자 기반 연관

검증가능한 크리덴셜의 주체는 credential.credentialSubject.id 필드를 사용하여 식별된다. 주체를 식별하는 데 사용되는 식별자는 식별자가 장기간 사용되거나 둘 이상의 웹 도메인에서 사용될 때 더 큰 연관 위험을 초래한다.

마찬가지로, 크리덴셜 식별자(credential.id)를 공개하면 여러 검증자 또는 발급자와 검증자가 공모하여 보유자를 연관시킬 수 있는 상황으로 이어진다. 보유자가 연관성을 줄이고 싶다면, 검증가능한 프레젠테이션 중에 식별자를 숨길 수 있는 검증가능한 크리덴셜 체계를 사용해야 한다. 이러한 체계는 보유자가 식별자를 생성하고 심지어 식별자를 검증가능한 크리덴셜에 포함되고 서명된 상태로 유지하면서도 발급자로부터 식별자를 숨길 수 있도록 한다.

검증가능한 크리덴셜 시스템에서 강력한 반연관 속성이 요구사항인 경우, 식별자가 다음 중 하나여야 한다:

• 단일 출처에 바인딩됨
• 일회용
• 전혀 사용되지 않고 대신 단기적이고 일회용인 bearer 토큰으로 대체됨.

서명 기반 연관

검증가능한 크리덴셜의 내용은 credential.proof 필드를 사용하여 보호된다. 이 필드의 속성은 동일한 값이 둘 이상의 세션 또는 도메인에서 사용되고 값이 변경되지 않을 때 더 큰 연관 위험을 초래한다. 예로는 verificationMethod, created, proofPurpose, jws 필드가 있다.

강력한 반연관 속성이 요구되는 경우, 서명 값과 메타데이터를 제3자 쌍별 서명, 영지식 증명 또는 그룹 서명과 같은 기술을 사용하여 매번 재생성하는 것이 좋다.

반연관 서명을 사용하더라도 사용된 암호화의 반연관 속성을 무력화하는 정보가 여전히 검증가능한 크리덴셜에 포함될 수 있다.

장기 식별자 기반 연관

검증가능한 크리덴셜에는 개인을 연관시키는 데 사용될 수 있는 장기 식별자가 포함될 수 있다. 이러한 유형의 식별자에는 주체 식별자, 이메일 주소, 정부 발행 식별자, 조직 발행 식별자, 주소, 의료 필수 정보, 검증가능한 크리덴셜 전용 JSON-LD 컨텍스트 및 기타 많은 종류의 장기 식별자가 포함된다.

보유자에게 소프트웨어를 제공하는 조직은 개인을 연관시키는 데 사용될 수 있는 정보가 포함된 검증가능한 크리덴셜의 필드를 식별하고, 이 정보가 공유될 때 보유자에게 경고하기 위해 노력해야 한다.

기기 핑거프린팅

인터넷과 웹에서 개인을 추적하고 연관시키는 데 사용되는 검증가능한 크리덴셜 외부의 메커니즘이 있다. 이러한 메커니즘에는 인터넷 프로토콜(IP) 주소 추적, 웹 브라우저 핑거프린팅, 에버쿠키, 광고 네트워크 추적기, 모바일 네트워크 위치 정보, 애플리케이션 내 GPS(Global Positioning System) API 등이 있다. 검증가능한 크리덴셜을 사용한다고 해서 이러한 다른 추적 기술의 사용을 막을 수는 없다. 또한 이러한 기술이 검증가능한 크리덴셜과 함께 사용될 때 새로운 연관 가능한 정보가 발견될 수 있다. 예를 들어, 생일과 GPS 위치를 결합하면 여러 웹사이트에서 개인을 강력하게 연관시키는 데 사용될 수 있다.

프라이버시를 존중하는 시스템은 검증가능한 크리덴셜이 사용될 때 이러한 다른 추적 기술의 사용을 방지하는 것이 좋다. 경우에 따라 보유자를 대신하여 검증가능한 크리덴셜을 전송하는 장치에서 추적 기술을 비활성화해야 할 수도 있다.

추상적인 클레임 선호

검증가능한 크리덴셜의 수신자가 거래에 필요한 것보다 더 많은 PII를 공개하지 않고 다양한 상황에서 사용할 수 있도록 하기 위해, 발급자는 크리덴셜에 게시된 정보를 예상되는 목적에 필요한 최소한의 집합으로 제한하는 것을 고려해야 한다. 크리덴셜에 PII를 넣지 않는 한 가지 방법은 주체에 대한 구체적인 정보를 제공하지 않고 검증자의 요구사항을 충족하는 추상적인 속성을 사용하는 것이다.

예를 들어, 이 문서는 훨씬 더 강력한 PII인 특정 생년월일 대신 ageOver 속성을 사용한다. 특정 시장의 소매업체가 일반적으로 구매자의 연령이 특정 연령 이상일 것을 요구하는 경우, 해당 시장에서 신뢰받는 발급자는 특정 생년월일에 대한 클레임이 포함된 검증가능한 크리덴셜을 제공하는 대신 주체가 해당 요구사항을 충족했다고 주장하는 검증가능한 크리덴셜을 제공하는 것을 선택할 수 있다. 이를 통해 개별 고객은 특정 PII를 공개하지 않고 구매할 수 있다.

데이터 최소화 원칙

한 맥락에서 공개된 정보가 다른 맥락으로 유출될 때 프라이버시 침해가 발생한다. 이러한 위반을 방지하기 위한 인정된 모범 사례는 요청하고 수신하는 정보를 절대적으로 필요한 최소한으로 제한하는 것이다. 이 데이터 최소화 접근 방식은 미국의 건강 보험 이동성 및 책임법(HIPAA)과 유럽 연합의 일반 데이터 보호 규정(GDPR)을 포함한 여러 관할 구역의 규정에서 요구된다.

검증가능한 크리덴셜에서 발급자에 대한 데이터 최소화는 검증가능한 크리덴셜의 내용을 예상되는 사용을 위해 잠재적 검증자에게 필요한 최소한으로 제한하는 것을 의미한다. 검증자의 경우 데이터 최소화는 서비스 액세스에 요청되거나 필요한 정보의 범위를 제한하는 것을 의미한다.

예를 들어, 운전자 ID 번호, 키, 체중, 생일, 집 주소를 포함하는 운전면허증은 해당 사람이 특정 연령 이상임을 확인하는 데 필요한 것보다 더 많은 정보를 포함하는 크리덴셜이다.

발급자가 정보를 원자화하거나 선택적 공개를 허용하는 서명 체계를 사용하는 것이 모범 사례로 간주된다. 예를 들어, 운전면허증의 발급자는 운전면허증에 나타나는 모든 속성을 포함하는 검증가능한 크리덴셜과 함께 각 검증가능한 크리덴셜이 생일과 같은 단일 속성만 포함하는 검증가능한 크리덴셜 집합을 발급할 수 있다. 또한 ageOver 속성만 포함하는 검증가능한 크리덴셜과 같이 보다 추상적인 검증가능한 크리덴셜을 발급할 수도 있다. 한 가지 가능한 적응 방식은 발급자가 검증가능한 크리덴셜의 가명 사용을 촉진하는 일회용 bearer 크리덴셜을 검색하기 위한 보안 HTTP 엔드포인트를 제공하는 것이다. 이를 비실용적이거나 안전하지 않다고 생각하는 구현자는 증명 시점에서 발급자에 대한 의존성을 제거하고 발급자로부터의 시간적 상관관계 위험을 줄이는 선택적 공개 체계를 사용하는 것을 고려해야 한다.

검증자는 특정 트랜잭션 발생에 절대적으로 필요한 정보만 요청하는 것이 좋다. 이것은 최소한 두 가지 이유로 중요하다:

• 검증자가 다룰 필요가 없는 매우 민감한 정보를 처리해야 하는 책임을 줄인다.
• 특정 트랜잭션에 필요한 정보만 요청함으로써 개인의 프라이버시를 강화한다.

최소 공개 원칙을 실천하는 것이 가능하지만, 단일 세션 또는 여러 세션에 걸쳐 특정 사용 사례에 대해 개인을 강력하게 식별하는 것을 피하는 것은 불가능할 수 있다. 이 문서의 저자들은 실제 시나리오에서 이 원칙을 충족하는 것이 얼마나 어려운지 강조할 수 없다.

Bearer 크리덴셜

bearer 크리덴셜은 콘서트 티켓과 같이 bearer 크리덴셜의 보유자에게 보유자에 대한 민감한 정보를 공개하지 않고 특정 리소스에 대한 자격을 부여하는 프라이버시 강화 정보이다. bearer 크리덴셜은 종종 bearer 크리덴셜의 공유가 우려되지 않거나 큰 경제적 또는 명성 손실로 이어지지 않는 저위험 사용 사례에 사용된다.

bearer 크리덴셜인 검증가능한 크리덴셜은 credentialSubject 속성에 중첩된 id 속성을 사용하여 표현되는 주체 식별자를 지정하지 않음으로써 가능해진다. 예를 들어, 다음 검증가능한 크리덴셜은 bearer 크리덴셜이다:

{
  "@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": {
    // note that the 'id' property is not specified for bearer credentials
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": { ... }
}
      

bearer 크리덴셜은 프라이버시를 강화할 수 있지만, bearer 크리덴셜의 보유자가 예상하는 것보다 더 많은 정보를 실수로 누설하지 않도록 신중하게 작성되어야 한다. 예를 들어, 동일한 bearer 크리덴셜을 여러 사이트에서 반복적으로 사용하면 이러한 사이트가 잠재적으로 공모하여 보유자를 부당하게 추적하거나 연관시킬 수 있다. 마찬가지로 생년월일 및 우편번호와 같은 정보는 식별되지 않는 것처럼 보일 수 있지만, 동일한 bearer 크리덴셜 또는 세션에서 함께 사용될 때 통계적으로 개인을 식별하는 데 사용될 수 있다.

bearer 크리덴셜의 발급자는 bearer 크리덴셜이 다음과 같은 프라이버시 강화 이점을 제공하도록 해야 한다:

• 가능한 경우 일회용이다.
• 개인 식별 정보를 포함하지 않는다.
• 부당하게 연관될 수 없다.

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

검증자는 보유자를 부당하게 연관시키는 데 사용될 수 있는 bearer 크리덴셜을 요청해서는 안 된다.

유효성 검사

검증가능한 크리덴셜을 처리할 때 검증자는 부록 에 나열된 많은 검사와 다양한 특정 비즈니스 프로세스 검사를 수행할 것으로 예상된다. 유효성 검사에는 다음 사항을 확인하는 것이 포함될 수 있다:

• 보유자의 전문 면허 상태.
• 면허 갱신 또는 취소 날짜.
• 개인의 세부 자격.
• 보유자와 보유자가 상호 작용하려는 엔티티 사이에 관계가 존재하는지 여부.
• 보유자와 연결된 지리적 위치 정보.

이러한 검사를 수행하는 과정에서 보유자의 프라이버시 침해로 이어지는 정보 유출이 발생할 수 있다. 예를 들어, 폐기 목록을 확인하는 것과 같은 간단한 작업으로 인해 특정 비즈니스가 보유자와 상호 작용할 가능성이 있음을 발급자에게 알릴 수 있다. 이를 통해 발급자가 공모하여 개인의 알지 못한 채로 연관시킬 수 있다.

발급자는 검증 프로세스 동안 프라이버시 위반으로 이어질 수 있는 크리덴셜당 고유한 크리덴셜 폐기 목록과 같은 메커니즘을 사용하지 않도록 해야 한다. 보유자에게 소프트웨어를 제공하는 조직은 검증 프로세스 중에 프라이버시 침해로 이어질 수 있는 정보가 크리덴셜에 포함된 경우 경고해야 한다. 검증자는 프라이버시 침해를 유발하거나 잘못된 프라이버시 관행을 가능하게 하는 크리덴셜을 거부하는 것을 고려해야 한다.

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

보유자가 발급자로부터 검증가능한 크리덴셜을 받으면 검증가능한 크리덴셜은 어딘가에 저장되어야 한다(예: 크리덴셜 리포지토리). 보유자는 검증가능한 크리덴셜의 정보가 본질적으로 민감하고 매우 개별화되어 데이터 마이닝의 높은 가치 목표가 된다는 점에 주의해야 한다. 검증가능한 크리덴셜의 무료 저장소를 광고하는 서비스는 실제로 개인 데이터를 마이닝하고 개인 및 조직에 대한 개별 프로파일을 구축하려는 조직에 판매할 수 있다.

보유자는 크리덴셜 리포지토리의 서비스 약관, 특히 검증가능한 크리덴셜을 서비스 제공자와 함께 저장하는 사람들을 위해 마련된 상관관계 및 데이터 마이닝 보호를 인식해야 한다.

데이터 마이닝 및 프로파일링에 대한 몇 가지 효과적인 완화 방법은 다음을 사용하는 것이다:

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

크리덴셜 집계

동일한 주체에 대한 두 가지 정보를 보유하는 것은 정보가 서로 다른 채널을 통해 전달되더라도 거의 항상 단순히 두 가지 정보의 합보다 주체에 대해 더 많은 것을 드러낸다. 검증가능한 크리덴셜의 집계는 프라이버시 위험이며 생태계의 모든 참여자는 데이터 집계의 위험을 인식해야 한다.

예를 들어, 한 세션에서 이메일 주소에 대한 bearer 크리덴셜을, 그 다음 세션에서 보유자가 21세 이상이라는 bearer 크리덴셜을 제공하는 경우, 정보의 검증자는 이제 해당 개인에 대한 고유 식별자와 연령 관련 정보를 모두 가지게 된다. 이제 시간이 지남에 따라 더 많은 정보가 유출되도록 보유자에 대한 프로파일을 쉽게 만들고 구축할 수 있다. 크리덴셜의 집계는 서로 공모하는 여러 사이트에서 수행될 수도 있으며, 이는 프라이버시 침해로 이어진다.

기술적 관점에서 정보의 집계를 방지하는 것은 해결하기 매우 어려운 프라이버시 문제이다. 영지식 증명과 같은 새로운 암호화 기술이 집계 및 상관관계 문제에 대한 해결책으로 제안되고 있지만, 장기 식별자와 브라우저 추적 기술의 존재는 가장 현대적인 암호화 기술조차도 무력화시킨다.

상관관계 또는 집계의 프라이버시 영향에 대한 해결책은 기술적인 것이 아니라 정책 중심인 경향이 있다. 따라서 보유자가 자신에 대한 정보가 집계되는 것을 원하지 않는 경우, 이를 전송하는 검증가능한 프레젠테이션에 명시해야 한다.

사용 패턴

프라이버시를 보장하기 위한 최선의 노력에도 불구하고, 검증가능한 크리덴셜을 실제로 사용하면 잠재적으로 익명성 해제와 프라이버시 손실로 이어질 수 있다. 이러한 상관관계는 다음과 같은 경우에 발생할 수 있다:

• 동일한 검증가능한 크리덴셜이 동일한 검증자에게 두 번 이상 제시된다. 검증자는 보유자가 동일한 개인임을 추론할 수 있다.
• 동일한 검증가능한 크리덴셜이 서로 다른 검증자에게 제시되고, 해당 검증자가 공모하거나 제3자가 두 검증자의 트랜잭션 기록에 액세스할 수 있다. 주의 깊은 당사자는 검증가능한 크리덴셜을 제시하는 개인이 두 서비스에서 동일한 사람이라고 추론할 수 있다. 즉, 계정이 동일한 사람에 의해 제어된다.
• 크리덴셜의 주체 식별자가 여러 프레젠테이션 또는 검증자에 걸쳐 동일한 주체를 참조한다. 서로 다른 크리덴셜이 제시되더라도 주체 식별자가 동일하면 검증자(및 검증자 로그에 액세스할 수 있는 사람)는 크리덴셜의 보유자가 동일한 사람이라고 추론할 수 있다.
• 크리덴셜의 기본 정보를 사용하여 서비스 전반에서 개인을 식별할 수 있다. 이 경우 검증자는 다른 출처(직접 보유자가 제공한 정보 포함)의 정보를 사용하여 크리덴셜 내부의 정보를 기존 프로필과 상관관계를 지을 수 있다. 예를 들어, 보유자가 우편번호, 연령, 성별이 포함된 크리덴셜을 제시하는 경우 검증자는 해당 크리덴셜의 주체를 기존 프로필과 잠재적으로 연관시킬 수 있다. 자세한 내용은 [[DEMOGRAPHICS]]를 참조하라.
• 크리덴셜의 식별자를 중앙 집중식 폐기 서버에 전달한다. 중앙 집중식 서버는 상호 작용에서 크리덴셜 사용을 연관시킬 수 있다. 예를 들어, 이러한 방식으로 크리덴셜이 연령 증명에 사용되는 경우 중앙 집중식 서비스는 해당 크리덴셜이 제시된 모든 곳(모든 주류 판매점, 바, 성인용품점, 복권 구매 등)을 알 수 있다.

부분적으로 다음과 같은 방법으로 이러한 익명성 해제와 프라이버시 손실을 완화할 수 있다:

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

이러한 완화 기술이 항상 실용적이거나 심지어 필요한 사용과 호환되는 것은 아니라는 점을 이해한다. 때로는 상관관계가 요구사항이다.

예를 들어, 일부 처방약 모니터링 프로그램에서는 사용 모니터링이 요구사항이다. 집행 기관은 개인이 통제 물질에 대한 여러 처방전을 얻기 위해 시스템을 속이지 않는다는 것을 확인할 수 있어야 한다. 이러한 법적 또는 규제적 사용 상관관계 필요성은 개인 프라이버시 우려보다 우선한다.

검증가능한 크리덴셜은 또한 여러 서비스에 로그인하기 위해 공통 페르소나를 사용할 때와 같이 서비스 전반에서 개인을 의도적으로 연관시키는 데 사용될 것이다. 따라서 이러한 각 서비스의 모든 활동이 의도적으로 동일한 개인에게 연결된다. 이러한 각 서비스가 예상되는 방식으로 상관관계를 사용하는 한 이것은 프라이버시 문제가 아니다.

크리덴셜 사용의 프라이버시 위험은 크리덴셜 제시로 인해 의도하지 않거나 예상치 못한 상관관계가 발생할 때 발생한다.

잘못된 당사자와 정보 공유

보유자가 검증자와 정보를 공유하기로 선택한 경우, 검증자가 악의를 가지고 행동하고 보유자에게 해를 끼치는 데 사용될 수 있는 정보를 요청하는 경우일 수 있다. 예를 들어, 검증자는 은행 계좌 번호를 요청할 수 있으며, 이는 다른 정보와 함께 사용하여 보유자 또는 은행을 속일 수 있다.

발급자는 보유자가 실수로 크리덴셜을 잘못된 검증자에게 전송하더라도 상황이 치명적이지 않도록 가능한 한 많은 정보를 토큰화하도록 노력해야 한다.

예를 들어, 개인의 은행 잔고를 확인하기 위해 은행 계좌 번호를 포함하는 대신 검증자가 잔고가 특정 금액 이상인지 확인할 수 있는 토큰을 제공한다. 이 경우 은행은 잔고 확인 토큰이 포함된 검증가능한 크리덴셜을 보유자에게 발급할 수 있다. 그러면 보유자는 검증가능한 프레젠테이션에 검증가능한 크리덴셜을 포함하고 디지털 서명을 사용하여 토큰을 신용 조회 기관에 바인딩한다. 그러면 검증자는 검증가능한 프레젠테이션을 자신의 디지털 서명으로 래핑하고 다시 발급자에게 전달하여 계좌 잔고를 동적으로 확인할 수 있다.

이 접근 방식을 사용하면 보유자가 계좌 잔고 토큰을 잘못된 당사자와 공유하더라도 공격자는 은행 계좌 번호나 계좌의 정확한 값을 알아낼 수 없다. 그리고 역서명의 유효 기간을 감안할 때 몇 분 이상 토큰에 대한 액세스 권한을 얻지 못한다.

클레임 발급 빈도

섹션 에 자세히 설명된 대로 사용 패턴은 특정 유형의 행동과 상관관계가 있을 수 있다. 이러한 상관관계의 일부는 보유자가 발급자의 지식 없이 검증가능한 크리덴셜을 사용할 때 완화된다. 그러나 발급자는 검증가능한 크리덴셜의 수명을 짧게 하고 갱신을 자동으로 함으로써 이러한 보호를 무력화할 수 있다.

예를 들어, ageOver 검증가능한 크리덴셜은 바에 접근하는 데 유용하다. 발급자가 매우 짧은 만료 기간과 자동 갱신 메커니즘으로 이러한 검증가능한 크리덴셜을 발급하는 경우, 발급자는 보유자에게 부정적인 영향을 미치는 방식으로 보유자의 행동을 연관시킬 수 있다.

보유자에게 소프트웨어를 제공하는 조직은 행동 상관관계를 초래할 수 있는 수명이 짧은 크리덴셜을 반복적으로 사용하는 경우 경고해야 한다. 발급자는 사용 패턴을 연관시킬 수 있는 방식으로 크리덴셜을 발급하는 것을 피해야 한다.

일회용 크리덴셜 선호

이상적인 프라이버시 존중 시스템은 검증자와의 상호 작용에 필요한 정보만 보유자가 공개하도록 요구할 것이다. 그런 다음 검증자는 공개 요구사항이 충족되었음을 기록하고 공개된 민감한 정보를 잊어버릴 것이다. 많은 경우 규제 부담과 같은 경쟁 우선순위로 인해 이 이상적인 시스템이 채택되지 못하고 있다. 다른 경우에는 장기 식별자가 일회성 사용을 방해한다. 그러나 검증가능한 크리덴셜 생태계의 설계는 가능한 한 일회용 검증가능한 크리덴셜을 선호함으로써 가능한 한 프라이버시를 존중하도록 노력해야 한다.

일회용 검증가능한 크리덴셜을 사용하면 여러 가지 이점이 있다. 첫 번째 이점은 검증자가 검증가능한 크리덴셜의 데이터가 새로운 것임을 확신할 수 있다는 것이다. 두 번째 이점은 검증가능한 크리덴셜에 장기 식별자가 없는 경우 검증가능한 크리덴셜 자체를 사용하여 보유자를 온라인에서 추적하거나 연관시킬 수 없다는 것을 아는 보유자에게 있다. 마지막으로 공격자가 훔칠 것이 없어 전체 생태계를 더 안전하게 운영할 수 있다.

프라이빗 브라우징

이상적인 프라이빗 브라우징 시나리오에서는 PII가 공개되지 않는다. 많은 크리덴셜에 PII가 포함되어 있기 때문에 보유자에게 소프트웨어를 제공하는 조직은 프라이빗 브라우징 모드에서 크리덴셜과 프레젠테이션을 사용하려는 경우 이 정보가 공개될 가능성에 대해 경고해야 한다. 각 브라우저 공급업체가 프라이빗 브라우징을 다르게 처리하고 일부 브라우저에는 이 기능이 전혀 없을 수 있으므로 구현자는 이러한 차이점을 인식하고 그에 따라 솔루션을 구현하는 것이 중요하다.

암호 스위트 및 라이브러리

이 규격에 설명된 데이터 모델의 일부 측면은 암호학을 사용하여 보호할 수 있다. 구현자가 크리덴셜과 프레젠테이션을 생성하고 처리하는 데 사용되는 암호 스위트와 라이브러리를 이해하는 것이 중요하다. 일반적으로 암호 시스템을 구현하고 감사하려면 상당한 경험이 필요하다. 효과적인 레드 팀은 또한 보안 검토에서 편견을 제거하는 데 도움이 될 수 있다.

암호 스위트와 라이브러리에는 수명이 있으며 결국 새로운 공격과 기술 발전에 의해 무너진다. 프로덕션 품질 시스템은 이를 고려해야 하며, 만료되거나 손상된 암호 스위트와 라이브러리를 쉽고 선제적으로 업그레이드하고 기존 크리덴셜을 무효화하고 교체할 수 있는 메커니즘이 존재해야 한다. 정기적인 모니터링은 크리덴셜을 처리하는 시스템의 장기적인 생존력을 보장하는 데 중요하다.

콘텐츠 무결성 보호

검증가능한 크리덴셜은 종종 검증가능한 크리덴셜 자체 외부에 있는 데이터에 대한 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 체계를 사용하는 것이 좋다. 이러한 두 가지 체계로는 [[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]]과 같은 접근 방식은 프로토콜을 보호할 수 있다. 보안되지 않은 모든 프로토콜은 중간자 공격에 취약하다.

종속 클레임 번들링

발급자가 크리덴셜의 정보를 원자화하거나 선택적 공개를 허용하는 서명 체계를 사용하는 것이 모범 사례로 간주된다. 원자화의 경우 발급자에 의해 안전하게 수행되지 않으면 보유자가 발급자가 의도하지 않은 방식으로 서로 다른 크리덴셜을 함께 번들링할 수 있다.

예를 들어, 대학은 한 사람에게 각각 두 개의 속성을 포함하는 두 개의 검증가능한 크리덴셜을 발급할 수 있는데, 이는 "컴퓨팅 학과"의 "직원" 또는 "경제학과"의 "대학원생"과 같이 주어진 "학과"에서 그 사람의 "역할"을 지정하기 위해 함께 취해져야 한다. 이러한 검증가능한 크리덴셜이 이러한 속성 중 하나만 각 크리덴셜에 넣도록 원자화되면, 대학은 그 사람에게 "직원", "대학원생", "컴퓨팅 학과", "경제학과" 중 하나의 지정을 포함하는 네 개의 크리덴셜을 발급할 것이다. 그러면 보유자는 "직원"과 "경제학과"의 검증가능한 크리덴셜을 검증자에게 전송할 수 있으며, 이는 함께 거짓 클레임을 구성할 것이다.

고도로 동적인 정보

고도로 동적인 정보에 대해 검증가능한 크리덴셜이 발급되는 경우, 구현자는 만료 시간을 적절하게 설정해야 한다. 검증가능한 크리덴셜이 유효한 시간 프레임보다 더 긴 만료 기간은 악용 가능한 보안 취약점을 만들 수 있다. 검증가능한 크리덴셜로 표현된 정보가 유효한 시간 프레임보다 더 짧은 만료 기간은 보유자와 검증자에게 부담을 준다. 따라서 사용 사례와 검증가능한 크리덴셜에 포함된 정보의 예상 수명에 적합한 검증가능한 크리덴셜의 유효 기간을 설정하는 것이 중요하다.

장치 도난 및 사칭

검증가능한 크리덴셜이 장치에 저장되어 있고 해당 장치를 분실하거나 도난당한 경우, 공격자가 피해자의 검증가능한 크리덴셜을 사용하여 시스템에 액세스할 수 있다. 이러한 유형의 공격을 완화하는 방법은 다음과 같다:

• 장치에서 비밀번호, PIN, 패턴 또는 생체 인식 화면 잠금 해제 보호 사용.
• 크리덴셜 리포지토리에 대해 비밀번호, 생체 인식 또는 다중 요소 인증 사용.
• 암호화 키에 액세스할 때 비밀번호, 생체 인식 또는 다중 요소 인증 사용.
• 별도의 하드웨어 기반 서명 장치 사용.
• 위의 모든 것 또는 조합.

데이터 우선 접근법

정부 신분증과 같이 오늘날 사용되는 많은 물리적 크리덴셜은 작은 인쇄, 작고 고해상도 이미지에 대한 의존, 시각 장애인을 위한 편의 시설 부족 등을 포함한 열악한 접근성 특성을 가지고 있다.

이 데이터 모델을 활용하여 검증가능한 크리덴셜을 만들 때, 데이터 모델 설계자는 데이터 우선 접근 방식을 사용하는 것이 좋다. 예를 들어, 크리덴셜을 표현하기 위해 데이터나 그래픽 이미지를 사용하는 선택권이 주어진 경우, 설계자는 기관명이나 전문 크리덴셜과 같은 이미지의 모든 요소를 뷰어의 이미지 해석에 의존하는 대신 기계 판독 가능한 방식으로 표현해야 한다. 데이터 우선 접근 방식을 사용하는 것이 선호되는 이유는 다양한 능력을 가진 사람들을 위한 다양한 인터페이스를 구축하는 기본 요소를 제공하기 때문이다.

언어와 기본 방향

데이터 게시자는 [[JSON-LD]], [[JSON]], CBOR [[?RFC7049]]와 같은 여러 표현 구문에서 언어 및 기본 방향 정보의 표현이 가능하도록 하기 위해 웹에서의 문자열: 언어 및 방향 메타데이터 문서 [[STRING-META]]의 교차 구문 표현 섹션을 읽는 것이 좋다.

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

"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 컨텍스트를 확장하고 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"
}
      

복잡한 언어 마크업

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

HTML로 정보를 인코딩할 수 있음에도 불구하고 구현자는 다음과 같은 이유로 이렇게 하지 않는 것이 좋다:

• 일종의 HTML 프로세서가 필요하므로 언어 및 기본 방향 정보 처리 부담이 증가한다.
• 무분별하게 HTML을 처리하면 데이터 생성 과정의 어느 시점에서 공격자가 주입한 script 태그를 실행하여 이 데이터 모델을 사용할 때 보안 공격 표면이 증가한다.

구현자가 특정 사용 사례를 해결하기 위해 실행 가능한 스크립트를 포함할 수 있는 HTML이나 기타 마크업 언어를 사용해야 한다고 생각하는 경우, 공격자가 마크업을 사용하여 마크업 소비자에 대한 주입 공격을 수행하는 방법을 분석한 다음 식별된 공격에 대한 완화책을 배포하는 것이 좋다.