Controlled Identifiers v1.0

아래의 사용 사례들은 이 규격의 필요성을 보여준다. Use Cases and Requirements for Decentralized Identifiers와 Verifiable Credentials Use Cases에 있는 것들처럼 관련된 다른 사용 사례도 많이 존재하지만, 아래에 기술한 것들이 이 규격이 다루고자 설계된 주요 시나리오다.

다음 요구사항들은 이 규격 앞부분에서 기술한 사용 사례로부터 도출된 것이다. 더욱 탈중앙화된 해법으로 이어질 수 있는 추가 요구사항은 Use Cases and Requirements for Decentralized Identifiers에서 찾을 수 있다.

1. 고유성이 보장된 식별자

식별자는 중복 가능성 없이 전역적으로 고유하다.

2. 제어권 증명

식별자에 대한 제어를 주장하는 엔티티가 실제로 그 제어자임을 증명할 수 있다.

3. 연관된 암호학적 자료

식별자는 엔티티가 그 식별자에 대한 제어를 증명하는 데 사용할 수 있는 암호학적 자료와 긴밀하게 결합되어 있다.

4. 간소화된 키 교체

지정된 식별자가 가리키는 엔티티는 요청 당사자의 직접적인 개입 없이 최소한의 개별 상호작용만으로 인증 자료를 갱신할 수 있다.

5. 서비스 엔드포인트 탐색

이러한 식별자는 요청 당사자가 식별자의 주체와 상호작용하기 위해 이용 가능한 서비스 엔드포인트를 조회할 수 있게 한다.

6. 제어권의 위임

식별자의 제어자는 그 제어권을 전부 또는 일부 제3자에게 위임할 수 있다.

7. 암호학적 미래 대비

이러한 식별자와 그에 연관된 정보는 기술이 발전함에 따라 갱신될 수 있다. 현재의 암호 기법은 양자 계산 공격에 취약한 것으로 알려져 있다. 미래 대비가 된 식별자는 갱신된 첨단 인증 및/또는 인가 기술로 동일한 식별자를 계속 사용할 수 있는 수단을 제공한다.

8. 암호학적 인증과 통신

이러한 식별자는 대체로 공개키-개인키 쌍을 사용하여, 개인을 인증하거나 식별자의 주체와의 통신을 보호하는 데 활용할 수 있는 암호 기법의 사용을 가능하게 한다.

9. 법적으로 인정 가능한 식별

이러한 식별자는 하나 이상의 관할권에서 법적으로 유효하다고 인정될 수 있는 크리덴셜과 거래의 기반으로 사용될 수 있다.

10. 인간 중심의 상호 운용성

탈중앙 식별자는 기술적 전문성이나 전문 지식이 없는 사람도 쉽게 사용할 수 있어야 한다.

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

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

적합 제어 식별자 문서란 데이터 모델을 구체적으로 표현한 것 중 2. 데이터 모델 절과 4. 컨텍스트와 어휘 절의 관련 규범적 요구사항을 따르는 모든 것이다.

적합 검증 방법이란 데이터 모델을 구체적으로 표현한 것 중 2.2 검증 방법 절과 4. 컨텍스트와 어휘 절의 관련 규범적 요구사항을 따르는 모든 것이다.

적합 문서란 적합 제어 식별자 문서이거나 적합 검증 방법이다.

적합 프로세서란 3. 알고리즘 절의 관련 규범적 진술에 따라 적합 문서를 생성하거나 소비하는, 소프트웨어 및/또는 하드웨어로 구현된 모든 알고리즘이다. 적합 프로세서는 적합하지 않은 문서를 소비할 때 오류를 생성해야 한다.

이 절은 이 규격에서 사용하는 용어를 정의한다. 이 용어 중 하나가 이 규격에 나타날 때마다 관련 정의로의 링크가 포함된다.

인증(authentication)

엔티티가 특정 속성을 가지고 있거나 특정 비밀을 제어하고 있음을 검증자에게 증명할 수 있는 과정.

인가(authorization)

엔티티가 특정 활동을 수행하도록 허용되어 있음을 검증자에게 증명할 수 있는 과정.

제어 식별자(controlled identifier)

어떤 엔티티의 제어 아래에 있음을 증명할 수 있는 유형의 식별자.

제어 식별자 문서(controlled identifier document)

