Skip to content

OAuth 2.0 Attestation-Based Client Authentication

Web Authorization Protocol                                     T. Looker
Internet-Draft                                                     MATTR
Intended status: Standards Track                              P. Bastian
Expires: 19 March 2026                                   Bundesdruckerei
                                                              C. Bormann
                                                                  SPRIND
                                                       15 September 2025

draft-ietf-oauth-attestation-based-client-auth-07

Abstract

本仕様は、[RFC6749] で定義される OAuth 2 プロトコルに対する拡張を定義する。これにより Client Instance は、Authorization Server または Resource Server とのやり取りにおいて、鍵に束縛されたアテステーションを含められる。この新しい方式により、従来は Public client と見なされてきたクライアント展開に関与する Client Instance でも、この鍵に束縛されたアテステーションを用いて認証できるようになる。

About This Document

この注記は RFC として公開する前に削除される。

本ドラフトの最新版は次にある。\ https://oauth-wg.github.io/draft-ietf-oauth-attestation-based-client-auth/draft-ietf-oauth-attestation-based-client-auth.html

本書のステータス情報は次で参照できる。\ https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

本書の議論は Web Authorization Protocol Working Group のメーリングリスト (mailto:oauth@ietf.org) で行われ、アーカイブは次にある。\ https://mailarchive.ietf.org/arch/browse/oauth/\ 購読は次から行う。\ https://www.ietf.org/mailman/listinfo/oauth/

本ドラフトのソースと issue tracker は次にある。\ https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出される。

Internet-Drafts は Internet Engineering Task Force (IETF) の作業文書である。なお、他のグループも作業文書を Internet-Draft として配布することがある。現行の Internet-Draft の一覧は次にある。\ https://datatracker.ietf.org/drafts/current/

Internet-Drafts は最大 6 か月間有効な草案文書であり、いつでも更新、差し替え、または他文書によって廃止され得る。Internet-Drafts を参照資料として用いたり、「作業中 (work in progress)」として以外に引用したりすることは不適切である。

この Internet-Draft は 19 March 2026 に失効する。

Copyright (c) 2025 IETF Trust および文書著者として識別された者。無断転載を禁ず。

本文書は、IETF Trust の IETF 文書に関する法的規定 (https://trustee.ietf.org/license-info) のうち、本書の公開日に有効な BCP 78 の対象である。これらの文書には本書に関する権利と制限が記載されているため、注意深く確認されたい。

本文書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記載された Revised BSD License の文言を含めなければならず、また Revised BSD License に記載のとおり無保証で提供される。

Table of Contents

1. Introduction

従来の OAuth セキュリティの概念では、Backend 経由のチャネルでクライアント認証を行う。[SD-JWT] で用いられる Issuer-Holder-Verifier モデルのようなエコシステムでは、このモデルはプライバシー上の懸念を生む。Backend が、どの Holder（すなわち Public client）がどの Issuer（すなわち Authorization Server）とやり取りしているかを識別でき、さらに発行される資格情報を把握し得るためである。本仕様は、これらの問題に対処するため、frontend 経由のチャネルで backend によるアテステーションに基づくクライアント認証の仕組みを確立する。

さらに本アプローチは、OAuth 2 の展開の状況が変化しており、Public client が安全かつ確実に認証できる能力の重要性が増していることを踏まえている。プラットフォームの仕組みを活用して Client Instance を検証する（例: mobile native apps）ことで、従来の OAuth クライアント認証方式では困難だった安全な認証が可能になる。本仕様で説明する共通フォーマットへ、こうしたプラットフォーム固有の仕組みを変換することで、この複雑さを抽象化し、Authorization Server 側の労力を最小化する。

本仕様の主目的は、クライアント backend がそれをアテステーションすることによって可能になる Client Instance の認証である。クライアント backend は、Client Instance のハードウェアおよびソフトウェアに関する追加の技術的特性についてもアテステーションできる。

次の図は、全体アーキテクチャとプロトコルフローを示す。

                  (3)
               +-------+
               |       |
               |      \ /
           +--------------------+
           |                    |
           |    Client Attester |
           |      (backend)     |
           |                    |
           +--------------------+
              / \      |
          (2)  |       |  (4)
               |      \ /
           +---------------+           +---------------+
    +----->|               |           |               |
(1) |      |    Client     |    (6)    | Authorization |
    |      |   Instance    |<--------->|    Server     |
    +------|               |           |               |
           +---------------+           +---------------+
              / \      |
               |       |
               +-------+
                  (5)

次の手順は、この OAuth フローを説明する。

  1. (1) Client Instance は、Client Attester に対して真正性を示すため、鍵（Client Instance Key）と、任意で追加のアテステーション（本仕様のスコープ外）を生成する。
  2. (2) Client Instance は、Client Attestation JWT の発行を求めて、このデータを Client Attester に送信する。
  3. (3) Client Attester は、Client Instance Key と任意の追加データを検証する。Client が生成した Client Instance Key に暗号学的に束縛された署名付き Client Attestation JWT を生成する。したがって、このアテステーションはこの特定の Client Instance に束縛される。
  4. (4) Client Attester は、Client Attestation JWT を送信して Client Instance に応答する。
  5. (5) Client Instance は、Client Instance Key により Proof of Possession (PoP) を生成する。
  6. (6) Client Instance は、Client Attestation JWT と Client Attestation PoP JWT の両方を、たとえば token リクエスト内で Authorization Server に送信する。Authorization Server は Client Attestation を検証し、これにより Client Instance を認証する。

手順 (2) と (4) のプロトコル詳細、特に Client Instance が Client Attester に対してどのように認証するかは、本仕様のスコープ外である。さらに本仕様は柔軟に設計されており、Client Attester として機能する backend をクライアントが持たないシナリオでも実装できる。その場合、各 Client Instance は、通常 Client Attester が担う機能を自ら実行する責任を負う。

2. Conventions and Definitions

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] で記述されるとおりに解釈される。

