ID
내 프로필은 여기 있다. https://bsky.app/profile/euroka.moe
이 링크는 2개로 나눌 수 있다. bsky.app 앱뷰, euroka.moe 핸들. 그런데…
- 왜 도메인 형식을 지닐까?
- PDS를 변경해도 핸들은 왜 같을까?
- 핸들을 변경해도 어떻게 게시글 등은 유지될까?
DID
이때 DID가 등장한다. Decentralized ID의 약자로, DID 종류(메서드)에 따라 탈중앙화된 식별자를 고유하게 생성한다. 180개 이상의 DID 종류가 있지만, ATProto에서 사용하는 DID는 두 가지가 있다.
did
did:web은 자신의 DID document를 .well-known/did.json 경로에 둔다. did:web:euroka.moe의 경우 https://euroka.moe/.well-known/did.json에 있는 것이다.
NOTE내 DID는
did:web을 쓰지 않는다! 예시용일 뿐이니 참고 바란다.
장점은,
- 탈중앙화에 더 가깝다.
DNS를 신뢰해야 한다는 문제가 있지만, 이건 뭐 어쩔 수 없지 않나. 공인되고 검증된 기관이 운영한다는 것에 기대는 게 그나마 나을 것이다.
- did가 직관적이다.
did:plc:qjua73d5eq537nio2sucdaj3와 did:web:euroka.moe 중 기억하기 쉬운 것을 고르라 하면 당연히 후자 아닌가?
하지만 단점이 상당하다.
- 도메인의
.well-known/did.json접근에만 의존한다.
도메인 만료, 호스팅 업체의 변덕, 레코드 작성 실수, 모든 것은 DID document의 제어권 유실로 이어진다.
그리고 DID document의 제어권 유실은 signing 키나 PDS 변경, 핸들(DID document의 alsoKnownAs 값) 등을 불가능하게 만든다.
HTTPS 인증서 주던 CA가 터졌다? 다른 CA에서 인증서 받아오기 전까진, DID document는 다른 사람들에게 보이지 않게 되고, DID document가 없으니 존재하지 않는 자가 된다. 게시글, 팔로우 기록, 등등. 이것들은 존재하지 않는 사람이 한 것으로 나온다.
did
did:plc는 제일 간결하고 탈중앙화는 아니지만 타협적인 방법이다. PLC Dictionary라는 중앙화된 원장에 저장한다. 그리고 이걸 REST API로 모두에게 공개한다. 감사 로그와 키 서명 검증을 통하여 투명성을 확보하지만, 그렇다고 완전히 염려가 없는 것은 아니다. 하지만, 이는 매우 큰 장점이 있다.
도메인의 사용처를 alsoKnownAs를 채우는 데만 쓰는 게 가능하다. PLC Directory가 망하지 않는 이상, 도메인이 털려도 PLC Directory는 털리지 않으니 원래 있던 recovery 키로 alsoKnownAs를 수정하면 그만이다.
이 장점 덕분에 절대 다수의 유저들은 did:plc를 사용한다.
DID의 검증
PDSls 서비스에서 DID document를 보기 쉽게 확인할 수 있다. 여기서 Identity 탭의 Aliases 항목을 보자.
이는 DID document의 alsoKnownAs를 알려주는 곳이다. DNS (TXT record) 항목에서 did:plc:qjua73d5eq537nio2sucdaj3가 적혀임을 알 수 있다.
DID document에서 did:plc:qjua...가 euroka.moe를 통제한다고 주장한다. 주장일 뿐이고, 인증되지 않았다. 이제 euroka.moe가 did:plc:qjua...를 통제한다고 주장하면 상호 통제 상태가 되고, 즉 같은 사람에게 제어받는다 생각할 수 있다.
핸들의 ${핸들}/.well-known/atproto-did 파일을 확인해서 검증할 수도 있지만, 이는 예시로 쓸 사용자가 없어 생략한다.