암호학적 자료를 담고, 어떤 식별자의 제어자로부터의 증명을 검증하고 그 제어자와 상호작용하는 데 사용할 수 있는 서비스 엔드포인트를 나열하는 문서.

제어자(controller)

제어 식별자 문서를 갱신하거나 검증 방법을 사용하여 증명을 생성하는 것과 같이, 특정 자원에 대해 어떤 행위를 수행할 수 있는 엔티티.

암호 스위트(cryptographic suite)

특정 보안 목표를 달성하기 위해 특정 암호 프리미티브를 사용하는 수단. 이러한 스위트는 검증 방법, 디지털 서명 유형, 그것들의 식별자, 그리고 기타 관련 속성을 명시할 수 있다.

개인키(private key)

증명을 생성하는 데 사용할 수 있는 암호학적 자료.

증명(proof)

어떤 주장의 유효성을 확인해 주는 수학적 논증. 그 논증은 검증자가 그 주장의 유효성을 암호학적으로 확인할 수 있게 하는 속성과 값의 집합으로 이루어진다. 디지털 서명은 증명의 한 유형이다.

공개키(public key)

대응하는 개인키로 생성된 증명을 검증하는 데 사용할 수 있는 암호학적 자료.

주체(subject)

제어 식별자 문서에서 id 속성의 값이 가리키는, 사람·그룹·조직·물리적 사물· 디지털 사물·논리적 사물과 같은 엔티티. 제어 식별자 문서에서 식별된 주체는 인증 중이나 검증가능한 크리덴셜에서와 같이 다른 맥락에서도 주체로 사용된다.

검증 방법(verification method)

증명을 독립적으로 검증하는 데 사용되는 방법과 그 매개변수. 예를 들어 암호학적 공개키는 디지털 서명과 관련하여 검증 방법으로 사용될 수 있다. 그러한 사용에서 그것은 서명자가 연관된 암호학적 개인키를 사용했음을 검증한다.

검증 관계(verification relationship)

하나 이상의 검증 방법이 주체를 대신하여 만들어진 증명을 검증하도록 인가되었다는 표현. 검증 관계의 한 예는 2.3.1 인증이다.

디지털 세계나 물리적 세계의 엔티티를 식별자, 제어 식별자 문서, 또는 암호학적 자료에 결속하려면 이 규격이 상정하는 보안 프로토콜의 사용이 필요하다. 다음 절들은 몇 가지 가능한 시나리오와, 그 안의 엔티티가 인증이나 인가를 목적으로 식별자나 제어 식별자 문서에 대한 제어를 어떻게 증명할 수 있는지를 기술한다.

식별자가 가리키는 주체가 제어를 증명하는 경우에도, 그 주체의 해석은 여전히 맥락에 따라 달라지며 잠재적으로 모호하다.

예를 들어 어느 학교가 https://controller.example/abc를 주체 식별자로 사용하여 컴퓨터 과학 입문의 교사에 관한 검증가능한 크리덴셜을 발급하면서, "https://controller.example/abc는 컴퓨터 과학 입문의 교사다"와 "https://controller.example/abc는 학교 컴퓨터실 접근을 통제한다. 접근을 요청하려면 그들에게 연락하라"라고 말할 수 있다.

이 사용에서는 https://controller.example/abc가 특정 교사를 가리키는지 아니면 현재의 교사가 누구든 그를 가리키는지 모호하다. 추가 진술이 있어야만 그 차이를 분간할 수 있을지 모른다. 하지만 여전히 까다롭다. 예를 들어 다음 진술의 주체는 여전히 모호하다:

<https://controller.example/abc>
  <https://schema.org/name>
    "Bob Smith" .

https://controller.example/abc가 특정 인간을 가리킨다면, 그 진술은 그 이름으로 식별되는 특정 인간에 관한 어테스테이션으로 받아들여진다. 그러나 https://controller.example/abc가 _현재의_ 교사를 가리키는 데 사용된다면, 그것은 현재의 교사가 실제로 그 이름을 가지고 있는 경우에도 유효하다. 이 경우 모호성은 중요하지 않다.

그러나 다음과 같은 진술에서는 그 차이가 매우 중요해진다.

<https://controller.example/abc>
  <http://law.example/convicted>
    <http://calaw.example/PenalCode647b> .