3. Terminology

  • Client Attestation JWT: Client Attester により生成される JSON Web Token (JWT)。Client Instance が管理する鍵に束縛され、その後インスタンスがクライアント認証に利用できる。
  • Client Attestation Proof of Possession (PoP) JWT: Client Attestation JWT が束縛されている鍵を用いて Client Instance が生成する Proof of Possession。
  • Client Instance: あるクライアントソフトウェアの、配備されたインスタンス。
  • Client Instance Key: Client Instance により生成される暗号学的な非対称鍵ペア。鍵ペアの公開鍵が Client Attester に提供される。この公開鍵は Client Attestation JWT 内にカプセル化され、Client Attestation Proof of Possession を署名するために用いられる。
  • Client Attester: Client Instance を認証し、Client Attestation JWT を発行することでアテステーションする主体。
  • Challenge: 暗号学的なチャレンジ・レスポンス・パターンへの入力となる String。OAuth では従来、nonce と呼ばれてきた。

4. Relation to RATS

[RFC9334] で定義される Remote Attestation Procedures (RATS) アーキテクチャには、本書と共通点がある。本仕様で規定するフローは、RATS における "Passport Model" に対応する。しかし、RATS のエコシステムが、RATS Attester が Verifier に対して自身を証明するための明示的な方式や値を与えるのに対し、Attestation-Based Client Authentication ではそれは意図的にスコープ外である。また、RATS と OAuth の用語は異なる。

  • RATS の "Attester" は OAuth の "Client" に対応する
  • RATS の "Relying Party" は OAuth の "Authorization Server or Resource Server" に対応する
  • RATS の "Verifier" は、本仕様で定義される "Client Attester" に対応する
  • RATS の "Attestion Result" は、本仕様で定義される "Client Attestation JWT" に対応する
  • RATS の "Endorser", "Reference Value Provider", "Endorsement", "Evidence" および "Policies and Reference Values" は本仕様のスコープ外である

5. Client Attestation Format

本ドラフトは、OAuth 2 プロトコルにおける client attestations の概念を導入し、2 つの JWT（Client Attestation と Client Attestation Proof of Possession (PoP)）を用いる。これらの JWT の主目的は Client Instance を認証することにある。これらの JWT は、Client Instance から Authorization Server または Resource Server への HTTP リクエストで HTTP headers を介して送信できる（Section 6.1 を参照）。また、OAuth2 ベースのやり取り以外での利用を可能にするため、連結シリアライズ（Section 7 を参照）でも送信できる。

5.1. Client Attestation JWT

Client Attestation は [RFC7519] に従い "JSON Web Token (JWT)" としてエンコードされなければならない (MUST)。

JWT Header

  • typ: REQUIRED. JWT type は oauth-client-attestation+jwt でなければならない (MUST)。

JWT Claims Set

  • iss: REQUIRED. iss (issuer) claim は、JWT を発行した主体の一意な識別子を含まなければならない (MUST)。別途指定しない application profile がない限り、準拠するアプリケーションは [RFC3986] の Section 6.2.1 で定義される Simple String Comparison により issuer 値を比較しなければならない (MUST)。
  • sub: REQUIRED. sub (subject) claim は OAuth Client の client_id 値を指定しなければならない (MUST)。
  • exp: REQUIRED. exp (expiration time) claim は、Client Attestation が発行者により失効と見なされる時刻を指定しなければならない (MUST)。Authorization Server は、システム間の許容されるクロックスキューを考慮しつつ、失効時刻を過ぎた JWT を拒否しなければならない (MUST)。
  • cnf: REQUIRED. cnf (confirmation) claim は、Authorization Server に対するクライアント認証のために、Client Instance が Client Attestation PoP JWT を生成する際に使用する鍵を、[RFC7800] に準拠して指定しなければならない (MUST)。鍵は "jwk" 表現で表さなければならない (MUST)。
  • iat: OPTIONAL. iat (issued at) claim は Client Attestation が発行された時刻を指定しなければならない (MUST)。
  • nbf: OPTIONAL. nbf (not before) claim は、Client Attestation がそれ以前には処理のため受理されてはならない (MUST NOT) 時刻を指定しなければならない (MUST)。

追加ルール

  1. JWT は他の claims を含んでもよい (MAY)。実装が理解できない claims は無視しなければならない (MUST)。
  2. JWT はデジタル署名されるか、Message Authentication Code (MAC) により完全性保護されなければならない (MUST)。Authorization Server は、署名または完全性保護の検証に失敗した場合、JWT を拒否しなければならない (MUST)。
  3. Authorization Server は、他のすべての点においても "JSON Web Token (JWT)" [RFC7519] に従って有効でない JWT を拒否しなければならない (MUST)。

例（デコード済み header と payload）

{
  "typ": "oauth-client-attestation+jwt",
  "alg": "ES256",
  "kid": "11"
}

{
  "iss": "https://attester.example.com",
  "sub": "https://client.example.com",
  "nbf": 1300815780,
  "exp": 1300819380,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "use": "sig",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    }
  }
}

5.2. Client Attestation PoP JWT

Client Attestation PoP は [RFC7519] に従い "JSON Web Token (JWT)" としてエンコードされなければならない (MUST)。

JWT Header

  • typ: REQUIRED. JWT type は oauth-client-attestation-pop+jwt でなければならない (MUST)。

