자격 증명 관리 1단계

1. 소개

이 섹션은 규범적이지 않습니다.

웹사이트에 로그인하는 것은 있어야 할 때보다 더 어렵습니다. 사용자 에이전트는 여러 방식으로 경험을 개선할 수 있는 고유한 위치에 있으며, 대부분의 최신 사용자 에이전트는 브라우저에 일부 자격 증명 관리 기능을 네이티브로 제공함으로써 이를 인식해 왔습니다. 예를 들어 사용자들은 웹사이트의 사용자 이름과 비밀번호를 저장할 수 있습니다; 이러한 credentials은 이후 로그인 양식에 자동완성되지만, 성공률은 다양합니다.

코드(autocomplete) 속성은 선언적 메커니즘을 제공하여 웹사이트가 사용자 에이전트와 협력해 특정 필드를 "username" 또는 "password"로 표시함으로써 로그인 양식을 감지하고 채우는 능력을 향상시킬 수 있게 합니다. 사용자 에이전트는 마크업에 이러한 세부사항을 제공할 시간이 없었던 웹사이트와 함께 작동하기 위해 다양한 탐지 휴리스틱을 구현합니다.

이러한 휴리스틱과 선언적 탐지의 조합은 비교적 잘 작동하지만, 현 상태는 탐지가 문제인 큰 공백을 남깁니다. 자격 증명을 XMLHttpRequest를 통해 제출하는 것과 같은 드문 로그인 메커니즘을 사용하는 사이트는 신뢰성 있게 탐지하기 어렵고, 사용자가 연합 신원 제공자(federated identity provider)를 사용해 인증하기를 원하는 경우가 점점 흔해지는 상황도 마찬가지입니다. 웹사이트가 사용자 에이전트의 credential manager와 보다 직접적으로 상호작용할 수 있도록 허용하면, 한편으로는 credential manager의 정확도를 높일 수 있고, 다른 한편으로는 연합 로그인에서 사용자를 도울 수 있습니다.

이 사용 사례들은 § 1.1 Use Cases 및 Credential Management: Use Cases and Requirements에서 더 자세히 다룹니다; 이 명세는 웹사이트가 사용자의 credentials을 요청하고 사용자가 성공적으로 로그인했을 때 사용자 에이전트에게 자격 증명 저장을 요청할 수 있도록 하는 Credential Manager API를 정의함으로써 해당 문서가 제시한 많은 요구사항을 해결하려고 합니다.

참고: 여기서 정의한 API는 의도적으로 작고 단순합니다: 이것 자체로 인증을 제공하려는 것이 아니라, 기존 사용자 에이전트들이 구현한 기존 credential managers에 대한 인터페이스를 제공하는 것으로 제한됩니다. 그 기능은 벤더나 작성자 쪽의 큰 노력 없이도 지금 당장 가치가 있습니다. 물론 더 많은 것을 할 수 있는 여지는 분명히 있습니다. 지금은 보류한 몇 가지 생각은 § 9 Future Work를 참조하십시오; 이후 이 API의 반복에서 탐구될 수 있습니다.

1.1. 사용 사례

최신 사용자 에이전트는 일반적으로 사용자가 웹사이트에 로그인할 때 비밀번호를 저장할 수 있도록 하고, 사용자가 재방문할 때 로그인 폼에 비밀번호를 완전히 또는 부분적으로 자동으로 채워주는 기능을 제공합니다. 웹사이트 입장에서는 이러한 동작을 전혀 인지하지 못합니다: 비밀번호가 저장되었는지, 채워졌는지 알지 못합니다. 이는 장단점이 있습니다. 한편으로 사용자 에이전트의 비밀번호 관리자는 사이트 협조 여부와 관계없이 동작하므로 사용자에게 매우 좋습니다. 반면, 비밀번호 관리자의 동작은 로그인 폼, 비밀번호 변경 폼 등을 감지하고 채우기 위한 휴리스틱이 뒤섞인 불안정하고 독점적인 조합입니다.

현 상태에서 특히 문제되는 몇 가지가 있습니다:

• 사용자 에이전트는 연합 신원 제공자를 사용하는 사용자를 돕는 데 매우 어려움을 겪습니다. 사용자 이름/비밀번호 폼 제출 감지는 비교적 간단하지만, 제3자를 통한 로그인 감지는 신뢰성 있게 잘 수행하기 어렵습니다. 웹사이트가 전형적인 연합 로그인 동작에 수반되는 리디렉션의 의도를 사용자 에이전트에 알려줄 수 있다면 좋을 것입니다.

• 마찬가지로, 사용자 에이전트는 단순 사용자 이름/비밀번호 폼보다 더 특이한 로그인 메커니즘을 감지하는 데 어려움을 겪습니다. 저자들은 점점 더 XMLHttpRequest 또는 유사한 메커니즘을 통해 비동기적으로 사용자를 로그인시키며, 이는 경험을 개선하고 프레젠테이션을 더 많이 제어하기 위함입니다. 사용자를 위해 좋은 일이지만, 사용자 에이전트가 비밀번호 관리자를 통합하기에는 어렵습니다. 웹사이트가 자신이 사용하는 로그인 메커니즘을 사용자 에이전트가 이해하도록 도울 수 있다면 좋을 것입니다.

• 마지막으로, 비밀번호 변경은 웹사이트가 자격 증명이 변경되었음을 명시적으로 사용자 에이전트에 알렸다면 더 잘 지원될 수 있습니다.

2. 핵심 API

개발자 관점에서 자격 증명은 특정 동작의 인증 결정을 내릴 수 있게 하는 객체입니다. 이 섹션에서는 Credential 인터페이스를 기반 클래스로 하여, 이 문서 및 다른 문서에서 정의된 자격 증명을 위한 확장 가능한 API 집합과 navigator.credentials.* 를 통해 개발자가 자격 증명을 얻을 수 있도록 정의합니다.

여러 자격 증명 유형은 각각 JavaScript에서 상속을 통해, 직접 또는 간접적으로 Credential 인터페이스를 구현합니다. 이 문서에서는 PasswordCredential 및 FederatedCredential 두 가지 인터페이스를 정의합니다. 다른 명세(예: [WEBAUTHN])는 다른 자격 증명 유형을 정의합니다.

자격 증명은 특정 origin에 대해 유효하다고 합니다. 이는 해당 origin에서 인증으로 받아들여지는 경우를 의미합니다. 자격 증명이 특정 시점에 유효하더라도, 사용자 에이전트는 같은 자격 증명이 앞으로도 계속 유효할 것이라고 가정할 수 없습니다. 그 이유는 다음과 같습니다.

1. 비밀번호 자격 증명은 계정 소유자가 비밀번호를 변경하면 더 이상 유효하지 않을 수 있습니다.

2. SMS로 받은 토큰으로 만든 자격 증명은 한 번만 사용할 수 있을 가능성이 높습니다.

일회용 자격 증명은 자격 증명 소스에서 생성되며, 이는 개인키, 연합 계정 접근, 특정 전화번호로 SMS를 받을 수 있는 능력 등일 수 있습니다. 자격 증명 소스는 JavaScript에 노출되지 않으며, 이 명세에서 명시적으로 표현되지 않습니다. 모델을 통합하기 위해, 비밀번호 자체를 하나의 자격 증명 소스로 간주하며, 이는 비밀번호 자격 증명을 만들기 위해 단순히 복사됩니다.

UA는 유효한 자격 증명이 두 번째 사용에서도 유효할 것이라거나, 유효한 자격 증명을 생성한 자격 증명 소스가 앞으로도 유효한 자격 증명을 지속적으로 생성할 수 있으리라고 가정할 수 없지만, 후자가 전자보다 더 가능성이 높습니다. 과거에 유효했던 자격 증명을 (store() 를 통해) 기록함으로써, UA는 앞으로 사용자가 사용할 수 있는 유효한 자격 증명 소스를 더 잘 제공할 수 있게 됩니다.

2.1. 인프라스트럭처

A 자격 증명 관리자는 애플리케이션, 하드웨어 장치 또는 서비스로서 저장, 정리, 관리하고 선택할 수 있게 하는 자격 증명을 다룹니다. 예시 자격 증명 관리자에는 디지털 지갑, 비밀번호 관리자, 그리고 passkey 관리자가 포함됩니다.

사용자 에이전트는 내부적으로 자격 증명 저장소를 반드시 제공해야 하며, 이는 특정 벤더에 종속된 불투명한 저장 메커니즘으로 어떤 자격 증명이 유효한지를 기록합니다. 이는 자격 증명에 대한 접근과 지속성에 대해 다음과 같은 기능을 제공합니다:

1. 자격 증명 저장 — 나중에 검색할 수 있도록 자격 증명을 저장합니다. 이 기능은 자격 증명을 받아 자격 증명 저장소에 삽입합니다.

2. 자격 증명 목록 검색. 이 기능은 임의의 필터를 받아 필터와 일치하는 자격 증명 집합을 반환합니다.

3. 자격 증명 수정. 이 기능은 자격 증명을 받아 기존 자격 증명의 상태를 자격 증명 저장소에서 덮어씁니다。