이 진술을 영어로 옮기면 "https://controller.example/abc가 가리키는 사람은 캘리포니아 형법 647b조로 유죄 판결을 받았다"가 될 수 있다. 그런데 우리가 뜻한 사람은 누구인가? 그 학교의 컴퓨터 과학 교사 중 한 명, 일부, 또는 전원이 PenalCode647b 위반으로 유죄 판결을 받았다고 말하려던 것인가? 아니면 특정 개별 교사, 아마도 "Bob Smith"라는 이름의 교사가 그 범죄로 유죄 판결을 받았다고 말하려던 것인가?

이 문제는 주체가 검증가능한 크리덴셜의 발급에 근본적으로 관여하지 않은 상황에서 특히 어렵다. 예를 들어 어떤 식별자가 학교에서 교사를 가리키는 데 사용되고, 학생이나 학부모가 교사와 학교 모두 관여하지 않은 채 그 식별자를 사용하여 그 교사에 관한 진술을 할 수 있다. 이런 경우, 예컨대 "컴퓨터 과학 수업의 현재 교사 누구든"이라는 학교가 의도한 의미의 미묘한 뉘앙스가 사라지고, 그 식별자가 학부모와 학생에 의해 특정 교사를 가리키는 데 오용되는 것을 쉽게 상상할 수 있으며, 이는 학교도 교사도 그 대화를 알지 못하는 맥락에서 일어날 가능성이 크다.

자연어에서는 이러한 모호성이 흔히 쉽게 무시되거나 바로잡힌다. 디지털 매체에서는 의도된 지시 대상을 확정하기 위해 맥락을 평가하는 것이 매우 중요한데, 특히 서로 다른 발급자가 서로 다른 맥락에서 식별자를 사용할 때 — 예를 들어 학교는 공식 학교 웹사이트에서, 학부모와 학생은 비공식 소셜 네트워킹 앱에서 사용할 때 — 그렇다.

요컨대, 특정 식별자의 주체에 대한 어떤 특정 해석에 의존할 때는 식별자가 생성되고 사용되는 맥락을 고려해야 한다.

탈중앙 아키텍처에서는 암호학적 자료나 암호학적 디지털 서명의 만료 정책을 집행할 중앙 권위체가 없을 수 있다. 따라서 요청 당사자가 암호학적 자료가 사용된 시점에 만료되지 않았음을 검증하는 것은 검증 라이브러리와 같은 지원 소프트웨어를 통해서다. 요청 당사자는 자신의 검증 과정에 대한 입력에 더하여 자신만의 만료 정책을 적용할 수 있다. 예를 들어 어떤 요청 당사자는 5분 전의 인증을 받아들이는 반면, 고정밀 시간 소스에 접근할 수 있는 다른 요청 당사자는 인증이 지난 500밀리초 이내에 타임스탬프 되기를 요구할 수 있다.

레거시 암호학적 디지털 서명을 검증하는 것과 같이, 이미 만료된 암호학적 자료의 사용을 연장할 정당한 필요가 있는 요청 당사자도 있다. 이러한 시나리오에서 요청 당사자는 자신의 검증 소프트웨어에 암호 키 자료 만료를 무시하도록 지시하거나, 암호 키 자료가 사용된 시점에 만료되었는지를 판정하도록 지시할 수 있다.

교체(rotation)는 새로운 검증 방법이 제어 식별자 문서에 추가된 후 기존 검증 방법에 연관된 비밀 암호학적 자료를 비활성화하거나 파기할 수 있게 하는 관리 과정이다. 이후로는 제어자가 기존 비밀 암호학적 자료를 사용하여 생성했을 새로운 증명을 이제 대신 새로운 암호학적 자료를 사용하여 생성할 수 있고, 새로운 검증 방법을 사용하여 검증할 수 있다.

교체는 검증 방법 침해에 대비하는 유용한 메커니즘인데, 제어자가 검증 방법을 자주 교체하면 침해된 단일 검증 방법이 공격자에게 갖는 가치가 줄어들기 때문이다. 교체 직후에 폐기를 수행하는 것은 메시지 암호화와 인증에 관여하는 것과 같이 제어자가 수명이 짧은 검증에 지정하는 검증 방법에 유용하다.

검증 방법 교체의 사용을 고려할 때 다음 고려사항이 유용할 수 있다:

• 검증 방법 교체는 선제적 보안 조치다.
• 검증 방법 교체를 정기적으로 수행하는 것은 일반적으로 모범 사례로 여겨진다.
• 더 높은 보안 환경일수록 검증 방법 교체를 더 자주 수행하는 경향이 있다.
• 검증 방법 교체는 제어 식별자 문서의 현재 또는 최신 버전에 대한 변경으로만 나타난다.
• 검증 방법이 오랫동안 활성 상태였거나 많은 연산에 사용된 경우, 제어자는 교체를 수행하고 싶어 할 수 있다.
• 검증 방법의 잦은 교체는 연관된 크리덴셜을 계속해서 갱신하거나 새로 고쳐야만 하는 당사자에게 번거로울 수 있다.
• 제어 식별자 문서의 최신 버전에 존재하지 않는 검증 방법에 의존하는 증명이나 서명은 교체의 영향을 받지 않는다. 이러한 경우 검증 소프트웨어는 그 증명이나 서명의 유효성을 판정하기 위해, 특정 검증 방법이 언제 유효할 것으로 기대되었는지와 같은 추가 정보뿐 아니라 이력 기록을 담은 검증가능한 데이터 레지스트리에 대한 접근을 요구할 수 있다. 이 옵션이 모든 시스템에서 이용 가능하지 않을 수 있다.
• 제어자는 얼마간의 시간이 지난 후 기존 검증 방법을 대체하려는 새로운 검증 방법을 추가할 때 교체를 수행한다.

폐기(revocation)는 기존 검증 방법에 연관된 비밀 암호학적 자료를 비활성화하여, 그것이 새로운 증명을 생성하는 유효한 형태가 되기를 멈추게 하는 관리 과정이다.

폐기는 검증 방법 침해에 대응하는 유용한 메커니즘이다. 교체 직후에 폐기를 수행하는 것은 메시지 암호화와 인증에 관여하는 것과 같이 제어자가 수명이 짧은 검증에 지정하는 검증 방법에 유용하다.

검증 방법에 연관된 비밀이 침해되면 공격자는 제어 식별자 문서에서 제어자가 표현한 검증 관계에 따라, 예를 들어 인증을 위해 그 비밀을 사용할 수 있다. 공격자의 비밀 사용은 검증 방법이 등록된 시점부터 폐기된 시점까지 정당한 제어자의 사용과 구별되지 않을 수 있다.

검증 방법 폐기의 사용을 고려할 때 다음 고려사항이 유용할 수 있다:

• 검증 방법 폐기는 대응적 보안 조치다.
• 키 폐기를 지원하는 것은 모범 사례로 여겨진다.
• 제어자는 침해된 것으로 알려진 어떤 검증 방법이든 즉시 폐기할 것으로 기대된다.
• 검증 방법 폐기는 제어 식별자 문서의 최신 버전에 대한 변경으로만 구현될 수 있다. 이전 버전을 소급하여 조정할 수는 없다.
• 검증 방법이 더 이상 제어자나 제어자를 대신하여 행동하도록 신뢰된 당사자에게만 배타적으로 접근 가능하지 않게 되면, 위장, 절도, 사기와 같은 침해의 위험을 줄이기 위해 즉시 폐기될 것으로 기대된다.
• 폐기는 폐기된 검증 방법에 연관되어 그 폐기 이후에 생성된 증명이나 서명이 무효로 취급되어야 한다고 제어자가 표현하는 것으로 이해될 것으로 기대된다. 그것은 또한 기존 증명이나 서명이 공격자에 의해 생성되었을 수 있다는 우려를 함의할 수도 있으나, 반드시 그런 것은 아니다. 그러나 검증자는 여전히 그러한 증명이나 서명을 자신의 재량으로 받아들이거나 거부하기로 선택할 수 있다.
• 검증 방법이 제어 식별자 문서에 존재하더라도, 공개키 폐기 인증서나 외부 허용 목록 또는 거부 목록과 같은 추가 정보가 검증 방법이 폐기되었는지를 판정하는 데 사용될 수 있다.
• 개인의 운영 체제, 안티바이러스, 엔드포인트 보호 소프트웨어와 같이 침해된 검증 방법에 의존하는 소프트웨어의 일상적 동작은 그 검증 방법이 공개적으로 폐기될 때 영향을 받을 수 있다.

Multiformats는 자기 기술적 데이터를 가능하게 한다. 데이터가 Multiformat임이 알려져 있다면, 데이터 시작 부분에 표현된 몇 개의 간결한 헤더 바이트를 읽어 그 정확한 타입을 판정할 수 있다. Multibase, Multihash, Multikey는 이 규격이 정의하는 Multiformat의 유형이다.