JWT Claims Set

  • iss: REQUIRED. iss (issuer) claim は OAuth Client の client_id 値を指定しなければならない (MUST)。
  • aud: REQUIRED. aud (audience) claim は、意図された audience として Authorization Server を識別する値を指定しなければならない (MUST)。Authorization Server の [RFC8414] issuer identifier URL を、JWT の intended audience として Authorization Server を識別する "aud" 要素の値として用いなければならない (MUST)。
  • jti: REQUIRED. jti (JWT identifier) claim は、Client Attestation PoP の一意な識別子を指定しなければならない (MUST)。Authorization Server はリプレイ攻撃検出のために jti 値を利用できる（Section 12.1 を参照）。
  • iat: REQUIRED. iat (issued at) claim は、Client Attestation PoP が発行された時刻を指定しなければならない (MUST)。なお Authorization Server は、"iat" claim の値が不当に過去である JWT を拒否し得る。
  • challenge: OPTIONAL. challenge claim は、Authorization Server がクライアントに提供し、クライアントが Client Attestation PoP JWT に含めるための String 値を指定しなければならない (MUST)。
  • nbf: OPTIONAL. nbf (not before) claim は、Client Attestation PoP がそれ以前には処理のため受理されてはならない (MUST NOT) 時刻を指定しなければならない (MUST)。

追加ルール

  1. JWT は他の claims を含んでもよい (MAY)。実装が理解できない claims は無視しなければならない (MUST)。
  2. JWT は非対称暗号アルゴリズムを用いてデジタル署名されなければならない (MUST)。Authorization Server は署名が無効な JWT を拒否しなければならない (MUST)。
  3. JWT の検証に使用される公開鍵は、対応する Client Attestation JWT の "cnf" claim にある鍵でなければならない (MUST)。
  4. iss claim の値（client_id を表す）は、対応する Client Attestation JWT の sub claim の値と一致しなければならない (MUST)。
  5. Authorization Server は、他のすべての点においても "JSON Web Token (JWT)" [RFC7519] に従って有効でない JWT を拒否しなければならない (MUST)。

例（デコード済み header と payload）

{
  "typ": "oauth-client-attestation-pop+jwt",
  "alg": "ES256"
}

{
  "iss": "https://client.example.com",
  "aud": "https://as.example.com",
  "nbf": 1300815780,
  "jti": "d25d00ab-552b-46fc-ae19-98f440f25064",
  "challenge": "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4"
}

6. Client Attestation using a Header based syntax

本節では、HTTP headers を用いて HTTP リクエストで Client Attestation を提供する方法を定義する。

6.1. Client Attestation HTTP Headers

headers を用いて Client Attestation JWT と Client Attestation PoP JWT を Authorization Server に転送する場合、これらは次の HTTP headers を用いて HTTP リクエスト内で提供されなければならない (MUST)。

  • OAuth-Client-Attestation: Section 5.1 で定義した構造と構文に準拠する JWT
  • OAuth-Client-Attestation-PoP: Section 5.2 で定義した構造と構文に準拠する JWT

次は OAuth-Client-Attestation header の例である。

OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJpc3MiOiJodHRwczovL2F0dGV
zdGVyLmV4YW1wbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20i
LCJuYmYiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwiY25mIjp7Imp3ayI6eyJrd
HkiOiJFQyIsInVzZSI6InNpZyIsImNydiI6IlAtMjU2IiwieCI6IjE4d0hMZUlnVzl3Vk
42VkQxVHhncHF5MkxzellrTWY2SjhualZBaWJ2aE0iLCJ5IjoiLVY0ZFM0VWFMTWdQXzR
mWTRqOGlyN2NsMVRYbEZkQWdjeDU1bzdUa2NTQSJ9fX0.4bCswkgmUHw06kKdiS2KEySR
gjj73yCEIcrz3Mv7Bgns4Bm1tCQ9FAqMLtgzb5NthwJT9AhAEBogbiD5DtxV1g

次は OAuth-Client-Attestation-PoP header の例である。

OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJpc3MiOiJodHRwczovL2NsaWVudC5l
eGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJuYmYiOjEzM
DA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLW
FlMTktOThmNDQwZjI1MDY0Iiwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My0
1N2MwOTU3YzA5YzQifQ.rEa-dKJgRuD-aI-4bj4fDGH1up4jV--IgDMFdb9A5jSSWB7Uh
HfvLOVU_ZvAJfOWfO0MXyeunwzM3jGLB_TUkQ

[RFC9110] によれば header field name は大文字・小文字を区別しない。したがって OAUTH-CLIENT-ATTESTATION, oauth-client-attestation などはいずれも有効で等価な header field name である。ただし header field value では大文字・小文字は区別される。

OAuth-Client-Attestation および OAuth-Client-Attestation-PoP HTTP header field value は、[RFC9110] の Section 11.2 で定義される token68 構文を使用する（参照しやすいよう以下に再掲する）。

OAuth-Client-Attestation       = token68
OAuth-Client-Attestation-PoP   = token68
token68                        = 1*( ALPHA / DIGIT / "-" / "." /
                                     "_" / "~" / "+" / "/" ) *"="

Authorization Server は、Client Attestation PoP を検証する前に Client Attestation JWT を検証することが推奨される (RECOMMENDED)。

6.2. Validating HTTP requests featuring client attestations

client attestation headers を含む HTTP リクエストを検証するため、受信側サーバーは、受信した HTTP リクエストに関して次を保証しなければならない (MUST)。

  1. OAuth-Client-Attestation HTTP request header field がちょうど 1 つ存在し、その値は Section 5.1 で概説した構文に準拠する単一の正しい形式の JWT である。
  2. OAuth-Client-Attestation-PoP HTTP request header field がちょうど 1 つ存在し、その値は Section 5.2 で概説した構文に準拠する単一の正しい形式の JWT である。
  3. OAuth-Client-Attestation-PoP HTTP header から得られた Client Attestation PoP JWT の署名は、OAuth-Client-Attestation HTTP header から得られた Client Attestation JWT の cnf claim に含まれる Client Instance Key により検証できる。