또한, 자격 증명 저장소는 prevent silent access 플래그를 origin에 대해 유지해야 합니다(명시되지 않는 한 true로 설정됩니다). 플래그가 true로 설정된 origin은 사용자 중재가 필요함으로 간주됩니다。

참고: 사용자 중재의 중요성은 § 5 사용자 중재에서 더 자세히 논의됩니다。

참고: 자격 증명 저장소는 사용자 에이전트가 이 문서에서 지정한 API를 구현하는 내부 구현 세부사항이며 웹에 직접 노출되지 않습니다. 특정 자격 증명 유형을 지원하기 위해 다른 문서에서 더 많은 기능이 지정될 수 있습니다。

이 문서는 알고리즘과 문장에 사용되는 여러 기본 개념에 대해 Infra Standard에 의존합니다 [INFRA]。

각 environment settings object에는 연관된 활성 자격 증명 유형이 있으며, 이는 처음에는 비어 있는 집합입니다。

2.1.1. 인프라스트럭처 알고리즘

2.1.1.1. 상위와 동일 출처

environment settings object (settings)가 상위와 동일 출처인 경우, 다음 알고리즘이 true를 반환합니다:

1. settings의 관련 글로벌 객체에 연결된 Document가 없으면, false를 반환한다.

2. document를 settings의 관련 글로벌 객체의 연결된 Document로 한다.

3. document에 브라우징 컨텍스트가 없으면 false를 반환한다.

4. origin을 settings의 origin으로 한다.

5. navigable을 document의 node navigable로 한다.

6. navigable이 null이 아닌 parent를 가질 때 반복한다:

   1. navigable을 navigable의 parent로 설정한다.

   2. navigable의 active document의 origin이 origin과 동일 출처가 아니면, false를 반환한다.

7. true를 반환한다.

2.1.2. 자격 증명 유형 레지스트리

이 레지스트리는 자격 증명 유형 (예: [[type]] 값)을 해당 유형에 연관된 다양한 값에 매핑합니다. 예시: 옵션 멤버 식별자 (공식적으로 딕셔너리 멤버 식별자)로, CredentialCreationOptions 및 CredentialRequestOptions (즉, "options dictionaries")에서 명세됩니다.

참고: 이 레지스트리는 관련 자격 증명 인터페이스 객체 알고리즘에서 사용됩니다.

2.1.2.1. 등록 항목 요구사항 및 갱신 프로세스

• 각 자격 증명 유형은 자격 증명 유형 집합 내에서 반드시 유일해야 합니다.

• 각 레지스트리 항목은 딕셔너리 멤버 식별자(레지스트리에서는 옵션 멤버 식별자로 알려짐)를 명시해야 하며, 이는 CredentialCreationOptions 및 CredentialRequestOptions의 확장에서 사용됩니다.

• 각 레지스트리 항목은 적절한 인터페이스 객체 식별자를 해당 자격 증명 유형에 대해 명시해야 합니다.

• 각 레지스트리 항목은 Get Permissions Policy 권한을 명시해야 하며, 이는 자격 증명 요청 시 사용하거나, 명시되지 않은 경우 null로 설정합니다.

• 각 레지스트리 항목은 Create Permissions Policy 권한을 명시해야 하며, 이는 자격 증명 생성 시 사용하거나, 명시되지 않은 경우 null로 설정합니다.

• 각 레지스트리 항목에는 자격 증명 유형 및 딕셔너리 멤버 식별자를 정의하는 공개 명세에 대한 링크가 포함되어야 합니다.

• 각 레지스트리 항목의 명세에는 요청자 연락처 정보가 포함되어야 합니다.

이 레지스트리의 갱신은 자격 증명 유형의 항목 추가, 변경 또는 삭제입니다. 누구나 webappsec-credential-management 저장소에 풀 리퀘스트로 갱신 요청을 할 수 있습니다. 웹 애플리케이션 보안 작업 그룹에서 다가오는 회의 안건에 올리고 요청자에게 알립니다. 요청의 검토 및 결정은 W3C 웹 애플리케이션 보안 작업 그룹의 합의에 따릅니다. 의장이 결과를 요청자에게 알리고 레지스트리를 갱신합니다.

2.2. Credential 인터페이스

[Exposed=Window, SecureContext]
interface Credential {
  readonly attribute USVString id;
  readonly attribute DOMString type;
  static Promise<boolean> isConditionalMediationAvailable();
};

Tobie/Dominic에게 여기 및 § 2.5.1 자격 증명 요청(Request a Credential) 등에서 인터페이스 객체 관련 논의를 확인하세요. 용어가 정확한지 확신이 없습니다. 인터페이스 프로토타입 객체일 수도 있습니다.

일부 Credential 객체는 Origin Bound가 될 수 있습니다. 이러한 객체에는 [[origin]] 이라는 내부 슬롯이 존재하며, 이는 해당 origin을 저장합니다. 이 정보는 Credential이 효과적(Effective)으로 사용될 수 있는 origin입니다.

2.2.1. Credential 내부 메서드

Credential 인터페이스 객체는 여러 개의 내부 메서드를 지원하며, Credential 객체의 조회 및 저장을 돕습니다. 이 섹션에서 명시한 대로, 기본적으로 "no-op"(아무 작업도 하지 않음) 구현을 제공합니다.

별도 명시가 없는 한, Credential 을(를) 상속하는 인터페이스에 대해 생성되는 각 인터페이스 객체(interface object)는 적어도 하나 이상의 내부 메서드를 구현해야 하며, 각 자격 증명(credential) 타입에 적합하게 Credential의 기본 구현을 오버라이드해야 합니다. 예시로 § 3.2 PasswordCredential 인터페이스, § 4.1 FederatedCredential 인터페이스, 그리고 [WEBAUTHN]가 있습니다.

2.2.1.1. [[CollectFromCredentialStore]] 내부 메서드

Credential의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 기본 구현:

1. 빈 집합을 반환한다.

2.2.1.2. [[DiscoverFromExternalSource]] 내부 메서드

Credential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 기본 구현:

1. null을 반환한다.

2.2.1.3. [[Store]] 내부 메서드

Credential의 [[Store]](credential, sameOriginWithAncestors) 기본 구현:

1. NotSupportedError를 throw한다.

2.2.1.4. [[Create]] 내부 메서드

• Credential 을 생성하거나,

• 자격 증명을 생성하지 않고 null을 반환하거나,

• 예외 상황(예: 잘못된 옵션으로 TypeError 가 발생하는 경우) 에서 오류를 throw합니다.

Credential 을 생성할 때, global object 를 받아 interface object 를 반환하는 알고리즘을 리턴합니다. 이 알고리즘은 반드시 task에서 호출되어야 합니다.

참고: 이 알고리즘의 단계는 각 자격 증명 타입별로 정의되어 있습니다.

Credential의 [[Create]](origin, options, sameOriginWithAncestors) 기본 구현:

1. null을 반환한다.

2.2.2. CredentialUserData 믹스인

일부 Credential 객체에는 사용자에게 자격 증명 선택기에서 인간이 읽을 수 있는 구분(식별) 메커니즘을 제공하기 위해 친숙한 이름과 아이콘 정보를 포함합니다:

[SecureContext]
interface mixin CredentialUserData {
  readonly attribute USVString name;
  readonly attribute USVString iconURL;
};

2.3. navigator.credentials

개발자는 Credential을(를) 조회하고, 사용자 에이전트의 자격 증명 저장소와 상호작용합니다. 이 작업은 CredentialsContainer 인터페이스의 메서드를 통해 이루어지며, Navigator 객체의 navigator.credentials 속성으로 노출됩니다.

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute CredentialsContainer credentials;
};

credentials 속성은 반드시 활성 문서의 탐색 컨텍스트(browsing context)에 연결된 CredentialsContainer 객체를 반환해야 합니다.

참고: § 6.3 비보안 사이트에서 설명했듯이, 자격 증명 관리 API는 보안 컨텍스트(Secure Contexts)에서만 노출됩니다.

[Exposed=Window, SecureContext]
interface CredentialsContainer {
  Promise<Credential?> get(optional CredentialRequestOptions options = {});
  Promise<undefined> store(Credential credential);
  Promise<Credential?> create(optional CredentialCreationOptions options = {});
  Promise<undefined> preventSilentAccess();
};

dictionary CredentialData {
  required USVString id;
};

2.3.1. CredentialRequestOptions 딕셔너리

Credential 을(를) get() 메서드로 조회하려면, 호출자는 CredentialRequestOptions 객체에 몇 가지 매개변수를 지정합니다.

참고: CredentialRequestOptions 사전(dictionary)은 확장 포인트(extension point)입니다. 만약 옵션이 필요한 새로운 종류의 자격 증명이 도입될 경우, 해당 사전 타입이 이 dictionary에 추가되어 요청(request) 시 전달될 수 있습니다. 자세한 사항은 § 8.2 확장 포인트를 참고하세요.

dictionary CredentialRequestOptions {
  CredentialMediationRequirement mediation = "optional";
  DOMString uiMode;
  AbortSignal signal;
};

2.3.2. 중재 요구사항

get(options) 또는 create(options) 를 통해 요청할 때, 개발자는 적절한 CredentialMediationRequirement enum 값을 선택하여 사용자 중재 요구사항을 경우에 따라 지정할 수 있습니다.

