auth.md — 에이전트가 사용자를 대신해 가입시키기 위한 오픈 프로토콜

• 각 서비스가 자기 도메인 루트에 호스팅하는 auth.md 파일 표준
• 에이전트에게 사용자를 대신해 등록하는 방법을 알려줘서, 별도의 회원가입 폼 없이 에이전트가 사용자를 등록 가능
• 파일에는 지원하는 flow, 존재하는 scope, 서비스 등록 방법이 포함
• 세 주체로 구성
  • agent: 사용자를 대신해 동작하는 주체
  • agent provider: 신원 어서션 ID-JAG를 발급하는 IdP
  • service: 어서션을 수용해 자격 증명을 발급하는 주체
• 에이전트는 auth.md를 가져와 지원되는 flow를 고른 뒤, verified identity assertion 제시 또는 사용자 대상 코드 확인 claim 수행
• 등록 방식은 마케팅상 두 가지로 소개되지만, 구현상으론 anonymous 포함 세 가지
  • Agent verified: 에이전트의 IdP가 사용자를 보증, 사람 개입 없음
  • User claimed: provider 불필요, 에이전트가 보여준 코드를 사용자가 로그인 후 확인. RFC 8628 스타일 claim ceremony(디바이스 플로우 방식) 사용
  • Anonymous Registration: 에이전트가 먼저 pre-claim scope로 동작하다가, 사용자가 소유권을 주장하면 post-claim 토큰으로 승격
  • 대부분의 앱은 두 방식 모두 지원, 에이전트가 상황에 맞게 선택
• 에이전트에게는 사용자에 묶인 scoped access token 발급, 수명 짧고 폐기 가능
• 표준 OAuth 위에서 발급되어 기존 API 인증 그대로 재사용
  • ID-JAG 발급 → RFC 7523 JWT-bearer grant로 access_token 교환, /.well-known/oauth-authorization-server 디스커버리로 동작
• WorkOS가 작성하지만 WorkOS 인프라에 종속되지 않는 오픈 프로토콜
  • 기존 OAuth 표준(Protected Resource Metadata, ID-JAG)을 조합해 계정 없이 게시·읽기 가능
• 앱/서비스는 어떤 flow를 받아들이고 어떤 자격 증명을 발급할지 직접 통제 가능
• 스펙뿐 아니라 agent provider·service 양측 샘플 구현과 skill manifest 역할의 AUTH.md 파일을 함께 제공해 실제로 돌려볼 수 있음
• Cloudflare, Firecrawl, Resend, monday.com 등 여러 서비스가 이미 도입했음
• MIT 라이선스

[bichi]

이건 왜 AUTH.md 가 아닐까 ?

[laeyoung]

Firecrawl, Resend의 auth.md.

Cloudflare는 프로토콜 소개 페이지 첫 적용 사례로 나오는데, 클릭해서 들어가보면 not found :(로 나오네요.