client attestations の利用に特有の検証エラーが発生した場合、追加の error codes が次の用途のために定義される。すなわち、Authorization Server の認証済み endpoint の error responses（[RFC6749] Section 5.2 で定義）または Resource Server の error responses（[RFC6750] Section 3 で定義）である。

  • use_attestation_challenge MUST be used when the Client Attestation PoP JWT が期待される server-provided challenge を使用していない場合。使用する場合、この error code は OAuth-Client-Attestation-Challenge HTTP header field parameter（Section 8.1）を伴わなければならない (MUST)。
  • use_fresh_attestation MUST be used when the Client Attestation JWT が server により受理可能と見なされるには十分に新しくないと判断された場合。
  • invalid_client_attestation MAY be used：アテステーションまたはその Proof of Possession を成功裏に検証できなかった場合に、より一般的な invalid_client（[RFC6749]）に加えて使用してもよい。

上記に記述されていない状況によるエラーの場合、Authorization Server および Resource Server は、適切な Error Responses を返すべき場合の指針として [RFC6749] および [RFC6750]、またはそれぞれの拡張に従わなければならない (MUST)。

6.3. Client Attestation at the Token Endpoint

本ドラフトで定義される client attestation 機構は、さまざまな endpoints に対する多様な HTTP リクエストで使用できるが、[RFC6749] で定義される token リクエスト内での使用には、以下に示す追加の考慮事項がある。

Authorization Server は、本ドラフトで定義される client attestation 機構を使用している受信 access token リクエストについて、Section 6.2 で概説したすべてのチェックを実行しなければならない (MUST)。

token リクエストに [RFC6749] に従う client_id parameter が含まれる場合、Authorization Server は、この parameter の値が、Client Attestation の sub claim にある client_id 値および Client Attestation PoP の iss claim にある client_id 値と同一であることを検証しなければならない (MUST)。

次の例は、access token リクエストにおける client attestation 機構の使用を示す（表示の都合上、余分な改行を入れている）。

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJpc3MiOiJodHRwczovL2F0dGV
zdGVyLmV4YW1wbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20i
LCJuYmYiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwiY25mIjp7Imp3ayI6eyJrd
HkiOiJFQyIsInVzZSI6InNpZyIsImNydiI6IlAtMjU2IiwieCI6IjE4d0hMZUlnVzl3Vk
42VkQxVHhncHF5MkxzellrTWY2SjhualZBaWJ2aE0iLCJ5IjoiLVY0ZFM0VWFMTWdQXzR
mWTRqOGlyN2NsMVRYbEZkQWdjeDU1bzdUa2NTQSJ9fX0.4bCswkgmUHw06kKdiS2KEySR
gjj73yCEIcrz3Mv7Bgns4Bm1tCQ9FAqMLtgzb5NthwJT9AhAEBogbiD5DtxV1g
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJpc3MiOiJodHRwczovL2NsaWVudC5l
eGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJuYmYiOjEzM
DA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLW
FlMTktOThmNDQwZjI1MDY0Iiwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My0
1N2MwOTU3YzA5YzQifQ.rEa-dKJgRuD-aI-4bj4fDGH1up4jV--IgDMFdb9A5jSSWB7Uh
HfvLOVU_ZvAJfOWfO0MXyeunwzM3jGLB_TUkQ

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4

6.4. Client Attestation at the PAR Endpoint

Client Attestation は、[RFC9126] で定義される Pushed Authorization Request (PAR) endpoint で、[RFC7523] Section 2.2 で定義される JWT client assertion-based authentication のような代替のクライアント認証方式の代わりに使用できる。

Authorization Server は、本ドラフトで定義される client attestation 機構を使用している受信 PAR リクエストについて、Section 6.2 で概説したすべてのチェックを実行しなければならない (MUST)。

pushed authorization request に [RFC9126] に従う client_id parameter が含まれる場合、Authorization Server は、この parameter の値が、Client Attestation の sub claim にある client_id 値および Client Attestation PoP の iss claim にある client_id 値と同一であることを検証しなければならない (MUST)。

次の例は、PAR リクエストにおける client attestation 機構の使用を示す（表示の都合上、余分な改行を入れている）。

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJpc3MiOiJodHRwczovL2F0dGV
zdGVyLmV4YW1wbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20i
LCJuYmYiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwiY25mIjp7Imp3ayI6eyJrd
HkiOiJFQyIsInVzZSI6InNpZyIsImNydiI6IlAtMjU2IiwieCI6IjE4d0hMZUlnVzl3Vk
42VkQxVHhncHF5MkxzellrTWY2SjhualZBaWJ2aE0iLCJ5IjoiLVY0ZFM0VWFMTWdQXzR
mWTRqOGlyN2NsMVRYbEZkQWdjeDU1bzdUa2NTQSJ9fX0.4bCswkgmUHw06kKdiS2KEySR
gjj73yCEIcrz3Mv7Bgns4Bm1tCQ9FAqMLtgzb5NthwJT9AhAEBogbiD5DtxV1g
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJpc3MiOiJodHRwczovL2NsaWVudC5l
eGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJuYmYiOjEzM
DA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLW
FlMTktOThmNDQwZjI1MDY0Iiwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My0
1N2MwOTU3YzA5YzQifQ.rEa-dKJgRuD-aI-4bj4fDGH1up4jV--IgDMFdb9A5jSSWB7Uh
HfvLOVU_ZvAJfOWfO0MXyeunwzM3jGLB_TUkQ