참고: § 5 사용자 중재 절에서 전반적인 개념 및 각 origin 단위 요청 처리의 동작 영향에 관한 자세한 내용을 확인할 수 있습니다.

enum CredentialMediationRequirement {
  "silent",
  "optional",
  "conditional",
  "required"
};

2.3.3. UI 모드

get(options) 요청에서, 개발자는 적절한 CredentialUiMode enum 값을 선택하여 원하는 사용자 중재 모드를 지정할 수 있습니다.

UI 모드 필드는 기본값이 없습니다. 미지정 상태라면, [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드는 CredentialMediationRequirement 만으로 사용자 에이전트 동작을 결정해야 합니다.

참고: 이 필드는 호출자가 여러 종류의 사용자 중재 UI 방식 중 특정 방식을 구분해 지정할 수 있게 해줍니다. UI 노출 여부는 해당 요청의 CredentialMediationRequirement 값에 따라 결정됩니다. 모든 CredentialUiMode 값들이 CredentialMediationRequirement 값들과 항상 호환되는 것은 아니며, 실제 동작은 각 자격 증명 타입이 지원하는 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 메서드의 정의에 좌우됩니다.

enum CredentialUiMode {
  "immediate"
};

2.3.3.1. 예시

window.addEventListener('load', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'silent'
  });
  if (credentials) {
    // Hooray! Let’s sign the user in using these credentials!
  }
});

document.querySelector('#sign-in').addEventListener('click', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'optional'
  });
  if (credentials) {
    // Hooray! Let’s sign the user in using these credentials!
  }
});

document.querySelector('#important-form').addEventListener('submit', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (credentials) {
    // Verify that |credentials| enables access, and cancel the submission
    // if it doesn’t.
  } else {
    e.preventDefault();
  }
});

document.querySelector('#switch-button').addEventListener('click', e => {
  var c = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (c) {
    // Sign the user in using |c|.
  }
});

2.4. CredentialCreationOptions 딕셔너리

Credential 을(를) create() 를 통해 생성하려면, 호출자는 CredentialCreationOptions 객체에 몇 가지 매개변수를 지정합니다.

참고: CredentialCreationOptions 딕셔너리는 확장 포인트(extension point)입니다. 새로운 자격 증명 타입이 도입되면, 관련 옵션이 이 딕셔너리에 추가되어 생성 메서드에 전달할 수 있습니다. 자세한 내용은 § 8.2 확장 포인트와, 본 문서 예시: § 3.2 PasswordCredential 인터페이스, § 4.1 FederatedCredential 인터페이스를 참조하세요.

dictionary CredentialCreationOptions {
  CredentialMediationRequirement mediation = "optional";
  AbortSignal signal;
};

2.5. 알고리즘

2.5.1. Credential 요청

Credential 요청(Request a Credential) 알고리즘은 CredentialRequestOptions (options)을 받아, 자격 증명을 명확하게 획득할 수 있으면 해당 Credential로 resolve되는 Promise를 반환하고, 그렇지 않으면 null로 resolve합니다.

1. settings를 현재 설정 객체(current settings object)로 둔다.

2. assert: settings는 보안 컨텍스트(secure context)이다.

3. document를 settings의 관련 전역 객체(relevant global object)의 연결된 Document(associated Document)로 둔다.

4. 만약 document가 완전히 활성화(fully active) 상태가 아니면 a promise rejected with "InvalidStateError" DOMException을 반환한다.

5. options.signal 이 aborted라면, a promise rejected with options.signal의 abort reason을 반환한다.

6. interfaces를 options의 관련 자격 증명 인터페이스 객체(relevant credential interface objects)로 둔다.

7. 만약 interfaces가 비어 있음(empty)이라면, a promise rejected with "NotSupportedError" DOMException을 반환한다.

8. 각(for each) interface of interfaces에 대해:

   1. 만약 options.mediation 이 conditional 이고 interface가 conditional 사용자 중재(user mediation)를 지원하지 않으면, a promise rejected with "TypeError" DOMException을 반환한다.

   2. 만약 options.uiMode 이 immediate 이고 interface가 immediate 사용자 중재(user mediation)를 지원하지 않으면, a promise rejected with "TypeError" DOMException을 반환한다.

   3. 만약 settings의 active credential types에 interface의 [[type]] 이 포함(contain)되어 있으면, a promise rejected with "NotAllowedError" DOMException을 반환한다.

   4. Append(추가) interface의 [[type]]을 settings의 active credential types에 추가한다.

9. origin을 settings의 origin으로 둔다.

10. sameOriginWithAncestors를 settings가 조상과 동일 출처(same-origin with its ancestors)인 경우에만 true, 그 외는 false로 둔다.

11. options의 관련 자격 증명 인터페이스 객체(relevant credential interface objects) 각 interface에 대해:

    1. permission을 interface의 [[type]] Get Permissions Policy 결과로 둔다.

    2. permission이 null이면, continue.

    3. 만약 document가 allowed to use permission이 아니라면, a promise rejected with "NotAllowedError" DOMException을 반환한다.

12. p를 새 promise로 둔다.

13. 아래 단계를 병렬로(in parallel) 수행한다:

    1. credentials를 자격 증명 저장소에서 Credential 수집의 결과로 origin, options, sameOriginWithAncestors 를 인자로 구한다.

    2. credentials가 예외(exception)면 reject p에 credentials로 reject한다.

    3. 아래 모든 조건이 true이면 p를 credentials[0]으로 resolve하고 남은 단계를 skip한다:

       1. credentials의 크기(size)가 1임

       2. origin이 사용자 중재 필요하지 않음

       3. options가 사전 매칭(matchable a priori)임.

       4. options.mediation 이 "required"가 아님.

       5. options.mediation 이 "conditional"가 아님.

       이 모델이 적절하지 않을 수 있음. 사이트가 username/password와 webauthn 타입 모두를 지원할 때 username/password를 쓰는 사용자가 계속 로그인 상태를 유지할 수 있도록 선택기(chooser) 강제 없이 처리할 수 있게 개선하면 좋을 수 있음.

    4. 만약 options의 mediation 이 "silent"라면, resolve p에 null로 resolve하고 남은 단계는 skip한다.

    5. result를 사용자에게 Credential 선택 요청(ask the user to choose a Credential) 실행 결과로 options, credentials를 인자로 한다.

    6. result가 인터페이스 객체(interface object)라면:

       1. result를 result의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 실행 결과로 지정한다. (origin, options, sameOriginWithAncestors)

          이때 예외가 발생했다면:

          1. e를 throw된 예외(exception)로 둔다.

          2. 작업 큐(queue a task)에, global의 DOM 조작 태스크 소스(DOM manipulation task source) 를 이용해 아래 하위 단계를 실행하도록 예약한다:

             1. reject p에 e로 reject한다.

          3. 이 하위 단계를 종료한다.

    7. assert: result는 null 또는 Credential이다.

    8. result가 Credential이면, resolve p를 result로 resolve한다.

    9. result가 null이고 options.mediation 이 conditional 이 아니라면, resolve p를 result로 resolve한다.

       참고: options.mediation 이 conditional 이고 null 자격 증명 발견 시 promise p는 resolve되지 않는다.

14. p가 settle된 후 반응(react):

    1. interfaces의 각 interface에 대해:

       1. Remove(제거) interface의 [[type]] 을 settings의 active credential types에서 제거한다.

15. p를 반환한다.

2.5.2. 자격 증명 저장소에서 Credential 수집

origin (origin), CredentialRequestOptions (options), 그리고 호출 컨텍스트가 조상과 동일 출처(same-origin with its ancestors) (sameOriginWithAncestors)일 때만 true인 불린 값이 주어졌을 때, 사용자 에이전트는 자격 증명 저장소에서 Credential 수집 작업을 수행할 수 있으며, options의 필터에 부합하는 사용자 에이전트에 로컬 저장된 Credential 객체 집합을 반환한다. 해당하는 Credential 객체가 없다면, 반환 집합은 비어 있게 된다:

1. possible matches를 빈 집합으로 둔다.

2. options의 관련 자격 증명 인터페이스 객체의 각 interface에 대해:

   1. r에 interface의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 내부 메서드를 origin, options, sameOriginWithAncestors로 실행한 결과를 할당한다. 예외(exception)가 발생하면 해당 예외를 다시 throw한다.

   2. assert: r은(는) interface objects의 리스트여야 한다.

   3. r의 각 c에 대해서:

      1. append c를 possible matches에 추가한다.

3. possible matches를 반환한다.

2.5.3. Credential 저장

Credential 저장(Store a Credential) 알고리즘은 Credential (credential)을 받아, 자격 증명 저장소에 객체가 영구 저장(persist)되면 resolve되는 Promise를 반환한다.

1. settings를 현재 설정 객체(current settings object)로 둔다.

2. assert: settings는 보안 컨텍스트(secure context)이다.

3. 만약 settings의 관련 전역 객체(relevant global object)의 연결된 Document(associated Document)가 완전히 활성화(fully active) 상태가 아니라면, a promise rejected with "InvalidStateError" DOMException을 반환한다.

