신뢰 당사자 패스키 엔드포인트를 위한 잘 알려진 URL

W3C 작업 초안,

이 문서에 대한 자세한 내용
이 버전:
https://www.w3.org/TR/2026/WD-passkey-endpoints-1-20260114/
최신 공개 버전:
https://www.w3.org/TR/passkey-endpoints/
편집자 초안:
https://w3c.github.io/webappsec-passkey-endpoints/
이전 버전:
이력:
https://www.w3.org/standards/history/passkey-endpoints-1/
피드백:
public-webappsec@w3.org 에 제목 줄 “[passkey-endpoints] … 메시지 주제 …”을 사용해 보내십시오(아카이브)
GitHub
편집자:
(Okta)
(Cisco)

초록

이 명세는 WebAuthn 신뢰 당사자(RP)가 자신의 생성, 관리, 그리고 기타 정보성 엔드포인트를 WebAuthn 클라이언트와 자격 증명 관리자에게 발견 가능하게 하기 위해 호스트할 수 있는 잘 알려진 URL을 정의한다.

이 문서의 상태

이 절은 이 문서가 공개된 시점의 상태를 설명한다. 현재 W3C 공개 문서와 이 기술 보고서의 최신 개정 목록은 W3C 기술 보고서 색인에서 찾을 수 있다.

이 문서는 Web Application Security Working GroupRecommendation 트랙을 사용하여 작업 초안으로 공개했다. 이 문서는 W3C Recommendation이 되는 것을 목표로 한다.

(아카이브된) 공개 메일링 리스트 public-webappsec@w3.org (지침 참조)가 이 명세의 논의에 권장된다. 이메일을 보낼 때에는 제목에 “passkey-endpoints”라는 텍스트를 넣어야 하며, 가능하면 다음과 같이 작성하는 것이 좋다: “[passkey-endpoints] …의견 요약…

작업 초안으로 공개되었다고 해서 W3C와 그 회원들이 이를 승인했다는 의미는 아니다. 이는 초안 문서이며, 언제든지 다른 문서로 갱신, 대체 또는 폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다.

이 문서는 Web Application Security Working Group이 작성했다.

이 문서는 W3C Patent Policy에 따라 운영되는 그룹이 작성했다. W3C는 이 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지하며, 해당 페이지에는 특허 공개 지침도 포함되어 있다. 어떤 개인이 자신이 보기에 Essential Claim(s)을 포함하는 특허를 실제로 알고 있는 경우, 그 개인은 W3C Patent Policy 6절에 따라 해당 정보를 공개해야 한다.

이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받는다.

1. 소개

이 절은 비규범적이다.

WebAuthn 신뢰 당사자(RP)는 현재 자신이 패스키를 지원한다는 것, 사용자가 해당 서비스를 위한 패스키를 만들 수 있는 위치, 그리고 해당 서비스를 위한 기존 패스키를 관리할 수 있는 위치를 프로그래밍 방식으로 알릴 방법이 없다. 패스키는 로그인 이외에도 서명과 암호화 같은 추가 기능에 사용할 수 있다. 패스키별 엔드포인트 집합을 정의하는 잘 알려진 URL을 제안함으로써, 이 명세는 WebAuthn 클라이언트와 자격 증명 관리자(인증자)가 사용자가 계정 설정과 도움말 페이지를 뒤져야 하는 대신 워크플로별 및 정보성 엔드포인트로 직접 연결할 수 있게 한다.

2. 기반 구조

이 명세는 Infra Standard에 의존한다. [INFRA]

이 명세는 Fetch, HTML, HTTP 및 URL 표준의 용어를 사용한다. [FETCH] [HTML] [HTTP-SEMANTICS] [URL]

3. 패스키 엔드포인트 URL

패스키 지원을 알리고/또는 패스키 생성과 관리를 위한 직접 엔드포인트를 제공하기 위해, 신뢰 당사자[WELL-KNOWN]에 따라 https 스킴신뢰 당사자 식별자에 문자열 .well-known/passkey-endpoints를 연결하여 형성한 경로에 JSON 문서를 호스트해야 한다. 리다이렉트는 반환되어서는 안 된다.

RP ID "example.com"에 대한 패스키 엔드포인트 URL은 "https://example.com/.well-known/passkey-endpoints"이다.

3.1. 서버 응답

이 문맥에서 서버는 WebAuthn 신뢰 당사자(RP)로, 패스키를 지원한다.

성공 응답은 200 OK HTTP 상태 코드를 사용하고 application/json 콘텐츠 유형을 사용하여 JSON 객체를 반환해야 한다.

반환된 JSON 객체는 아래에 정의된 멤버 중 어느 것이든 포함할 수 있다.

enroll

이 OPTIONAL 멤버는 사용자 계정의 패스키 생성 페이지로 가는 직접 URL을 포함한다

manage

이 OPTIONAL 멤버는 사용자 계정의 패스키 관리 페이지로 가는 직접 URL을 포함한다

prfUsageDetails

이 OPTIONAL 멤버는 RP가 WebAuthn Pseudo-Random Function Extension(PRF)을 어떻게 사용하는지 설명하는 정보성 페이지의 URL을 포함한다.

HTTP/1.1 200 OK
Content-Type: application/json

{
   "enroll": "https://example.com/account/manage/passkeys/create",
   "manage": "https://example.com/account/manage/passkeys",
   "prfUsageDetails": "https://example.com/help/passkeys#encryption"
}

빈 JSON 객체를 반환하여 패스키 지원을 신호할 수 있지만, 특정 엔드포인트를 알리지는 않는다.

HTTP/1.1 200 OK
Content-Type: application/json

{}

3.2. 클라이언트 처리

