요약

  • WebFinger는 익숙한 계정 이름을 조회 요청으로 바꿨다. 2013년 RFC 7033에 따라 프로그램은 @ 뒤의 도메인에 있는 /.well-known/webfinger에 묻고 JSON 링크를 받는다. 이름은 앱 사이를 다니지만 주소록은 도메인이 보관한다.
  • 2015년 RFC 7565는 acct:를 접속 방식과 별개의 계정 식별자로 정의했다. 2024년 W3C 커뮤니티그룹 보고서는 같은 조회로 ActivityPub actor를 찾는 관행을 기술했다. 들고 다니기 쉬운 이름도 지정된 호스트가 답해야 작동한다.

이름은 쉬운데 주소는 제각각이었다

사람에게 ‘Carol은 example.com에 있다’고 말하면 대체로 알아듣는다. 프로그램에는 로그인 제공자나 프로필 문서의 URL이 필요하다. 어떤 사이트는 /carol, 다른 사이트는 /users/carol, 또 다른 사이트는 긴 불투명 식별자를 쓴다. 모든 앱이 서비스별 경로 규칙을 추측하는 일은 주소 찾기의 공통 해법이 될 수 없다.

2013년 9월에 나온 RFC 7033은 계정 도메인에 공통 문의 창구를 놓았다. 클라이언트는 example.com의 /.well-known/webfinger에 Carol의 example.com 계정을 가리키는 acct: 식별자을 부호화한 resource를 붙여 GET 요청을 보낸다. 응답은 주체, 가능한 별칭, 속성, 관계별 링크를 담은 JSON Resource Descriptor다. rel로 필요한 관계만 물을 수도 있다. RFC의 예는 Carol의 OpenID Connect 발행자를 찾는다. 프로그램은 이름을 보고 목적지를 만들어 내는 대신 도메인에 묻는다.

조용한 결정권이 그 응답에 있다. 도메인 운영자는 사람들이 부르는 이름을 그대로 두고 반환 링크를 바꿀 수 있다. 문의 창구가 답하지 않으면 다른 앱은 그 이름에 대한 WebFinger 답을 얻지 못한다. 표준은 질문 형식을 통일했을 뿐, 모든 도메인을 대신할 중앙 주소록을 만들지 않았다.

acct는 프로필 페이지가 아니다

2015년 5월의 RFC 7565은 acct:를 특정 상호작용 프로토콜과 독립적인 서비스 제공자의 계정 식별자로 정의했다. Carol의 example.com 계정을 가리키는 acct: 식별자 자체는 브라우저가 HTTP로 열 수 있는 Carol의 프로필 URL이 아니다. WebFinger가 이 식별자를 지정된 호스트로 향하는 질문으로 만들고, 호스트가 실제 웹 링크를 반환한다.

이 분리는 앱마다 다른 관계를 찾게 해 준다. 한 앱은 신원 제공자를, 다른 앱은 작성자나 프로필 정보를 찾는다. 첫 문의처는 늘 @ 뒤의 도메인이다. 이름 표기가 공통이라는 이유로 계정 사용자가 그 도메인의 운영권을 갖게 되지는 않는다. 현재의 연결표는 호스트 운영자가 관리한다.

2024년 W3C Social Web Incubator 커뮤니티그룹 최종 보고서는 ActivityPub에서 이 방식을 설명했다. user@domain을 acct: 자원으로 만들고 해당 도메인의 WebFinger에 물어 actor 문서의 HTTPS 링크를 받는다. 문서 경로는 서비스마다 달라도 된다. 보고서는 actor 문서에서 핸들로 돌아가는 역방향 확인도 다룬다. 이는 이후 사회적 웹 관행을 기록한 커뮤니티그룹 보고서이며 W3C 권고안은 아니다.

열린 주소록은 원치 않는 손님에게도 대답할 수 있다. RFC 7033은 조회만으로 계정의 존재를 알아내고 다른 정보를 묶어 주소 수집이나 피싱에 이용할 가능성을 지적했다. 접근 통제와 요청 횟수 제한도 논의했다. 실제 서비스에서는 답이 돌아온다는 사실뿐 아니라 어떤 별칭과 속성을 누구에게 내놓는지 확인해야 한다.

WebFinger는 앱이 사이트마다 다른 프로필 경로를 외우지 않아도 계정 관련 문서로 가는 길을 만들었다. 첫걸음부터 권한의 자리도 드러냈다. 이름에 적힌 도메인으로 가서 다음 주소를 물어야 한다. 핸들은 멀리 여행했다. 주소록은 호스트의 책상에 남았다.