- Bluesky 계정은 특정 앱에 묶이지 않고 atproto 기반의 여러 앱에서 사용할 수 있으며, DID(탈중앙 식별자) 가 앱과 분리된 신원 확인 기반을 제공함
- DID는
did:<method>:<identifier> 형식이며, DID Document에 담긴 공개 키와 PDS 위치를 이용해 게시물 작성자와 계정의 연관성을 검증함
did:web은 도메인의 /.well-known/did.json을 조회하는 단순한 방식이지만, DNS·등록기관 의존성과 웹 서버 중단, 문서 변경 반영 지연에 취약함- Bluesky가 만든
did:plc는 ID를 특정 도메인에서 분리하고 plc.directory가 운영 부담을 맡지만, DNS 대신 plc.directory를 신뢰해야 하며 Bluesky에서는 블록체인 기반 DID 방식 등을 사용할 수 없음
- 사용자는 추가 키 등록과 키 순환, 자체 PDS 운영을 통해 Bluesky가 만든 키를 제거하고 신원을 실질적으로 직접 통제할 수 있으며, 복잡한 키 관리를 모두에게 강제하지 않고 원하는 사람에게 선택권을 제공함
Bluesky 계정과 DID 기반 신원
- “Bluesky 계정”은 Bluesky에서만 쓰는 계정이 아니라 ATmosphere의 여러 애플리케이션에서 사용할 수 있는 계정임
- Bluesky와 다른 앱의 기반 프로토콜인 atproto는 사용자가 누구인지 나타내고 로그인이나 게시물 작성자를 확인하기 위해 DID를 사용함
- W3C가 2022년에 표준화한 DID는 애플리케이션에서 신원의 기반으로 사용할 수 있는 탈중앙 식별자임
- DID의 탈중앙성은 단일 기관이 유효한 DID 유형을 결정하는 대신, 사용자가 자신의 신원을 검증할 DID 메서드를 선택할 수 있다는 데 있음
- 다만 애플리케이션이 모든 DID 메서드를 자동으로 처리하지는 못함
- 메서드마다 지원 코드를 별도로 구현해야 함
- 앱이
foo 메서드를 지원하지 않으면 did:foo:1243을 제시해도 해석할 수 없음
DID와 DID Document
- 예시 DID
did:plc:3danwc67lo7obz2fmdg6jxcr은 콜론으로 구분된 세 부분으로 구성됨
- 스킴:
did
- 메서드:
plc
- 메서드별 식별자:
3danwc67lo7obz2fmdg6jxcr
- DID를 사용하려면 이를 DID Document로 해석해야 함
- DID Document는 DID 주체나 위임자가 자신을 인증하고 해당 DID와의 연관성을 증명할 수 있도록 암호학적 공개 키 등의 데이터를 담음
- 예시 문서에는 신원 검증에 필요한 정보가 포함됨
id: DID 자체alsoKnownAs: at://steveklabnik.comverificationMethod: Multikey 유형과 publicKeyMultibaseservice: AtprotoPersonalDataServer 유형의 PDS 엔드포인트
- 임의의 게시물이 특정 사용자가 작성했다고 주장할 때, 문서의 검증 정보를 이용해 해당 주장의 진위를 확인할 수 있음
- DID를 문서로 해석하는 절차는 메서드별 표준이 정함
did:plc는 PLC 표준을 따름- Bluesky가 지원하는 또 다른 방식인
did:web은 Web 방식으로 해석함
did:web의 해석 방식
did:web을 사용하는 사람은 매우 적지만 구조가 단순해 DID 해석 과정을 이해하기 쉬움- Liz Fong-Jones의
did:web:lizthegrey.com은 메서드별 식별자인 lizthegrey.com을 다음 URL 템플릿에 넣어 해석함
https://<id>/.well-known/did.json
- 해당 URL에서 받은 DID Document에는 다음 정보가 담김
id: did:web:lizthegrey.comalsoKnownAs: at://web.lizthegrey.com, did:plc:i4tfenpfog244rxry5uz4vtkverificationMethod: atproto용 Multikey 공개 키serviceEndpoint: https://pds.lizthegrey.com
did:web이 안고 있는 제약
did:web은 DNS와 도메인 등록기관에 의존함
- 등록기관이 도메인을 회수하면 DID 통제권도 잃음
- 도메인을 더 이상 사용하지 않거나 만료 후 다른 사람이 구매해도 신원을 잃을 수 있음
- 등록기관 계정이 해킹돼 도메인을 탈취당하는 경우도 마찬가지임
- DID Document를 제공하는 웹 서버를 계속 실행해야 하며, 서버가 중단되면 문서도 가져올 수 없음
- DID Document 변경 사실을 클라이언트에 즉시 알릴 방법도 없음
- 애플리케이션이 오래된 문서를 계속 사용할 수 있음
- 문서 갱신과 애플리케이션 반영 사이의 지연으로 최신 문서를 다시 가져올 때까지 일시적인 문제가 생길 수 있음
did:plc가 바꾸는 신원 유지 방식
- Bluesky는
did:web의 문제를 줄이기 위해 did:plc를 개발함
did:plc는 전체 DID를 다음 URL 템플릿에 넣어 DID Document를 가져옴
https://plc.directory/<did>;
- URL을 조회한다는 점은
did:web과 같지만, 운영과 신원 유지 방식이 다름
- DID가 특정 도메인에 묶이지 않아
steveklabnik.com을 만료시키고 steve.klabnik.com으로 옮겨도 동일한 DID를 유지할 수 있음
- 웹 서버 운영은 사용자 대신
plc.directory가 맡으므로 운영 부담이 줄어듦
- 신뢰 대상 자체가 사라지는 것은 아님
did:web에서는 DNS와 도메인 등록기관을 신뢰해야 함did:plc에서는 plc.directory가 ID를 빼앗지 않고 탈취당하지 않을 것이라고 신뢰해야 함
- DNS와
plc.directory 모두 신뢰할 수 없다고 보는 사용자는 블록체인 등으로 이름을 해석하는 다른 DID 메서드를 선택할 수 있음
- 그러나 Bluesky가 이런 메서드를 지원하지 않으므로 Bluesky 애플리케이션에서는 사용할 수 없음
접근성 문제와 새로운 DID 방식
did:web을 직접 설정하려면 비전문 사용자에게 부담스러운 작업이 필요함
- 도메인을 등록하고 지속적으로 비용을 지불해야 함
- 웹 서버를 설정하고 DID Document용 JSON을 작성해야 함
- 서버를 계속 가동해야 함
- 개인 키를 저장하고 안전하게 관리해야 함
- 이 과정은 일반적인 웹 앱 가입보다 훨씬 복잡해, 비전문 사용자도 플랫폼을 이용하게 하려는 Bluesky의 목표와 맞지 않음
plc.directory가 관련 작업을 관리하면 사용자가 이 단계를 직접 수행하지 않아도 됨did:webvh는 did:web을 확장해 일부 단점을 보완하려는 방식으로 1.0에 도달했지만, 구체적인 명세까지 비교 대상에 포함되지는 않음
Bluesky에서 신원을 직접 소유하는 방법
- 기본 설정에서는 Bluesky가 사용자의 키 쌍을 생성하고 비밀 키에 접근할 수 있으므로, 어떤 의미에서는 Bluesky가 신원을 소유한다고 볼 수 있음
did:plc는 ID에 추가 키 쌍을 등록하고 서명 키를 순환할 수 있음
- Bluesky가 생성한 키를 제거할 수 있음
- 사용자가 직접 만든 키로 교체할 수 있음
- 키를 바꾸는 것만으로 Bluesky 인프라와 완전히 분리되지는 않음
- PDS가 게시물에 서명하려면 사용자의 키를 사용해야 함
- Bluesky 관리형 PDS를 사용하면 일반적으로 키가 Bluesky 인프라에 저장됨
- Bluesky와 신원을 분리하려면 자체 PDS를 운영한 뒤 키를 순환해야 함
- 키가 사용자가 소유한 인프라에 저장됨
- 이후 Bluesky는 해당 키를 통제하지 못함
- 대부분의 사용자가 자체 PDS와 키 관리를 선택하지 않더라도, 동기가 있는 사용자가 신원을 실질적으로 소유할 수 있다는 점은 중요한 설계 속성임
- 모든 사용자에게 직접 키 관리를 강제하기보다 원하는 사용자가 선택할 수 있게 하는 방식이 대부분의 사용자에게 적절함