Multiformats 규격이 존재하는 이유는 애플리케이션 개발자가 서로 다른 사용 사례와 그 요구사항에 기반하여 서로 다른 base 인코딩 함수, 암호 해싱 함수, 암호 키 형식 등을 적절히 선택하기 때문이다. 세상의 어떤 단일 base 인코딩 함수, 암호 해싱 함수, 암호 키 형식도 모든 요구사항 집합을 충족한 적이 없다. Multiformats는 자기 문서화 데이터와 문서 안에서 임의의 base 인코딩, 암호 해시, 암호 키 형식을 인코딩하거나 탐지하는 대안적 수단을 제공한다.

상호 운용성을 높이기 위해, 규격 작성자는 특정 애플리케이션이나 생태계에 사용할 Multiformat의 수를 최소화하되 — 최적으로는 단 하나만 선택하도록 — 강력히 권한다.

암호화 알고리즘은 암호학과 컴퓨팅 성능의 발전으로 인해 깨지는 것으로 알려져 왔다. 구현자는 제어 식별자 문서에 놓인 어떤 암호화 데이터든 결국에는 그 암호화 데이터에 접근 가능한 동일한 대상에게 평문으로 제공될 수 있다고 가정할 것을 권한다. 이는 제어 식별자 문서가 공개된 경우 특히 그러하다.

제어 식별자 문서의 전부 또는 일부를 암호화하는 것은 데이터를 장기적으로 보호하는 적절한 수단이 아니다. 마찬가지로 제어 식별자 문서에 암호화 데이터를 놓는 것은 개인 데이터를 보호하는 적절한 수단이 아니다.

위의 유의사항을 감안할 때, 암호화 데이터가 제어 식별자 문서에 포함된다면, 구현자는 암호화 데이터와 연관 당사자 사이의 관계를 추론하는 데 사용될 수 있는 어떤 상관 가능한 정보도 연관시키지 않을 것을 권한다. 상관 가능한 정보의 예로는 수신 당사자의 공개키, 수신 당사자의 통제 아래 있는 것으로 알려진 디지털 자산에 대한 식별자, 또는 수신 당사자에 대한 사람이 읽을 수 있는 설명이 있다.

이미지, 웹 페이지, 스키마와 같은 외부 기계 판독 가능 콘텐츠에 대한 링크를 포함하는 제어 식별자 문서는 변조에 취약하다. 외부 링크는 Verifiable Credentials Data Model v2.0 규격에 기술된 것과 같이 관련 자원을 보호하는 메커니즘을 사용하여 무결성 보호할 것을 강력히 권한다. 외부 링크를 무결성 보호할 수 없고 제어 식별자 문서의 무결성이 그 외부 링크에 의존한다면, 그 외부 링크는 피해야 한다.

제어 식별자 문서 자체의 무결성이 영향을 받을 수 있는 외부 링크의 한 예는, 존재할 경우 JSON-LD 컨텍스트 [JSON-LD11]다. 침해에 대비하기 위해, JSON-LD를 사용하는 제어 식별자 문서 소비자는 JSON-LD 컨텍스트의 로컬 정적 사본을 캐시하거나, 외부 JSON-LD 컨텍스트의 안전한 버전에 연관된 것으로 알려진 암호 해시에 대해 외부 컨텍스트의 무결성을 검증할 것을 권한다.

2.1.2 제어자 절에 기술된 대로, 이 규격은 controller 속성의 사용을 통해 제어 식별자 문서의 변경 제어권을 외부 제어 식별자 문서에 기술된 엔티티에게 위임하는 메커니즘을 포함한다.

변경 제어권 위임은, 한 엔티티의 보살핌이 다른 엔티티(들)의 책임인 경우와, 어떤 엔티티가 다른 엔티티가 계정 복구 서비스를 제공하기를 바라는 경우 등 여러 사용 사례를 다룬다. 그러한 시나리오에서는 후견인이 자신의 키 자료 교체를 관리하도록 허용하는 것이 유익할 수 있다. 또한 위임자가 원격 문서를 알려진 정상 값으로 "고정(pin)"하기 위해 원격 제어 식별자 문서의 암호 해시를 연관시키는 것이 유익할 수 있다.