response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information

7. Concatenated Serialization for Client Attestations

本仕様に従う Client Attestation は、header-based mechanism（Section 6.1 で導入）では基盤となるプロトコルに適合しない場合（例: Browser APIs への直接呼び出し）に備えて、代替表現として提示してもよい (MAY)。その場合、Client Attestation と Client Attestation PoP を連結したシリアライズを使用できる。

7.1. Concatenated Serialization Format

この表現は、チルダ (~) 文字で区切って Client Attestation と Client Attestation PoP を連結して作成する。

<Client Attestation>~<Client Attestation PoP>

この形式は [SD-JWT] Section 5 による SD-JWT+KB に似ているが、Disclosures を含まず、異なる typ values を用い、PoP に sd_hash claim を含めない。

この連結シリアライズ形式により、header-based アプローチが利用できない場合（例: direct Browser API call を使用する際にクライアントへの信頼を確立する）に、Client Attestation と Client Attestation PoP を提示できる。

次は、そのような連結シリアライズの例である（表示の都合上、余分な改行を入れている）。

eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24rand0IiwiYWxnIjoiRVMyNTYiL
CJraWQiOiIxMSJ9.eyJpc3MiOiJodHRwczovL2F0dGVzdGVyLmV4YW1wbGUuY29tIiwic
3ViIjoiaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20iLCJuYmYiOjEzMDA4MTU3ODAsIm
V4cCI6MTMwMDgxOTM4MCwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsInVzZSI6InNpZyI
sImNydiI6IlAtMjU2IiwieCI6IjE4d0hMZUlnVzl3Vk42VkQxVHhncHF5MkxzellrTWY2
SjhualZBaWJ2aE0iLCJ5IjoiLVY0ZFM0VWFMTWdQXzRmWTRqOGlyN2NsMVRYbEZkQWdje
DU1bzdUa2NTQSJ9fX0.4bCswkgmUHw06kKdiS2KEySRgjj73yCEIcrz3Mv7Bgns4Bm1tC
Q9FAqMLtgzb5NthwJT9AhAEBogbiD5DtxV1g~eyJhbGciOiJFUzI1NiIsInR5cCI6Im9h
dXRoLWNsaWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJpc3MiOiJodHRwczovL2Nsa
WVudC5leGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJuYm
YiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MCwianRpIjoiZDI1ZDAwYWItNTUyYi0
0NmZjLWFlMTktOThmNDQwZjI1MDY0Iiwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmIt
YWU3My01N2MwOTU3YzA5YzQifQ.rEa-dKJgRuD-aI-4bj4fDGH1up4jV--IgDMFdb9A5j
SSWB7UhHfvLOVU_ZvAJfOWfO0MXyeunwzM3jGLB_TUkQ

7.2. Validating the Concatenated Serialization

連結シリアライズ形式を用いて client attestation を検証するため、受信側サーバーは次を保証しなければならない (MUST)。

  1. ~ 文字より前に、Section 5.1 で概説した構文に準拠する単一の正しい形式の JWT がちょうど 1 つ存在する。
  2. ~ 文字より後に、Section 5.2 で概説した構文に準拠する単一の正しい形式の JWT がちょうど 1 つ存在する。
  3. ~ 文字より後に得られた Client Attestation PoP JWT の署名は、~ 文字より前に得られた Client Attestation JWT の cnf claim に含まれる Client Instance Key により検証できる。

8. Challenge Retrieval

本節では、Client が Authorization Server から新しい Challenge を要求し、それを Client Attestation PoP JWT に含めるための任意の仕組みを定義する。この構成要素は nonce と類似または等価であり得る（Section 3 を参照）。challenge の値はクライアントにとって不透明である。

Authorization Server は、本仕様の文脈において Client が Challenge を取得できる challenge endpoint を提供してもよい (MAY)。Authorization Server が [RFC8414] で定義される metadata をサポートする場合、challenge endpoint のサポートを、metadata entry challenge_endpoint に endpoint の URL を値として含めることで示さなければならない (MUST)。Authorization Server が challenge endpoint を提供する場合、Client は challenge を取得しなければならず (MUST)、Section 5.2 で定義される OAuth-Attestation-PoP にこの challenge を使用しなければならない (MUST)。

Challenge の要求は、Authorization Server metadata の challenge_endpoint parameter で提供される URL に対して HTTP POST リクエストを送信することで行う。

次は非規範的なリクエスト例である。

POST /as/challenge HTTP/1.1
Host: as.example.com
Accept: application/json

Authorization Server は、HTTP レスポンスで 200 ステータスコードとともに Challenge を提供し、application/json media type を用いて、HTTP レスポンスの message body に次の parameters を含める。

  • attestation_challenge: REQUIRED（authorization server が本書で記述される Client Attestations と server provided challenges をサポートする場合）。Section 5.2 で定義される OAuth-Attestation-PoP で使用する Challenge を含む String。ほかの状況でこの要素を必須としない意図は、challenge endpoint を client attestation と無関係な他アプリケーションでも利用できる余地を残すためである。

Authorization Server は、Cache-Control header field に no-store を含めて、レスポンスをキャッシュ不可にしなければならない (MUST)。Authorization Server は追加の challenges またはデータを付加してもよい (MAY)。

次は非規範的なレスポンス例である。

HTTP/1.1 200 OK
Host: as.example.com
Content-Type: application/json
Cache-Control: no-store

{
  "attestation_challenge": "AYjcyMzY3ZDhiNmJkNTZ"
}

8.1. Providing Challenges on Previous Responses