이 문맥에서 클라이언트는 WebAuthn WebAuthn 클라이언트 또는 자격 증명 관리자(인증자)일 수 있다.

패스키의 신뢰 당사자 식별자가 주어졌을 때, 다음 단계를 실행하여 패스키 엔드포인트 URL을 생성한다:

  1. url을 다음과 같이 값이 설정된 새 URL이라고 하자:

    스킴

    "https"

    호스트

    패스키의 신뢰 당사자 식별자

    포트

    null

    경로

    « ".well-known", "passkey-endpoints" ».

  2. url을 반환한다.

RP ID "example.com"에 대한 패스키 엔드포인트 URL은 "https://example.com/.well-known/passkey-endpoints"이다.

4. WebAuthn 클라이언트와 자격 증명 관리자에 의한 사용

이 절은 비규범적이다.

enroll

패스키 등록은 일반적으로 RP의 비즈니스 로직과 세션 문맥에 의해 구동된다. 때로는 사용자가 비밀번호로 성공적으로 로그인한 뒤나 비밀번호 재설정 흐름을 거친 뒤 발생할 수 있고, 또 다른 경우에는 사용자가 전용 "패스키 생성" 페이지를 방문할 때 발생할 수 있다.

이러한 패스키 생성 진입점은 계정 설정이나 도움말 페이지 안에 묻혀 있는 경우가 많기 때문에 사용자가 찾기 어려울 수 있다.

이 멤버가 존재할 때의 사용 예:

manage

자격 증명 관리는 계정 설정 안에 묻혀 있는 경우가 많으며, 이는 사용자가 찾기 어려울 수 있다.

이 멤버가 존재할 때, 자격 증명 관리자는 RP의 패스키(또는 일반 자격 증명 관리) 페이지로 가는 직접 링크를 표시할 수 있다.

prfUsageDetails

일부 신뢰 당사자(RP)는 사용자 데이터를 서명하거나 암호화하기 위해 WebAuthn Pseudo-Random Function(PRF) Extension을 사용한다. 패스키는 주로 인증을 위해 설계되었기 때문에, 사용자는 PRF가 활성화된 패스키를 삭제하면 저장된 데이터나 다른 기능에 영향을 줄 수 있다는 사실을 알지 못할 수 있다.

PRF를 활용하는 RP는 자신의 패스키가 인증을 넘어 어떻게 사용되는지와 삭제의 영향을 자세히 설명하는 전용 정보성 페이지를 제공해야 한다. 이 페이지의 URL은 prfUsageDetails 키의 값이어야 한다.

이 멤버가 존재할 때, 자격 증명 관리자는 패스키 삭제 흐름 중에 RP의 정보성 페이지로 가는 링크를 포함하여 경고를 표시해야 한다.

5. IANA 고려사항

5.1. passkey-endpoints 잘 알려진 URI

이 문서는 ".well-known" URI passkey-endpoints를 정의한다. 이 등록은 [WELL-KNOWN]에 정의된 템플릿을 사용하여 검토, 승인 및 IANA 등록을 위해 IESG에 제출될 것이며, 그 내용은 다음과 같다:

URI suffix

passkey-endpoints

Change controller

W3C

Specification document(s)

이 문서가 관련 명세이다. (§ 3.1 서버 응답 참조)

Related information:

없음.

감사의 말

이 제안에 피드백을 제공해 준 Arnar Birgisson, Rew Islam, Adam Langley, René Léveillé, Matthew Miller, Ricky Mondello, Dan Veditz에게 감사한다.

적합성

문서 규약

적합성 요구사항은 설명적 단언과 RFC 2119 용어의 조합으로 표현된다. 이 문서의 규범적 부분에서 쓰인 핵심어 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”은 RFC 2119에 설명된 대로 해석되어야 한다. 다만 가독성을 위해, 이 명세에서는 이러한 단어들이 모두 대문자로 나타나지는 않는다.

이 명세의 모든 텍스트는 명시적으로 비규범적이라고 표시된 절, 예제 및 참고를 제외하고 규범적이다. [RFC2119]

이 명세의 예제는 “예를 들어”라는 말로 도입되거나 규범적 텍스트와 분리되어 class="example"으로 표시된다. 다음과 같다:

이는 정보성 예제의 예이다.

정보성 참고는 “참고”라는 단어로 시작하며 규범적 텍스트와 분리되어 class="note"로 표시된다. 다음과 같다:

참고, 이는 정보성 참고이다.

적합 알고리즘

알고리즘의 일부로 명령형으로 표현된 요구사항 (예: "모든 선행 공백 문자를 제거한다" 또는 "false를 반환하고 이 단계를 중단한다")은 알고리즘을 도입할 때 사용된 핵심어 ("must", "should", "may" 등)의 의미로 해석되어야 한다.

알고리즘이나 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등하기만 하다면, 어떤 방식으로든 구현될 수 있다. 특히 이 명세에 정의된 알고리즘은 이해하기 쉽도록 의도되었으며, 성능이 뛰어나도록 의도된 것은 아니다. 구현자는 최적화할 것을 권장한다.

색인

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTTP-SEMANTICS]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. HTTP Semantics. 2022년 6월. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBAUTHN-2]
Jeff Hodges; et al. Web Authentication: An API for accessing Public Key Credentials - Level 2. 2021년 4월 8일. REC. URL: https://www.w3.org/TR/webauthn-2/
[WEBAUTHN-3]
Tim Cappalli; et al. Web Authentication: An API for accessing Public Key Credentials - Level 3. 2025년 1월 27일. WD. URL: https://www.w3.org/TR/webauthn-3/
[WELL-KNOWN]
M. Nottingham. Well-Known Uniform Resource Identifiers (URIs). 2019년 5월. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615