4. sameOriginWithAncestors를 현재 설정 객체(current settings object)가 조상과 동일 출처(same-origin with its ancestors)일 경우 true, 그 외에는 false로 둔다.

5. p를 새 promise로 둔다.

6. 만약 settings의 active credential types에 포함된 credential의 [[type]]이 있으면, a promise rejected with "NotAllowedError" DOMException을 반환한다.

7. Append(추가) credential의 [[type]]을 settings의 active credential types에 추가한다.

8. 아래 단계를 병렬로(in parallel) 실행한다:

   1. credential의 interface object의 [[Store]](credential, sameOriginWithAncestors) 내부 메서드를 credential, sameOriginWithAncestors 인자로 실행한다.

      이때 예외(exception)가 발생했다면:

      1. e를 throw된 예외(exception)로 둔다.

      2. 작업 큐(queue a task)를 global의 DOM 조작 태스크 소스(DOM manipulation task source) 로 실행하여 아래 하위 단계를 수행한다:

         1. reject p에 e로 reject한다.

      그 외의 경우 resolve p에 undefined로 resolve한다.

9. p가 settle된 후 반응(React):

   1. Remove(제거) credential의 [[type]] 을 settings의 active credential types에서 제거한다.

10. p를 반환한다.

2.5.4. Credential 생성

Credential 생성(Create a Credential) 알고리즘은 CredentialCreationOptions (options)을 받아, 주어진 옵션으로 자격 증명을 만들 수 있으면 Credential로 resolve되고, 만들 수 없으면 null로 resolve되는 Promise를 반환한다. 예외 상황에서는, Promise가 적절한 예외로 reject될 수 있다:

1. settings를 현재 설정 객체(current settings object)로 둔다.

2. assert: settings는 보안 컨텍스트(secure context)이다.

3. global을 settings의 글로벌 객체(global object)로 둔다.

4. document를 관련 전역 객체(relevant global object)의 연결된 Document(associated Document)로 둔다.

5. document가 완전히 활성화(fully active) 상태가 아니면, a promise rejected with "InvalidStateError" DOMException을 반환한다.

6. 조상과 동일 출처이면 sameOriginWithAncestors를 true, 아니면 false로 한다.

7. interfaces를 set(집합)으로서 options의 관련 자격 증명 인터페이스 객체를 담는다.

8. 아래 조건 중 하나라도 true면 a promise rejected with NotSupportedError를 반환한다:

   1. global에 연결된 Document(associated Document)가 없음.

   2. interfaces의 크기(size)가 1보다 큼.

      참고: 미래에는 이 제한을 완화하여 사용자 에이전트가 여러 자격 증명 타입 가운데 사용자가 하나를 고를 수 있도록 할 수 있음. 당장은 이 딕셔너리가 단일 entry만 갖게 하여 해당 use case는 보류.

9. interfaces의 각 interface마다:

   1. permission을 interface의 [[type]] Create Permissions Policy 값으로 둔다.

   2. permission이 null이면 다음 interface로 continue.

   3. document가 not allowed to use permission이면 a promise rejected with "NotAllowedError" DOMException 반환.

10. options.signal 이 aborted라면, a promise rejected with options.signal의 abort reason으로 반환.

11. type을 interfaces[0]의 [[type]]으로 둔다.

12. settings의 active credential types에 포함되어 있다면 a promise rejected with "NotAllowedError" DOMException을 반환.

13. Append(추가) type을 settings의 active credential types에 추가.

14. origin을 settings의 origin으로 둔다.

15. p를 새 promise로 둔다.

16. 아래 단계를 병렬로(in parallel) 실행:

    1. r을 interfaces[0]의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드 실행 결과로 둔다. (origin, options, sameOriginWithAncestors 인자 사용)

       이때 예외(exception)가 발생했다면:

       1. e를 throw된 예외로 둔다.

       2. 작업 큐(queue a task)에서 global의 DOM 조작 태스크 소스(DOM manipulation task source) 로 아래 하위 단계를 실행:

          1. reject p에 e로 reject.

       3. 하위 단계 종료.

    2. r이 Credential 또는 null이면, resolve p를 r로 resolve하고 하위 단계 종료.

    3. assert: r은 § 2.2.1.4 [[Create]] 내부 메서드에 정의된 알고리즘임.

    4. 작업 큐(queue a task)에서 global의 DOM 조작 태스크 소스(DOM manipulation task source)로 아래 하위 단계를 실행:

       1. Resolve p을 promise-calling r 결과(global 인자)로 resolve.

17. p가 settle된 후 반응(React):

    1. Remove(제거) type을 settings의 active credential types에서 제거.

18. p를 반환한다.

2.5.5. 암묵적 접근 방지

Silent Access 방지(Prevent Silent Access) 알고리즘은 environment settings object (settings)을 받아, prevent silent access 플래그가 자격 증명 저장소에 영구 저장되면 resolve되는 Promise 를 반환한다.

1. origin을 settings의 origin으로 둔다.

2. 만약 settings의 관련 전역 객체(relevant global object)의 연결된 Document(associated Document)가 완전히 활성화(fully active) 상태가 아니라면, a promise rejected with "InvalidStateError" DOMException을 반환한다.

3. p를 새 promise로 둔다.

4. 아래 단계를 병렬로(in parallel) 수행:

   1. 조용한 접근 방지 플래그(prevent silent access flag)를 자격 증명 저장소(credential store)에서 origin에 대해 설정한다.

   2. resolve p를 undefined로 resolve한다.

5. p를 반환한다.

3. 비밀번호 자격 증명

좋든 나쁘든 많은 웹사이트가 사용자 이름/비밀번호 쌍에 인증 메커니즘을 의존합니다. PasswordCredential 인터페이스는 이런 사용 사례를 지원하기 위한 자격 증명으로, 사용자 이름과 비밀번호를 저장하며, 사용자가 자격 증명 선택기에서 올바른 계정을 선택할 수 있도록 돕는 메타데이터도 함께 저장합니다.

3.1. 예시

3.1.1. 비밀번호 기반 로그인

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      // 사용자가 이 사이트에 자격 증명이 없거나,
      // 공유를 거절함. 여기서 기본 로그인 폼으로
      // 폴백되는 동작을 구현할 수 있습니다.
      return;
    }
    if (credential.type == 'password') {
      var form = new FormData();
      form.append('username_field', credential.id);
      form.append('password_field', credential.password);
      var opt = {
        method: 'POST',
        body: form,
        credentials: 'include'  // 쿠키도 함께 전송
      };
      fetch('https://example.com/loginEndpoint', opt)
        .then(function (response) {
          if (/* |response|가 로그인 성공이면 */) {
            // 이 credential이 실제로 사용되었음을 기록. 아래 참고.
            navigator.credentials.store(credential);
            // 사용자에게 로그인 성공 표시, 로그인된 UX로 전환 등 동작.
            // location.href = '/signed-in-experience'로 이동 등도 가능.
          } else {
            // 여기서 기본 로그인 폼 등으로 폴백
          }
        });
    }
  });

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      return; // 위와 동일...
    }
    if (credential.type === 'password') {
      document.querySelector('input[name=username_field]').value =
        credential.id;
      document.querySelector('input[name=password_field]').value =
        credential.password;
      document.getElementById('myform').submit();
    }
  });

참고: 사용자 에이전트가 표시하는 자격 증명 선택기는 현재 origin에 실제로 저장되어 있지 않은 자격 증명도 사용자가 선택할 수 있게 할 수 있습니다. 예를 들어, https://www.example.com에 로그인할 때 https://m.example.com에 저장된 자격 증명을 제시하거나(§ 6.1 교차 도메인 자격 증명 접근 참고), 새 자격 증명을 즉석에서 만들 수도 있습니다. 개발자는 store() 를 항상 호출(심지어 get() 직후라도) 해서 이 불확실성을 처리할 수 있습니다: 자격 증명이 해당 origin에 저장되어 있지 않다면 사용자가 직접 저장 결정을 하도록 안내받게 되며, 이미 저장되어 있다면 별도 안내 없이 처리됩니다.

3.1.2. 로그인 후 확인

사용자가 성공적으로 로그인한 후 새로운 자격 증명 저장을 권장하려면, store() 에 전달하면 됩니다.

<form action="https://example.com/login" method="POST" id="theForm">
  <label for="username">Username</label>
  <input type="text" id="username" name="username" autocomplete="username">
  <label for="password">Password</label>
  <input type="password" id="password" name="password" autocomplete="current-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
    if (window.PasswordCredential) {
      e.preventDefault();

      // "submit" 이벤트가 발생한 PasswordCredential을 HTMLFormElement에서 생성:
      // "username" 및 "current-password" autocomplete 필드 값을 자동으로 읽어들입니다:
      var c = new PasswordCredential(e.target);

      // 폼의 action URL로 새 자격 증명을 FormData로 전송. 응답이 성공적이면 사용자 에이전트에 알려, 사용자가 비밀번호를 저장할 수 있도록 합니다:
      var opt = {
        method: 'POST',
        body: new FormData(e.target),
        credentials: 'include'  // 쿠키 전송.
      };
      fetch(e.target.action, opt).then(r => {
        if (/* |r|이 "성공적인" Response인 경우 */)
          navigator.credentials.store(c);
      });
    }
});