Authorization Server は、任意の HTTP レスポンスとともに、HTTP header-based syntax を用いて新しい Challenge を提供してもよい (MAY)。この HTTP header field parameter の名称は "OAuth-Client-Attestation-Challenge" でなければならず (MUST)、Challenge の値を含む。Client は、この新しい Challenge を次の OAuth-Client-Attestation-PoP に使用しなければならない (MUST)。

次は、新しい Challenge を含む Authorization Response の非規範的な例である。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600
}

9. Verification and Processing

Client Attestation を受領した場合、受信側サーバーは次の条件とルールを保証しなければならない (MUST)。

  1. Client Attestation が Header based Syntax（Section 6）で受領された場合:

    • HTTP リクエストは、OAuth-Client-Attestation フィールドと OAuth-Client-Attestation-PoP フィールドをそれぞれ正確に 1 つ含む。
    • 両フィールドは、それぞれ正確に 1 つの正しい形式の JWT を含む。

  2. Client Attestation JWT は、Section 5.1 に従うすべての claims と header parameters を含む。

  3. Client Attestation PoP JWT は、Section 5.2 に従うすべての claims と header parameters を含む。
  4. 両 JWT の alg JOSE Header Parameter は、登録済みの非対称デジタル署名アルゴリズム [IANA.JOSE.ALGS] を示し、none ではなく、アプリケーションがサポートし、ローカルポリシーとして受理可能である。
  5. Client Attestation JWT の署名は、既知かつ信頼された Attester の公開鍵で検証できる。
  6. Client Attestation JWT の cnf claim に含まれる鍵は秘密鍵ではない。
  7. Client Attestation PoP JWT の署名は、Client Attestation JWT の cnf claim に含まれる公開鍵で検証できる。
  8. サーバーがクライアントに challenge 値を提供した場合、Client Attestation PoP JWT に challenge claim が存在し、サーバー提供の challenge 値と一致する。
  9. Client Attestation PoP JWT の作成時刻は、iat claim、または challenge claim によるサーバー管理タイムスタンプのいずれかで判定され、許容可能なウィンドウ内にある。
  10. Client Attestation PoP JWT の aud claim は、[RFC8414] で記述される Authorization Server の issuer identifier URL である。
  11. Client Attestation JWT は、iat または exp claims の確認により、Authorization Server のポリシーにとって十分に新しい。
  12. 展開のセキュリティ要件に応じて、Client Attestation PoP JWT のリプレイ保護を保証する追加チェックが必要になり得る（詳細は Section 12.1）。
  13. Client Attestation を含むリクエストに client_id が提供されている場合、この client_id は Client Attestation JWT の sub claim および Client Attestation PoP JWT の iss claim と一致する。

10. Implementation Considerations

10.1. Authorization Server Metadata

Authorization Server は、公開 metadata の token_endpoint_auth_methods_supported に値 attest_jwt_client_auth を含めることで、Attestation-Based Client Authentication による認証のサポートおよび要件を伝えるべきである (SHOULD)。client は Authorization Server metadata を取得して解析し、当該 parameters が存在する場合、Attestation-Based Client Authentication をクライアント認証方式として認識すべきである (SHOULD)。

Authorization Server は、公開 metadata の client_attestation_signing_alg_values_supported および client_attestation_pop_signing_alg_values_supported を用いて、client attestations でサポートされるアルゴリズムを伝えるべきである (SHOULD)。これにより client は、認証に先立って、Authorization Server が当該 client attestation を理解できることを検証できる。client は、異なるアルゴリズムで新しい client attestation を取得しようとしてもよい (MAY)。

Authorization Server は、token_endpoint_auth_methods_supported に attest_jwt_client_auth が含まれる場合、公開 metadata に client_attestation_signing_alg_values_supported と client_attestation_pop_signing_alg_values_supported を含めなければならない (MUST)。

10.2. Reuse of a Client Attestation JWT

実装者は、この認証方式の設計が、Client Instance が単一の Client Attestation JWT を Authorization Server との複数のやり取り／リクエストで再利用しつつ、新しい Client Attestation PoP JWT を生成できるように意図的にしている点を認識すべきである。クライアントの展開では、発行する Client Attestation JWT の有効期間を決める際にこれを考慮すべきである。というのも、これが最終的に、Client Instance が単一の Client Attestation JWT をどれだけの期間再利用できるかを制御するためである。

10.3. Refresh token binding

client attestation 機構を用いた token リクエストに応答して refresh token を発行する Authorization Server は、その refresh token を、[RFC6749] の Section 6 で規定されるような「client のみ」ではなく、Client Instance およびそれに関連付く公開鍵へ束縛しなければならない (MUST)。この束縛を示すため、Client Instance は access token を更新する際に client attestation 機構を使用しなければならない (MUST)。また client は、refresh token が発行された際に使用した client attestation の "cnf" claim に存在した同一の鍵を使用しなければならない (MUST)。

10.4. Web Server Default Maximum HTTP Header Sizes

Client Attestation と Client Attestation PoP は HTTP headers を用いて伝達されるため、実装者は、Web server に設定されているデフォルトの最大 HTTP header サイズが小さすぎて、HTTP リクエストで Client Attestation および／または Client Attestation PoP を運べない可能性を考慮すべきである。なお、この制限は HTTP [RFC9112] で与えられるものではなく、Web server 実装が一般に HTTP headers の最大サイズをデフォルト設定することが多い。2024 年時点では、現代的な Web server での典型的なデフォルト上限は 8 kB 以上である。

10.5. Rotation of Client Instance Key

