Summary

  • 초안은 /.well-known/agent-capabilities에 에이전트용 흐름, 인가 서버, 호출 경로를 공개하도록 제안한다.
  • 공개된 어느 흐름에도 없는 작업은 닫힌다. 이전에 승인된 인가 인스턴스에 그 작업이 있어도 리소스 서버는 실행해서는 안 된다.

어제 받은 허가증을 든 에이전트가 오늘 서비스에 도착했다. 그런데 서비스가 공개한 작업 목록에서 그 일이 사라졌다. 새로운 IETF 초안은 현재 목록에 무게를 싣는다. 원본 서버의 JSON 문서가 작업 흐름과 인가 서버, 호출 지점을 알리고, 어느 흐름에도 적히지 않은 작업은 기본적으로 닫힌다. 리소스 서버는 이를 실행할 수 없으며 인가 서버도 그 작업을 담은 인스턴스를 거절해야 한다는 권고를 받는다. 오래된 승인 기록보다 현재의 공개 경계가 앞선다.

운영자가 작업을 철회할 때는 쓸모 있는 장치다. 그러나 초안 8.6절은 정적 콘텐츠 쓰기 권한을 가진 공격자의 선택지도 적었다. 그가 문서를 바꾸면 이후 원본을 찾는 에이전트를 자신이 정한 호출 경로로 보내거나 실제 흐름에서 멀어지게 할 수 있다. 앱 코드는 그대로여도 된다. 저자들은 이 파일을 앱 출시와 같은 변경 통제 아래 두라고 권한다. RFC 8615는 관리자가 .well-known 경로를 놓칠 수 있다고 이미 경고했다. 이제 그 경로에 실행 경계가 놓일 수 있다.

네이티브 앱은 오프라인 탐색을 위해 문서 복사본을 패키지에 넣을 수 있다. 하지만 초안에서는 이것이 캐시일 뿐이다. 세션의 첫 원격 작업 전에 연결된 원본 서버의 문서를 확인하고, 두 문서가 다르면 원본 쪽을 따라야 한다. 원본에서 빠진 작업은 낡은 설치 파일에 남아 있어도 실행할 수 없다. 앱 배포 기록과 실제 허용 범위가 다른 시간을 가리킬 수 있다는 뜻이다.

서비스 이름과 로고는 신원 증거가 아니다. 원본과 인증된 전달 경로가 연결의 근거다. OAuth 보호 리소스 메타데이터를 함께 공개한다면 두 곳의 인가 서버 목록도 일치해야 한다. IETF 기록상 아직 개인 초안이다. 실제로 문이 움직였는지는 특정 서비스의 파일 변경 내역과 서버의 실행·거절 기록이 있어야 알 수 있다.