3.1.3. 비밀번호 변경

동일한 저장 메커니즘은 "비밀번호 변경"에도 아무런 수정 없이 재사용할 수 있습니다. 사용자가 자격 증명을 변경하면, 웹사이트는 사용자가 새 자격 증명으로 성공적으로 로그인했음을 사용자 에이전트에 알릴 수 있습니다. 그러면 사용자 에이전트는 저장된 자격 증명을 업데이트할 수 있습니다:

<form action="https://example.com/changePassword" method="POST" id="theForm">
  <input type="hidden" name="username" autocomplete="username" value="user">
  <label for="password">New Password</label>
  <input type="password" id="password" name="password" autocomplete="new-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
  if (window.PasswordCredential) {
    e.preventDefault();

    // "submit" 이벤트가 발생한 PasswordCredential을 HTMLFormElement에서 생성:
    // "username" 및 "new-password" autocomplete 필드 값을 자동으로 읽어들입니다:
    var c = new PasswordCredential(e.target);

    // 폼의 action URL로 새 자격 증명을 FormData로 전송. 응답이 성공적이면 사용자 에이전트에 알려, 사용자가 비밀번호를 저장할 수 있도록 합니다:
    var opt = {
      method: 'POST',
      body: new FormData(e.target),
      credentials: 'include'  // 쿠키 전송.
    };
    fetch(e.target.action, opt).then(r => {
      if (/* |r|이 "성공적인" Response인 경우 */)
        navigator.credentials.store(c);
    });
  }
});

3.2. PasswordCredential 인터페이스

[Exposed=Window,
 SecureContext]
interface PasswordCredential : Credential {
  constructor(HTMLFormElement form);
  constructor(PasswordCredentialData data);
  readonly attribute USVString password;
};
PasswordCredential includes CredentialUserData;

partial dictionary CredentialRequestOptions {
  boolean password = false;
};

PasswordCredential 객체는 PasswordCredentialData 딕셔너리를 명시적으로 전달하거나, HTMLFormElement의 제출 가능한 요소를 기반으로 navigator.credentials.create()로 생성할 수 있습니다.

dictionary PasswordCredentialData : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString password;
};

typedef (PasswordCredentialData or HTMLFormElement) PasswordCredentialInit;

partial dictionary CredentialCreationOptions {
  PasswordCredentialInit password;
};

PasswordCredential 객체는 origin에 바인딩됩니다.

PasswordCredential의 인터페이스 객체는 Credential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 구현을 상속하며, [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), [[Create]](origin, options, sameOriginWithAncestors), [[Store]](credential, sameOriginWithAncestors)는 자체적으로 구현합니다.

3.3. 알고리즘

3.3.1. PasswordCredential의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 는 origin (origin), CredentialRequestOptions (options), 그리고 호출 컨텍스트가 조상과 동일 출처 (sameOriginWithAncestors)일 경우에만 true인 불리언 값을 인자로 호출됩니다. 알고리즘은 자격 증명 저장소에서 Credential 객체 집합을 반환합니다. 일치하는 Credential 객체가 없다면, 반환 집합은 비어 있습니다.

sameOriginWithAncestors가 true가 아니면 이 알고리즘은 NotAllowedError를 throw합니다.

1. assert: options["password"] 존재함.

2. sameOriginWithAncestors가 false이면 "NotAllowedError" DOMException을 throw한다.

   참고: 이 제한은 § 6.4 출처 혼동(Origin Confusion) 문제 보완을 목적합니다.

3. 만약 options["password"] 가 true가 아니면 빈 집합을 반환한다.

4. 자격 증명 저장소에서 아래와 같이 필터링하여 자격 증명 목록을 반환한다:

   1. 자격 증명이 PasswordCredential임

   2. 자격 증명의 [[origin]] 이 origin과 동일 출처인 경우

3.3.2. PasswordCredential의 [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) 는 origin (origin), CredentialCreationOptions (options), 그리고 호출 컨텍스트가 조상과 동일 출처 (sameOriginWithAncestors)인 경우에만 true인 불리언을 인자로 받습니다. 알고리즘은 생성 가능하다면 PasswordCredential 을 반환하고, 아니라면 null을 반환합니다. CredentialCreationOptions 딕셔너리에는 반드시 password 멤버가 있어야 하며, 이 값은 HTMLFormElement 또는 PasswordCredentialData여야 합니다. 만약 해당 멤버의 값을 사용해 PasswordCredential 을 만들 수 없다면, 이 알고리즘은 TypeError 예외(exception)를 throw합니다.

1. assert: options["password"] 존재해야 하며, sameOriginWithAncestors는 사용되지 않음.

2. options["password"] 이 HTMLFormElement이라면, HTMLFormElement에서 PasswordCredential 생성을 options["password"]와 origin을 인자로 실행하여 나온 결과 값을 반환. 예외 발생 시 그대로 rethrow.

3. options["password"] 가 PasswordCredentialData라면, PasswordCredentialData에서 PasswordCredential 생성을 options["password"]에 대해 실행하여, 결과 값을 반환한다. 예외 발생 시 그대로 rethrow.

4. TypeError 예외를 throw한다.

3.3.3. PasswordCredential의 [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) 는 PasswordCredential (credential)과, 호출 컨텍스트가 조상과 동일 출처 (sameOriginWithAncestors)일 때만 true인 불리언을 인자로 받습니다. 알고리즘은 credential이 자격 증명 저장소에 영구 저장(persist)되면 undefined를 반환합니다.

sameOriginWithAncestors가 true가 아니면, 이 알고리즘은 NotAllowedError를 반환합니다.

1. 만약 sameOriginWithAncestors가 false이면, 사용자 에이전트의 자격 증명 저장소를 변경하지 않고 "NotAllowedError" DOMException을 throw한다.

   참고: 이 제한은 § 6.4 출처 혼동(Origin Confusion) 문제 보완을 목적합니다.

2. 만약 사용자 에이전트의 자격 증명 저장소에 PasswordCredential (stored)가 존재하고, 이 id attribute가 credential의 id와 같으며, [[origin]] 슬롯 역시 credential의 [[origin]]과 동일 출처라면:

   1. 사용자가 자격 증명 업데이트 동의를 한 경우(사용자 중재에서 논의한 대로):

      1. stored의 password를 credential의 password로 설정한다.

      2. stored의 name을 credential의 name으로 설정한다.

      3. stored의 iconURL 을 credential의 iconURL으로 설정한다.

   그 외 사용자 저장 동의가 있을 경우(사용자 중재 참고):

   1. 자격 증명 저장소에 아래 속성으로 PasswordCredential 을(를) 저장한다:

      id

      credential의 id

      name,

      credential의 name

      iconURL

      credential의 iconURL

      [[origin]]

      credential의 [[origin]]

      password

      credential의 password

3.3.4. HTMLFormElement에서 PasswordCredential 생성

HTMLFormElement에서 PasswordCredential 생성 알고리즘은 HTMLFormElement (form)과 origin (origin)이 주어지면 다음 단계를 실행합니다.

참고: § 3.1.2 로그인 후 확인 및 § 3.1.3 비밀번호 변경에서 사용 예시를 제공합니다.

1. data를 새로운 PasswordCredentialData 딕셔너리로 한다.

2. data의 origin 멤버 값을 origin의 값으로 설정한다.

3. formData를 FormData 생성자로 form에 대해 실행한 결과로 한다.

4. elements를 form의 제출 가능한 요소 중 form owner가 form인 것의 리스트로, 트리 순서로 정렬한다.

5. newPasswordObserved를 false로 한다.

6. elements의 각 field에 대해 아래 단계를 실행:

   1. field에 autocomplete 속성이 없으면, 다음 field로 건너뛴다.

   2. name을 field의 name 속성 값으로 한다.

   3. formData의 has() 메서드를 name에 대해 실행했을 때 false면, 다음 field로 건너뛴다.

   4. field의 autocomplete 값에 하나 이상의 자동완성 상세 토큰(tokens)이 포함된다면:

      1. tokens의 각 token에 대해:

         1. token이 아래 문자열 중 하나와 ASCII 대소문자 구분 없이 일치한다면, 해당 절차를 실행:

            "new-password"

            data의 password 멤버 값을 formData의 get() 메서드를 name에 대해 실행한 결과로 설정하고, newPasswordObserved를 true로 설정한다.

            "current-password"

            newPasswordObserved가 false이면, data의 password 멤버 값을 formData의 get() 메서드를 name에 대해 실행한 결과로 설정.

            참고: newPasswordObserved가 false인 경우, new-password 필드가 current-password 필드보다 우선함을 의미합니다.

            "photo"

            data의 iconURL 멤버 값을 formData의 get() 메서드를 name에 대해 실행한 결과로 설정.

            "name"

            "nickname"

            data의 name 멤버 값을 formData의 get() 메서드를 name에 대해 실행한 결과로 설정.

            "username"

            data의 id 멤버 값을 formData의 get() 메서드를 name에 대해 실행한 결과로 설정.

7. c를 PasswordCredentialData에서 PasswordCredential 생성을 data에 대해 실행한 결과로 한다. 예외가 발생하면 재throw한다.