本仕様は、Client Attestation JWT の "cnf" claim にある Client Instance Key をローテーションする仕組みを提供しない。Client Instance が何らかの理由で新しい Client Instance Key を使用する必要がある場合、Client Attester から新しい Client Attestation JWT を要求しなければならない (MUST)。

10.6. Replay Attack Detection

Section 12.1 で述べるリプレイ攻撃検出の対策を実装する Authorization Server では、取引量が多いユースケースにおいて大量の challenges を管理するため、効率的なデータ構造が必要となる。データ構造のサイズを制限するため、Authorization Server はスライディングウィンドウを用いるべきである (SHOULD)。これにより、一定の時間ウィンドウ内の Client Attestation PoP を許容し、既出の challenge または jti 値を保存しておき、時間経過後に破棄する。安全性を確保するため、この時間ウィンドウ外の Client Attestation PoP は Authorization Server により拒否されなければならない (MUST)。

許容されるウィンドウは、Client Attestation PoP の iat と、Authorization Server が選択したスライディングウィンドウの時間長によって決まる。これらのデータ構造には次が必要となる。

  • Client Attestation PoP の challenge が過去に観測されたかどうかを検証するために、データ構造を検索する
  • 検索結果が見つからなかった場合、新しい challenge をデータ構造へ挿入する
  • Client Attestation PoP がスライディングウィンドウを過ぎた後、challenge を削除する

この仕組みを実装するデータ構造として、trie（prefix tree とも呼ばれる）、または patricia trie（radix tree とも呼ばれる）が推奨される (RECOMMENDED)。

11. Privacy Considerations

11.1. Client Instance Tracking Across Authorization Servers

実装者は、複数の authorization server にまたがって同一の client attestation を使用すると、claims の値（cnf claim に含まれる Client Instance Key を含む）を通じて、Client Instance を利用する End-User の相関（関連付け）が生じ得ることを認識すべきである。したがってクライアントの展開では、異なる authorization server 間で、異なる Client Instance Key を持つ異なる Client Attestation JWT を使用することが推奨される (RECOMMENDED)。

12. Security Considerations

[RFC7519] および [RFC8725] による指針が適用される。

12.1. Replay Attacks

Authorization Server は、Client Instance によるリプレイ攻撃を検出する対策を実装すべきである (SHOULD)。本仕様の文脈では、これは攻撃者が同一の Client Attestation PoP JWT を複数のリクエストで再送していることを検出することを意味する。このクライアント認証方式において推奨される (RECOMMENDED) 選択肢は次のとおりである。

  • Authorization Server は、JWT が有効と見なされる時間ウィンドウの間、Client Attestation PoP JWT の jti 値の観測リストを管理する。このスライディングウィンドウは、Client Attestation PoP の iat と、Authorization Server が選択した時間長に基づく。Client Attestation PoP JWT がリプレイされた場合、Authorization Server はリスト内の jti 値を認識し、認証エラーで応答する。jti 値を保持するデータ構造の実装詳細は Section 10.6 にある。

  • Authorization Server は challenge endpoint で OAuth-Client-Attestation-Challenge として challenge を Client Instance に提供し、Client はそれを Client Attestation PoP JWT の challenge 値として使用する。Authorization Server は次を選択してもよい (MAY)。

    • 先述の jti アプローチと同様に、観測された challenge 値のリストを管理する。challenge 値を保持するデータ構造の実装詳細は Section 10.6 にある。これにより、追加のラウンドトリップが必要になる可能性というコストと引き換えに、Authorization Server 自身が選択した challenge により、より強いリプレイ保護が保証される。
    • 観測済み challenge を保存せずに、自己完結型の challenge を使用する。このアプローチはスケールしやすい一方で、Authorization Server が選択した限定された時間ウィンドウ内におけるリプレイ保護は保証せず、新しさ（freshness）のみを保証する。

  • Authorization Server は、challenge を Client Instance の session に束縛して生成し、Client Attestation PoP JWT 内の特定の challenge が期待され検証されるようにする。Authorization Server は次のいずれかを行ってもよい (MAY)。

    • challenge を、Client Instance に対する別の以前のレスポンスの一部として送信する（challenge を明示的に提供する代わりに）
    • Client Instance の session に関する既存の artefact（例: authorization code）を再利用する。これは Authorization Server と Client の間で out-of-band に連携されなければならない (MUST)。

サーバーとクライアントのクロックスキューが大きい場合があるため、Authorization Server は、クライアントが供給する iat 時刻をサーバー時刻と比較するのではなく、サーバー時刻を含む server-provided challenge 値を用いて Client Attestation PoP の有効期間を制限してもよい (MAY)。この方法で作成された challenges は、クロックスキューが任意に大きい場合でも同じ結果を得られる。

いずれの場合でも Authorization Server は、iat claim、または存在する場合は server provided challenge のいずれかが許容時間ウィンドウ内にあることを確認して、Client Attestation PoP の新しさ（freshness）を保証すべきである (SHOULD)。

Authorization Server が明示的に提供する challenge を用いるアプローチは、より強いリプレイ攻撃検出の保証を与える。しかし実装必須要件を簡素化するため、Authorization Server 側のサポートは OPTIONAL とされている。jti 値は必須であり、したがってデフォルトのフォールバックとして機能する。

13. IANA Considerations

13.1. OAuth Parameters Registration

本仕様は、[RFC8414] により確立された [IANA.OAuth.Params] の IANA "OAuth Authorization Server Metadata" registry に、次の値を登録することを要求する。

  • Metadata Name: challenge_endpoint
  • Metadata Description: Authorization Server の challenge endpoint の URL。client attestation のようなクライアント認証方式で使用する新しい challenge を取得するために用いられる。
  • Change Controller: IETF
  • Reference: 本仕様の Section 8

13.2. OAuth Extensions Error Registration