이 문서는 암호학적으로 보호된 URL에 대한 특정 메커니즘을 지정하지 않지만, Verifiable Credentials Data Model v2.0의 relatedResource 속성과 Verifiable Credential Data Integrity 1.0의 digestMultibase 속성이 그러한 보호를 제공할 수 있는 메커니즘에 활용될 수 있다.

인증 이벤트의 보안 맥락에 관한 추가 정보는, 특히 금융 및 공공 부문과 같은 규제 영역에서 규정 준수를 이유로 흔히 요구된다. 이 정보는 흔히 보증 수준(Level of Assurance, LOA)이라고 불린다. 예로는 비밀 암호학적 자료의 보호, 신원 증명 과정, 인증기(authenticator)의 폼 팩터가 있다.

Payment services (PSD 2)와 eIDAS는 보안 맥락에 그러한 요구사항을 도입한다. 보증 수준 프레임워크는 eIDAS, NIST 800-63-3, ISO/IEC 29115:2013과 같은 규정과 표준에 의해 분류되고 정의되며, 여기에는 보안 맥락에 대한 요구사항과 그것을 달성하는 방법에 대한 권고가 포함된다. 이는 FIDO2/WebAuthn이 요구사항을 충족할 수 있는 강한 사용자 인증을 포함할 수 있다.

일부 규제 시나리오는 특정 보증 수준의 구현을 요구한다. 어써션과 인증을 수행하는 데 사용되는 검증 관계가 이러한 상황 중 일부에서 사용될 수 있으므로, 적용된 보안 맥락에 관한 정보를 표현하여 검증자에게 제공해야 할 수 있다. 이 정보를 제어 식별자 문서 데이터 모델에 인코딩할지 여부와 그 방법은 이 규격의 범위 밖이다. 관심 있는 독자는 1) 그 정보가 검증가능한 크리덴셜 [VC-DATA-MODEL-2.0]을 사용하여 전송될 수 있고, 2) 제어 식별자 문서 데이터 모델이 이 정보를 포함하도록 확장될 수 있음에 유의할 수 있다.

제어 식별자 문서가 주체의 인증이나 인가를 위한 서비스를 공개한다면(2.1.4 서비스 절 참고), 그 서비스 엔드포인트가 지원하는 인증 및/또는 인가 프로토콜의 요구사항을 준수하는 것은 서비스 제공자, 주체, 요청 당사자의 책임이다.

제어 식별자 문서가 특정 개인에 관한 것이고 공개용이라면, 제어 식별자 문서에 개인 생체 데이터나 신상 데이터를 담지 않는 것이 결정적으로 중요하다. 개인 데이터가 공개 암호 키나 IP 주소와 같은 가명 정보를 포함할 수 있는 것은 사실이지만, 그런 종류의 정보를 공개하는 것은 개인의 전체 이름, 프로필 사진, 소셜 미디어 계정을 제어 식별자 문서에 공개하는 것과 같은 즉각적인 프라이버시 위험을 만들지는 않는다. 더 나은 대안은 그러한 개인 데이터를 검증가능한 크리덴셜 [VC-DATA-MODEL-2.0]이나 사적이고 안전한 통신 채널로 전송되는 다른 데이터 형식과 같은 다른 수단을 통해 전송하는 것이다.

동일 출처 정책(Same-origin policy)은 기본적으로 정보를 동일한 웹 도메인으로 제한하는 보안 및 프라이버시 개념이다. Web Authentication:An API for accessing Public Key Credentials Level 1과 같이 이 정책을 암호 키로 확장하는 메커니즘이 있다. 암호 키가 특정 도메인에 결속될 때, 이를 때때로 쌍별 식별자(pairwise identifier)라고 부른다.

동일 출처 정책은 교차 출처 자원 공유(Cross-origin resource sharing)(CORS)와 같은 다양한 사용 사례를 위해 재정의될 수 있다. 이 규격은 검증 방법과 서비스 엔드포인트의 교차 출처 자원 공유를 허용하는데, 이는 상관 가능한 식별자가 출처 간에 공유될 수 있음을 의미한다. 자원 공유는 긍정적 보안 결과(암호 키 등록 부담 감소)로 이어질 수 있지만, 부정적 프라이버시 결과(추적)로도 이어질 수 있다. 이 규격을 사용하는 이들은 각 접근법에 절충점이 있으며 개인이나 조직의 필요에 따라 보안과 프라이버시를 극대화하는 메커니즘을 사용하라는 경고를 받는다. 동일 출처에 결속된 암호 키로 충분한 경우 모든 사용 사례에 제어 식별자 문서를 사용하는 것이 항상 유리한 것은 아니다.