8. Assert: c는 PasswordCredential이다.

9. c를 반환한다.

3.3.5. PasswordCredentialData에서 PasswordCredential 생성

주어진 PasswordCredentialData (data)로부터 PasswordCredential 생성 알고리즘을 수행하려면 아래 단계를 따르십시오.

1. c를 새 PasswordCredential 객체로 둡니다.

2. 다음 중 어느 하나라도 빈 문자열이면 TypeError 예외를 throw합니다:

   • data의 id 멤버 값

   • data의 origin 멤버 값

   • data의 password 멤버 값

3. c의 프로퍼티를 다음과 같이 설정합니다:

   password

   data의 password 멤버 값

   id

   data의 id 멤버 값

   iconURL

   data의 iconURL 멤버 값

   name

   data의 name 멤버 값

   [[origin]]

   data의 origin 멤버 값

4. c를 반환합니다.

3.3.6. PasswordCredential에 대한 CredentialRequestOptions 매칭

CredentialRequestOptions (options)이 주어졌을 때, 다음 알고리즘은 PasswordCredential 이(가) get() 요청에 대해 응답으로 제공되어야 하면 "Matches"를, 그렇지 않으면 "Does Not Match"를 반환한다.

1. options에 password 멤버가 있고, 그 값이 true라면 "Matches"를 반환한다.

2. "Does Not Match"를 반환한다.

4. 연합 자격 증명

4.1. FederatedCredential 인터페이스

[Exposed=Window,
 SecureContext]
interface FederatedCredential : Credential {
  constructor(FederatedCredentialInit data);
  readonly attribute USVString provider;
  readonly attribute DOMString? protocol;
};
FederatedCredential includes CredentialUserData;

dictionary FederatedCredentialRequestOptions {
  sequence<USVString> providers;
  sequence<DOMString> protocols;
};

partial dictionary CredentialRequestOptions {
  FederatedCredentialRequestOptions federated;
};

FederatedCredential 객체는 FederatedCredentialInit 딕셔너리를 navigator.credentials.create() 에 전달함으로써 생성할 수 있습니다.

dictionary FederatedCredentialInit : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString provider;
  DOMString protocol;
};

partial dictionary CredentialCreationOptions {
  FederatedCredentialInit federated;
};

FederatedCredential 객체는 origin bound입니다.

FederatedCredential의 interface object는 Credential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 구현을 상속하며, [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), [[Create]](origin, options, sameOriginWithAncestors), [[Store]](credential, sameOriginWithAncestors) 를 자체적으로 구현합니다.