本仕様は、[RFC6749] により確立された [IANA.OAuth.Params] の IANA "OAuth Extensions Error Registry" registry に、次の値を登録することを要求する。

  • Name: use_attestation_challenge
  • Usage Location: token error response, resource access error response
  • Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication
  • Change Controller: IETF
  • Reference: 本仕様の Section 6.2
  • Name: use_fresh_attestation
  • Usage Location: token error response, resource access error response
  • Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication
  • Change Controller: IETF
  • Reference: 本仕様
  • Name: invalid_client_attestation
  • Usage Location: token error response, resource access error response
  • Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication
  • Change Controller: IETF
  • Reference: 本仕様の Section 6.2

13.3. OAuth Authorization Server Metadata Registration

本仕様は、[RFC8414] により確立された [IANA.OAuth.Params] の IANA "OAuth Authorization Server Metadata" registry に、次の値を登録することを要求する。

  • Metadata Name: client_attestation_signing_alg_values_supported
  • Metadata Description: Authorization Server が Client Attestation JWT の署名に対してサポートする JWS 署名アルゴリズムのリストを含む JSON array。
  • Change Controller: IETF
  • Reference: 本仕様の Section 6.2
  • Metadata Name: client_attestation_pop_signing_alg_values_supported
  • Metadata Description: Authorization Server が Client Attestation PoP JWT の署名に対してサポートする JWS 署名アルゴリズムのリストを含む JSON array。
  • Change Controller: IETF
  • Reference: 本仕様

13.4. Registration of attest_jwt_client_auth Token Endpoint Authentication Method

本節は、OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] により確立された IANA "OAuth Token Endpoint Authentication Methods" registry に、値 "attest_jwt_client_auth" を登録する。

  • Token Endpoint Authentication Method Name: "attest_jwt_client_auth"
  • Change Controller: IESG
  • Specification Document(s): TBC

13.5. HTTP Field Name Registration

本節は、[RFC9110] で記述される [IANA.HTTP.Fields] の "Hypertext Transfer Protocol (HTTP) Field Name Registry" に、次の scheme を登録することを要求する。

  • Field Name: OAuth-Client-Attestation
  • Status: permanent
  • Reference: 本仕様の Section 6.1
  • Field Name: OAuth-Client-Attestation-PoP
  • Status: permanent
  • Reference: 本仕様の Section 6.1

また、次の項目が追記されている（原文どおりに示す）。

  • add implementation consideration for Authorization Server Metadata
  • Field Name: OAuth-Client-Attestation-Challenge
  • Status: permanent
  • Reference: 本仕様の Section 8

14. References

14.1. Normative References

14.2. Informative References

  • [ARF] "The European Digital Identity Wallet Architecture and Reference Framework", n.d..
  • [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, https://www.rfc-editor.org/rfc/rfc7523.
  • [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, https://www.rfc-editor.org/rfc/rfc9334.

Appendix A. Document History

-07

  • MAC-based algorithms を許容しない制限を削除
  • Client Attestation PoP JWT で iat を必須化
  • use_attestation_challenge を明確化し、invalid_client_attestation を追加
  • IANA 登録に client_attestation_signing_alg_values_supported および client_attestation_pop_signing_alg_values_supported を追加

-06

  • token リクエストにおける client attestation の client_id 処理を明確化
  • oauth2 applications の外での client attestation 利用を明確化
  • oauth error response 値 invalid_client_attestation と use_attestation_challenge を追加
  • nonce 取得のための HTTP OPTIONS 機構を戻し、専用の challenge endpoint を追加
  • nonce を challenge に改名
  • リプレイ攻撃に関するセキュリティ考慮事項を書き直し
  • リプレイ攻撃に関する実装上の考慮事項を追加
  • Client Attestation PoP JWT から exp を削除
  • 検証および処理ルールを追加

-05

  • nonce endpoint を追加
  • nonce の metadata entry を追加
  • Introduction を改善
  • client backend を client attester に改名
  • 例で typ header が欠けていた点を修正

-04

  • key attestation の例を削除
  • 可読性向上のため JWT Claims を再構成
  • Client Attestation と Client Attestation PoP の JOSE typ values を追加
  • RATS との関係を追加
  • headers を使わない連結表現を追加
  • PAR endpoint の例を追加
  • PoP の例に jti と nonce（challenge）を含めるよう修正
  • iana http field name registration を追加

-03

  • RFC7521 の使用と client_assertion の使用を削除
  • header-based syntax として Oauth-Client-Attestation と OAuth-Client-Attestation-PoP を追加
  • 用語 Client Instance を追加し、関連する説明を改善

-02

  • Client Instance Key をローテーションできないことに関する記述を追加

-01

  • Appendix の eIDAS 例を更新
  • client attestation の jti claim に関する記述を削除し、client attestation pop での使用に関する文を洗練
  • client attestation の cnf claim に関する説明を洗練
  • この認証方式を用いて refresh tokens を Client Instance に束縛する方法を明確化
  • 認証方式が汎用であり PAR のような拡張と互換であることをより明示
  • Acknowledgments を更新

-00

  • 初版ドラフト

Acknowledgments

本仕様への貴重な貢献に対し、Brian Campbell、Filip Skokan、Francesco Marino、Guiseppe De Marco、Kristina Yasuda、Micha Kraus、Michael B. Jones、Takahiko Kawasaki、Torsten Lodderstedt に感謝する。

Authors' Addresses

Tobias Looker\ MATTR\ Email: tobias.looker@mattr.global

Paul Bastian\ Bundesdruckerei\ Email: paul.bastian@bdr.de

Christian Bormann\ SPRIND\ Email: chris.bormann@gmx.de