식별자는 원치 않는 상관관계에 사용될 수 있다. 제어자는 각 관계나 상호작용 도메인에 고유한 쌍별 식별자를 사용하여 이 프라이버시 위험을 완화할 수 있다. 결과적으로 각 식별자는 가명처럼 작동한다. 쌍별 식별자는 맥락 간 상관관계가 명시적으로 요구될 때에만 둘 이상의 당사자와 공유되면 된다. 쌍별 식별자가 기본값이라면, 식별자를 공개적으로 게시하거나 여러 당사자와 공유할 유일한 필요는 제어자 및/또는 주체가 공개 식별과 상호작용 도메인 간 상관관계를 명시적으로 원할 때뿐이다.

쌍별 식별자의 반(反)상관관계 보호는 대응하는 제어 식별자 문서의 데이터가 상관될 수 있으면 쉽게 무력화된다. 예를 들어 여러 제어 식별자 문서에서 동일한 검증 방법을 사용하는 것은 동일한 식별자를 사용하는 것만큼 많은 상관관계 정보를 제공할 수 있다. 따라서 쌍별 식별자를 위한 제어 식별자 문서도, 검증 방법이 그 쌍별 관계에 고유하도록 보장하는 것과 같이 쌍별로 고유한 정보를 사용해야 한다.

주체가 어떤 타입이거나 어떤 성격의 사물인지를 명시적으로 또는 추론을 통해 나타내는 데 사용될 수 있는 속성을 제어 식별자 문서에 추가하는 것은 위험하며, 특히 주체가 사람인 경우 그러하다.

그러한 속성은 잠재적으로 제어 식별자 문서에 개인 데이터(6.1 개인 데이터를 비공개로 유지하기 참고)나 상관 가능한 데이터( 6.3 식별자 상관관계 위험과 6.4 제어 식별자 문서 상관관계 위험 참고)가 존재하는 결과를 낳을 수 있을 뿐만 아니라, 특정 식별자를 특정 연산이나 기능에 포함하거나 배제하는 방식으로 묶는 데에도 사용될 수 있다.

제어 식별자 문서에 타입 정보를 포함하는 것은 IoT 기기와 같이 사람이 아닌 엔티티인 주체에 대해서도 개인 프라이버시 피해를 초래할 수 있다. 제어자를 중심으로 그러한 정보를 집합하는 것은 일종의 디지털 핑거프린트로 작용할 수 있으며, 이는 피하는 것이 가장 좋다.

이러한 위험을 최소화하기 위해, 제어 식별자 문서의 모든 속성은 식별자 사용과 관련된 검증 방법과 검증 관계를 표현하기 위한 것이어야 한다.

제어자가 제어 식별자 문서에 적어도 하나의 서비스를 선택적으로 표현할 수 있는 능력은 그들의 제어권과 주체성을 높인다. 제어 식별자 문서에 추가되는 각 엔드포인트는 엔드포인트 설명 간의 상관관계 때문이든, 서비스가 인가 메커니즘으로 보호되지 않기 때문이든, 또는 그 둘 다이든 프라이버시 위험을 더한다.

제어 식별자 문서는 흔히 공개되며, 표준화되어 있으므로 효율적으로 저장되고 색인될 것이다. 이 위험은 제어 식별자 문서가 불변의 검증가능한 데이터 레지스트리에 게시되면 증가한다. URL이 참조하는 제어 식별자 문서의 이력에 대한 접근은 표준의 사용을 통해 더 효율적으로 이루어지는 일종의 트래픽 분석을 가능하게 한다.

하나의 제어 식별자 문서에 여러 서비스를 포함함으로써 발생하는 추가 프라이버시 위험의 정도는 추정하기 어려울 수 있다. 프라이버시 피해는 대체로 의도치 않은 결과다. URL은 개별 사람, 가구, 동호회, 고용주와 연관될 수 있는 문서, 서비스, 스키마, 그 밖의 것들을 가리킬 수 있으며 — 그 서비스의 상관관계는 강력한 감시 및 추론 도구가 될 수 있다. 이 잠재적 피해의 한 예는 https://example.co.uk과 같은 여러 흔한 국가 수준 최상위 도메인이 주체의 대략적 위치를 더 높은 확률로 추론하는 데 사용될 수 있을 때 볼 수 있다.