참고: 나중에 사용자 에이전트가 사용자를 대신해 인증 토큰을 획득하도록 지원할 경우, [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 구현에 의해 가능합니다.

4.1.1. 제공자 식별

모든 사이트는 특정 연합 신원 제공자를 참조할 때 동일한 식별자를 사용해야 합니다. 예를 들어, Facebook Login은 "Facebook", "Facebook Login", "FB", "FBL", "Facebook.com" 등 여러 이름이 아닌, 모두가 사용할 수 있는 표준 식별자를 가져야 합니다. 일관된 식별은 사용자 에이전트가 더 유용하게 동작할 수 있게 해줍니다.

일관성을 위해, 이 문서에서 정의된 API(예: FederatedCredentialRequestOptions의 providers 배열 또는 FederatedCredential의 provider 속성)에 전달되는 federation은 제공자가 로그인에 사용하는 origin의 ASCII serialization으로 식별되어야 합니다. 즉, Facebook은 https://www.facebook.com으로, Google은 https://accounts.google.com으로 표시됩니다.

이 origin의 serialization에는 마지막 U+002F SOLIDUS("/")가 포함되지 않지만, 사용자 에이전트는 이를 묵인해야 합니다: https://accounts.google.com/은 분명히 https://accounts.google.com과 동일합니다.

4.2. 알고리즘

4.2.1. FederatedCredential의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 는 origin (origin), CredentialRequestOptions (options), 그리고 호출 컨텍스트가 조상과 동일 출처 (sameOriginWithAncestors)일 때만 true가 되는 불린 값을 인자로 호출됩니다. 이 알고리즘은 자격 증명 저장소에서 Credential 객체 집합을 반환합니다. 일치하는 Credential 객체가 없다면 반환 집합은 비어 있습니다.

1. assert: options["federated"] 존재함.

2. sameOriginWithAncestors가 false이면 "NotAllowedError" DOMException을 throw 한다.

   참고: 이 제한은 § 6.4 출처 혼동 문제 해소를 목적으로 합니다.

3. options["federated"] 값이 true가 아니면 빈 집합을 반환한다.

4. 자격 증명 저장소에서 아래 조건으로 자격 증명 목록을 반환한다:

   1. 자격 증명은 FederatedCredential임

   2. 자격 증명의 [[origin]] 이 origin과 동일 출처임

   3. 만약 options["federated"]["providers"] 가 존재한다면, 해당 값이 자격 증명의 provider를 포함해야 한다.

   4. 만약 options["federated"]["protocols"] 가 존재한다면, 해당 값이 자격 증명의 protocol을 포함해야 한다.

4.2.2. FederatedCredential의 [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) 는 origin(origin), CredentialCreationOptions (options), 그리고 상위와 동일 origin(sameOriginWithAncestors)일 때 true인 boolean 값을 인자로 호출됩니다. 알고리즘은 생성 가능한 경우 FederatedCredential을 반환하며, 그렇지 않으면 null을 반환하거나, 예외 상황에서는 exception을 던집니다:

1. 단언: options["federated"] 존재함, 그리고 sameOriginWithAncestors는 사용되지 않음.

2. options["federated"]의 origin 멤버 값을 origin 값으로 설정합니다.

3. FederatedCredentialInit로부터 FederatedCredential 생성을 실행한 결과를 반환합니다. 예외가 발생하면 그 예외를 다시 던집니다.

4.2.3. FederatedCredential의 [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) 는 FederatedCredential (credential)과, 상위와 동일 origin(sameOriginWithAncestors)일 때 true인 boolean 값을 인자로 호출됩니다. 알고리즘은 credential이 credential store에 저장된 후 undefined를 반환합니다.

알고리즘은 sameOriginWithAncestors가 true가 아니면 NotAllowedError를 반환합니다.

1. "NotAllowedError" DOMException을 던지고, 사용자 에이전트의 credential store는 변경하지 않습니다. (sameOriginWithAncestors가 false인 경우)

   참고: 이 제한은 § 6.4 Origin 혼동에서 제기된 문제를 해결하기 위함입니다.

2. 사용자 에이전트의 credential store에 FederatedCredential이 있고, 그 id 속성이 credential의 id와 같고, [[origin]] 슬롯이 credential의 [[origin]]과 동일 origin이고, provider가 credential의 provider와 같으면 반환합니다.

3. 사용자가 자격 증명 저장 권한을 부여하면(user mediation 정의 참고), 다음 속성으로 credential store에 FederatedCredential을 저장합니다:

   id

   credential의 id

   name,

   credential의 name

   iconURL

   credential의 iconURL

   [[origin]]

   credential의 [[origin]]

   provider

   credential의 provider

   protocol

   credential의 protocol

4.2.4. FederatedCredentialInit로부터 FederatedCredential 생성

FederatedCredentialInit로부터 FederatedCredential 생성을 위해, FederatedCredentialInit (init)을 인자로 다음 단계를 수행합니다.

1. c에 새로운 FederatedCredential 객체를 할당합니다.

2. 아래 값 중 하나라도 빈 문자열이면 TypeError exception을 던집니다:

   • init.id의 값

   • init.provider의 값

3. c의 속성을 다음과 같이 설정합니다:

   id

   init.id의 값

   provider

   init.provider의 값

   iconURL

   init.iconURL의 값

   name

   init.name의 값

   [[origin]]

   init.origin의 값.

4. c를 반환합니다.

5. 사용자 중재

API를 통해 웹에 자격 증명 정보를 노출하는 것은 사용자 프라이버시에 여러 잠재적인 영향을 줄 수 있습니다. 그러므로 사용자 에이전트는 사용자가 무슨 일이 일어나고 있는지, 그리고 누구와 자격 증명이 공유되고 있는지 명확히 이해할 수 있도록 여러 상황에서 반드시 사용자를 개입시켜야(MUST) 합니다.

특정 동작이 사용자의 명시적 동의 후에 이루어지는 경우, 우리는 이를 사용자 중재(user mediated) 라고 부릅니다. 예를 들면 사용자가 자격 증명 선택기 인터페이스에서 직접 상호작용하여 동의를 표현할 수 있습니다. 일반적으로 사용자 중재 동작은 사용자가 UI를 접하고 그에 대한 결정을 내리도록 요구하는 과정을 포함합니다.

동작이 명시적 사용자 동의 없이 조용히(silently) 수행되는 경우, 이를 비중재(unmediated)라고 합니다. 예를 들어, 사용자가 브라우저 설정을 통해 특정 origin에 지속적으로 자격 증명 접근을 허용했다면, 자격 증명 제공 시 별도의 결정 요청 UI 없이 전달될 수 있습니다.

여기서는 모든 자격 증명 타입에 공통되는 일부 요구 사항을 명확히 기술합니다. 단, 사용자 에이전트가 사용자 보호 측면에서 다양한 재량을 가질 수 있음을 참고하세요 (사용자 에이전트는 사용자를 돕는 특권적 위치에 있음). 또한, 특정 자격 증명 타입은 여기서 설명하는 일반 요구 사항보다 더 엄격한 개별 요건을 가질 수 있습니다.

5.1. 자격 증명 저장 및 갱신

자격 증명 정보는 민감한 데이터이며, 사용자는 이 정보의 저장에 대한 통제권을 반드시(MUST) 가져야 합니다. 예를 들어, 의도치 않은 자격 증명 저장은 특정 디바이스의 사용자의 로컬 프로필을 온라인 페르소나와 예기치 않게 연결할 수 있습니다. 이런 불의의 위험을 줄이기 위해:

1. 자격 증명 정보는 사용자 중재 없이 저장되거나 갱신되어서는 안 됩니다(SHOULD NOT). 예를 들어, 사용자 에이전트는 store() 를 호출할 때마다 "이 자격 증명을 저장하시겠습니까?" 다이얼로그 박스를 표시할 수 있습니다.

   사용자가 "항상 비밀번호 저장" 옵션 등 영구 동의 권한을 직접 설정할 경우, 사용자 동의가 부여된 것으로 간주할 수 있습니다(MAY). (다만, 사용자 에이전트는 더 제한적인 범위로 — 예를 들면 "항상 _생성된_ 비밀번호 저장", 또는 "이 사이트에만 항상 비밀번호 저장" — 접근하는 것이 권장됨.)

2. 사용자 에이전트는 자격 증명이 저장될 때 사용자가 알 수 있도록 알림을 제공해야 합니다(SHOULD). 예를 들어, 주소창에 아이콘을 표시하거나 이와 유사한 위치에 노출할 수 있습니다.

3. 사용자 에이전트는 사용자가 저장된 자격 증명을 수동으로 삭제할 수 있도록 반드시(MUST) 허용해야 합니다. 이 기능은 설정 페이지나 위에서 말한 알림과의 상호작용 등으로 구현될 수 있습니다.

5.2. 사용자 중재 요구

기본적으로 사용자 중재가 모든 origin에 대해 요구됩니다. 이는 자격 증명 저장소에서 관련 silent access 방지 플래그 가 true로 설정되어 있기 때문입니다. 사용자는 어떤 origin에 대해 자격 증명 영구 접근 권한(예: "이 사이트에 계속 로그인" 옵션)을 부여할 수 있으며, 이 경우 플래그가 false로 전환됩니다. 이런 경우 사용자는 항상 해당 사이트에 로그인되어 있게 되므로, 사용성과 편의성 측면에서는 바람직하지만(다만, 예를 들어 에이전트가 이 플래그 상태를 기기 간 동기화한다면 사용자 입장에서 당황스러운 결과를 초래할 수도 있습니다).

이런 의도치 않은 상황의 위험을 줄이기 위하여:

1. 사용자 에이전트는 특정 origin 또는 모든 origin에 대해 사용자 중재를 반드시(MUST) 요구할 수 있어야 합니다. 이 기능은 모든 origin의 silent access 방지 플래그 를 false 로 덮는(override) 글로벌 토글로 구현할 수도 있고, 특정 origin 또는 특정 자격 증명별 세밀한 설정으로 제공될 수도 있습니다.

2. 사용자 에이전트는 origin의 silent access 방지 플래그 를 사용자 중재 없이 false로 설정해서는 안 됩니다(MUST NOT). 예를 들어 자격 증명 선택기 (§ 5.3 자격 증명 선택 참고)에 체크박스를 추가해 사용자가 해당 자격 증명을 origin에 대해 중재 없이 쓸 수 있도록 선택하게 하거나, 에이전트의 자격 증명 관리자 온보딩 과정에서 초기 설정을 물어보는 방식일 수 있습니다.

3. 사용자 에이전트는 자격 증명이 origin에 제공될 때 반드시(MUST) 사용자에게 알림을 제공해야 합니다. 예를 들어 주소창 아이콘 표시 등 다양한 형태로 구현할 수 있습니다.

4. 사용자가 특정 origin에 대한 브라우징 데이터(쿠키, localStorage 등)를 삭제할 경우, 에이전트는 해당 origin의 silent access 방지 플래그 를 true로 반드시(MUST) 설정해야 합니다.

5.3. 자격 증명 선택

사용자 중재(user mediation)가 요구되는 origin에서 get() 호출에 응답할 때, 사용자 에이전트는 자격 증명 정보 공유에 대한 사용자 동의를 반드시(MUST) 요청해야 합니다. 이는 사용자에게 해당 사이트에서 사용할 수 있는 자격 증명 목록을 보여주고, 사용자가 제공할 자격 증명을 선택하거나 요청 자체를 중단하도록 할 수 있는 자격 증명 선택기(credential chooser) 형태의 UI로 구현되어야 합니다(SHOULD).

선택기의 사용자 인터페이스는 웹사이트가 흉내낼 수 없는 구별 가능한 방식으로 반드시 구현되어야(SHOULD) 합니다. 예를 들어 진짜 선택기는 사용자 에이전트의 UI 일부와 겹친다든지 위조할 수 없는 방식이 될 수 있습니다.

선택기의 사용자 인터페이스에는 자격 증명을 요청하는 origin이 반드시(MUST) 표시되어야 합니다.

선택기 UI에는 해당 origin과 연관된 모든 Credential 객체가 포함되어야 합니다(SHOULD).

사용자 에이전트는 선택기의 효용을 높이기 위해 각 Credential 객체에 본 문서에서 규정하지 않은 추가 정보를 내부적으로 연결시킬 수 있습니다(MAY). 예를 들어, 파비콘 이미지를 표시해 아이덴티티 제공자를 쉽게 구분하게 할 수 있습니다. 단, 이러한 부가 정보는 반드시 웹에 직접 노출되어서는 안 됩니다(MUST).

선택기의 구체적인 동작 방식은 이 문서에서 정의하지 않으며, 사용자 에이전트는 인증 옵션에 대한 이해를 돕고 자격 증명 선택 과정을 안내하는 UI 실험을 권장합니다. 단, 선택기에 대한 인터페이스는 다음과 같습니다:

6. 보안 고려사항

다음 섹션은 다양한 보안 및 프라이버시 고려사항에 대한 가이드라인을 제시합니다. 개별 자격 증명 타입은 이 가이드라인보다 더 엄격하거나 느슨한 버전을 적용할 수 있습니다.

6.1. 도메인 간 자격 증명 접근

자격 증명은 민감한 정보이므로, 사용자 에이전트는 언제 자격 증명을 웹사이트에 안전하게 공유할 수 있는지 결정할 때 신중을 기해야 합니다. 가장 안전한 방법은 자격 증명을 저장된 정확한 origin에서만 공유하도록 제한하는 것이지만, 웹 환경에는 너무 제한적일 수 있습니다. 예를 들어 example.com과 admin.example.com 등 하위 도메인으로 기능을 분리하는 사이트의 경우가 있습니다.

사용자 불편과 자격 증명 보호 사이의 타협안으로, 사용자 에이전트는 다음과 같이 동작해야 합니다:

1. 보안 수준이 강등되는 scheme끼리(origin) 자격 증명을 공유해서는 안 됩니다(MUST NOT). 즉, http://example.com/에 저장된 자격 증명을 https://example.com/에서 사용할 수 있게 하는 것은 개발자가 보안 전송으로 마이그레이션할 수 있도록 허용할 수 있지만, 그 반대는 위험합니다.

2. 자격 증명의 유효 범위를 판단하기 위해 Public Suffix List [PSL]를 사용할 수 있습니다(MAY). 즉, 자격 증명의 등록 도메인(registerable domain)을 [[origin]] 및 get() 이 호출되는 origin에 대해 비교해서 범위를 결정할 수 있습니다. 예를 들어 https://admin.example.com/ 과 https://example.com/에 저장된 자격 증명을 https://www.example.com/에서 get() 호출 시 사용자에게 제공할 수 있으며, 그 반대 역시 허용될 수 있습니다.

3. 자격 증명의 origin이 호출 origin과 완전히 일치하지 않는 경우, 사용자 중재 없이 get() 에 자격 증명을 바로 제공해서는 안 됩니다(MUST NOT). 즉, Credential 객체가 https://example.com용일 때, https://www.example.com에 바로 반환해서는 안 되고 반드시 선택기(chooser) UI를 통해 사용자가 직접 선택할 수 있어야 제공됩니다.

6.2. 자격 증명 누출

개발자들은 교차 사이트 스크립팅 공격이 사용자의 계정에 대한 지속적인 접근으로 이어지는 위험을 완화하기 위해, 데이터를 전송할 수 있는 엔드포인트를 제한하는 적절한 콘텐츠 보안 정책(Content Security Policy, [CSP])을 설정하는 등의 예방 조치를 취하는 것이 바람직합니다. 특히, 개발자들은 페이지의 정책에 다음 지시어들이 명시적으로 또는 암묵적으로 설정되어 있는지 확인해야 합니다:

• script-src와 object-src 모두 페이지에서 스크립트 실행을 제한하여 교차 사이트 스크립팅 공격이 처음부터 성공할 가능성을 줄여줍니다. 사이트에서 form 요소를 사용한다면, form-action 지시어도 설정해야 합니다.

• connect-src는 fetch() 를 통해 데이터를 제출할 수 있는 origin을 제한합니다(이를 통해 자격 증명이 evil.com 등으로 유출되는 위험을 줄일 수 있습니다).

• child-src는 페이지에 포함될 수 있는 중첩 브라우징 컨텍스트를 제한하여 악의적인 postMessage() 대상이 주입되는 것을 더욱 어렵게 만듭니다. [HTML]

개발자는 입력 및 출력을 반드시 적절히 이스케이프 처리하고, 위험을 더욱 줄이기 위해 Subresource Integrity [SRI]와 같은 추가적인 방어 계층도 고려해야 합니다.

특정 자격 증명 타입을 정의할 때, 관련 자격 증명 타입은 자격 증명 데이터가 네트워크로 전송되는 방식에 충분히 주의를 기울여야 합니다. 예를 들어, 전송 메커니즘을 동일 origin의 엔드포인트로만 제한하도록 정의하는 것이 합리적일 수 있습니다.

6.3. 안전하지 않은 사이트

사용자 에이전트는 보안 컨텍스트가 아닌 환경에는 여기에서 정의된 API를 노출해서는 안 됩니다. 사용자 에이전트는 사용자 자격 증명을 저장하고 신뢰할 수 없는 URL에서 로그인 양식을 자동으로 채우는 기능을 구현할 수 있지만, 그러한 사이트는 자격 증명 관리자와 직접적으로 상호작용할 수 있는 신뢰할 수 있는 환경이 아니며, 해당 사이트는 보안 컨텍스트에 저장된 자격 증명에 접근할 수 없어야 합니다.

6.4. Origin 혼동

프레임된 페이지가 여기서 정의된 API에 접근할 수 있다면, 사용자가 최상위 탐색 컨텍스트가 아닌 다른 origin에 대한 자격 증명 접근을 허용하도록 혼란스럽게 만들 가능성이 있습니다. 사용자가 합리적으로 이해할 수 있는 유일한 보안 origin은 최상위 탐색 컨텍스트입니다.

이 문서는 Credential Management API를 해당 컨텍스트에 노출합니다. 일부 자격 증명 타입은 사용자 에이전트가 UI에 충분한 고려와 맥락을 담을 경우 쉽게 제공할 수 있을 것으로 보입니다.

그러나 특정 자격 증명 타입은 그러한 컨텍스트에서 위험 없이 노출하기 어렵습니다. 해당 자격 증명 타입은 [[Create]](origin, options, sameOriginWithAncestors), [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), 그리고 [[Store]](credential, sameOriginWithAncestors) 메서드에서 적절한 검사를 통해 제한됩니다.

예를 들어 PasswordCredential의 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 메서드는 Worker나 비-최상위 탐색 컨텍스트에서 호출되는 경우 즉시 빈 집합을 반환합니다.

6.5. 로그아웃

§ 5.2 사용자 중재 요구에서 논의된 바와 같이, 사용자가 자동 로그인 선택을 한 경우, 사용자 에이전트는 origin이 자격 증명을 요청할 때마다 이를 제공하게 됩니다. 웹사이트는 CredentialsContainer의 preventSilentAccess() 메서드를 호출하여 이 동작을 억제할 수 있으며, 이는 해당 origin의 자동 로그인을 비활성화합니다.

사용자 에이전트는 웹사이트가 올바르게 동작할 것이라 기대합니다. 부주의하거나 악의적인 웹사이트는 이 메서드를 호출하지 않아, 사용자 에이전트가 사용자의 의도와 달리 계속 자격 증명을 제공할 수 있습니다. 이는 사용자가 "로그아웃"을 클릭해도 사이트가 사용자 자격 증명을 지우지 않는 기존 상황보다 약간 더 나쁜 상황입니다. 사용자 에이전트가 인증에 관여하게 되기 때문입니다.

사용자는 반드시 이 동작을 제어할 수 있어야 합니다. § 5.2 사용자 중재 요구에서 언급한 바와 같이, origin의 쿠키를 삭제하면 해당 origin의 prevent silent access flag가 자격 증명 저장소에서 true로 초기화됩니다. 또한, 사용자 에이전트는 특정 origin에 대한 자동 로그인을 비활성화할 수 있는 UI 옵션도 제공해야 합니다. 예를 들어, 자격 증명이 origin에 제공되었을 때 표시되는 알림에 연동될 수 있습니다.

7. 프라이버시 고려사항

7.1. 타이밍 공격

사용자가 특정 origin에 자격 증명이 없는 경우 get() 호출은 매우 빠르게 완료됩니다. 악의적인 웹사이트는 자격 증명이 없는 사용자를, 자격 증명이 있지만 공유하지 않기로 선택한 사용자를 구별할 수 있습니다.

사용자 에이전트는 또한 자격 증명 요청을 속도 제한(rate-limit)해야 합니다. 짧은 시간에 여러 번 자격 증명 요청을 하는 것은 거의 확실히 악용에 해당합니다.

7.2. 선택기 정보 누출

만약 사용자 에이전트의 자격 증명 선택기가 origin이 제공한 이미지를 표시한다면 (예: Credential 에 사이트의 파비콘이 표시되는 경우), 이러한 이미지 요청은 반드시(MUST NOT) 선택기 표시 동작과 직접 연결되어서는 안 됩니다. 이렇게 하면 선택기 사용 정보가 누출되는 것을 방지할 수 있습니다. 한가지 방법은 Credential 저장 또는 갱신 시점에 이미지를 백그라운드로 받아 Credential 생명주기 동안 캐시하는 것입니다.

이러한 이미지는 반드시 다음 조건으로 페치되어야 합니다(MUST): credentials mode는 "omit", service-workers mode는 "none", client는 null, initiator는 빈 문자열, destination은 "subresource".

또한, 사용자 에이전트가 사용자가 자격 증명에 연결된 이름이나 아이콘을 변경할 수 있게 하는 경우, 데이터의 이런 변경 내용들은 웹사이트에 노출되어서는 안 됩니다(SHOULD NOT). (사용자가 하나의 origin에 대해 "내 가짜 계정" 과 "내 진짜 계정"처럼 두 자격 증명에 이름을 지정하는 경우 등을 고려)

7.3. 로컬 저장 데이터

이 API는 origin이 사용자의 프로필과 함께 데이터를 영구적으로 저장할 수 있는 기능을 제공합니다. 대부분의 사용자 에이전트는 자격 증명 데이터를 "브라우징 데이터"(쿠키 등)와 다르게 처리하기 때문에, 사용자가 쿠키를 지울 때 모든 흔적이 삭제된다고 생각할 수 있지만 실제로는 자격 증명 데이터가 남아 있을 수 있습니다.

사용자 에이전트는 origin에 대해 자격 증명 데이터가 저장되어 있음을 명확하게 보여주는 UI를 제공해야 하며, 사용자가 더 이상 해당 데이터를 유지하고 싶지 않을 때 쉽게 삭제할 수 있도록 해야 합니다.

9. 향후 작업

이 섹션은 규범적이지 않습니다.

여기에서 정의된 API는 사용자 에이전트의 자격 증명 관리자를 웹에 노출하는 데 최소한의 기능만을 제공하며, 웹이 자격 증명 관리자가 연합 신원 제공자(federated identity provider)가 사용 중임을 이해하는 데 도움을 줄 수 있게 합니다. 다음 단계는 [WEB-LOGIN]과 같은 문서(그리고 어느 정도는 Mozilla의 BrowserID [BROWSERID])에서 제시된 방향을 따르는 것이 될 것입니다.

사용자 에이전트는 사용자, 신원 제공자, 그리고 웹사이트 간의 관계를 효과적으로 중재할 수 있는 독특한 위치에 있습니다. 사용자 에이전트가 일반적인 인증 흐름에 수반되는 위험과 혼란을 일부 제거할 수 있다면, 사용자는 오늘날보다 훨씬 더 나은 위치에 있게 될 것입니다.

이 정보를 노출하는 자연스러운 방법은 FederatedCredential 인터페이스에 인증 토큰과 같은 속성을 추가하거나, 제공자가 지원하는 인증 타입을 선언하는 속성을 가진 매니페스트 형식을 추가하는 것일 수 있습니다.

여기서 설명하는 API는 사용자 상호작용이 필요한 사용 사례(아마도 자격 증명을 요청한 웹사이트가 아닌 다른 웹사이트와 함께)까지 지원할 수 있도록 충분히 확장 가능하게 설계되었습니다. Promise 기반 시스템이 여러 탐색 컨텍스트(예: idp.com에서 중재된 활동이 rp.com에 반환된 Promise를 해결하는 경우)나 디바이스 및 사용자 에이전트 간(예: [WEBAUTHN])의 일부 상호작용을 지원할 수 있을 만큼 충분히 확장 가능하기를 바랍니다. 이러한 흐름을 위해 API를 처음부터 다시 설계하지 않아도 되기를 희망합니다.

작은 한 걸음씩.