RFC 対応一覧
本ライブラリがコード中で参照しているすべての規格を、実装パッケージ、および有効化を決めるオプション・feature と対応づけて一覧化しています。まずステータス列（凡例は下にあります）を見て、次に括弧内を読んでください。対応する範囲と対応しない範囲が書いてあります。
仕様をどう分類しているか
ステータスの凡例
full その仕様について本ライブラリが対象とする OP 側 surface を end-to-end で実装しています。
partial OP として必要な部分は実装済みです（設計上スコープ外の任意章は除きます）。
planned 対応予定。まだ着地していません。
out out-of-scope（設計上、本ライブラリの責務ではない）。
refused 意図的に拒否しています（例: alg=none）。
この区分は実装範囲を示すもので、OpenID Foundation の認証取得を意味しません。full とした行も、その行に記した制限やライブラリの対象外事項まで満たすという意味ではありません。
OIDC core / discovery
| 仕様 | ステータス | 場所 |
|---|---|---|
| OpenID Connect Core 1.0 | partial（response_type は code のみ） | op/、internal/authorize、internal/tokenendpoint、internal/userinfo、internal/sector |
| OpenID Connect Discovery 1.0 | partial（メタデータエンドポイントを実装） | internal/discovery |
| OpenID Connect Dynamic Client Registration 1.0 | partial（主要フローと登録メタデータの検証を強制） | internal/registrationendpoint |
| OpenID Connect RP-Initiated Logout 1.0 | full | internal/endsession |
| OpenID Connect Back-Channel Logout 1.0 | full | internal/backchannel |
| OpenID Connect Prompt Create 1.0 | full (LoginFlow.Registration を設定すると prompt=create を受け付け、prompt_values_supported で公開します) | internal/authorize, internal/authn, internal/discovery |
| OpenID Connect Front-Channel Logout 1.0 | out（iframe / third-party-cookie 依存の通知方式は意図的に非実装。Back-Channel Logout を使う） | — |
| OpenID Connect Session Management 1.0 | out（サードパーティ cookie 依存のため。Back-Channel を推奨） | — |
| OpenID Connect CIBA Core 1.0 | partial（poll 配信のみ。ping / push は対象外） | internal/ciba、internal/cibaendpoint、op.WithCIBAGrant |
- OpenID Connect Core 1.0：Aggregated / Distributed claim types §5.6.2 は emit せず、pairwise sub §8.1 は
op.WithPairwiseSubjectで対応。詳細は下の「設計上の対象外」セクション - OpenID Connect Discovery 1.0：既定の ES256 では、Discovery が必須とする
RS256をid_token_signing_alg_values_supportedに含めません。op.WithSigningAlgorithm(op.AlgRS256)で構築した OP はRS256を広告します - OpenID Connect Dynamic Client Registration 1.0：強制する内容:
sector_identifier_uriの取得、application_type=web/=nativeごとの redirect URI 規則、JWKs / pairwise / response_type のクロスチェック、PUT の予約フィールド拒否、post_logout_redirect_urisの往復、5 種の JWE alg/enc encrypted-response メタデータ。GET /register/{id}の応答からはclient_secretを意図的に除外、software_statementも非対応
OAuth 2.0 系 RFC
| RFC | ステータス | 場所 / オプション |
|---|---|---|
| RFC 6749 OAuth 2.0 Framework | partial（authorization-code、refresh-token、client-credentials の surface） | op/、internal/authorize、internal/tokenendpoint |
| RFC 6750 Bearer Token Usage | partial（OP 発行 bearer token と、UserInfo / introspection など OP が持つ resource endpoint） | internal/tokens、internal/userinfo、internal/introspectendpoint |
| RFC 6819 Threat Model & Security Considerations | partial（OP 全体に適用しているセキュリティ指針。独立したプロトコル surface ではない） | コードベース全体 |
| RFC 7009 Token Revocation | full（feature.Revoke で有効化） | internal/revokeendpoint |
| RFC 7521 Assertion Framework | partial（private_key_jwt クライアント認証と JWT bearer authorization grant） | internal/clientauth、internal/assertiongrant |
| RFC 7523 JWT Bearer Assertions for Client Auth and Authorization Grants | partial（private_key_jwt） | internal/clientauth、internal/assertiongrant、internal/tokenendpoint |
| RFC 7591 Dynamic Client Registration | partial（op.WithDynamicRegistration で有効化） | internal/registrationendpoint |
| RFC 7592 DCR Management | partial（read / update / delete を実装） | internal/registrationendpoint |
| RFC 7636 PKCE | full（S256 のみ。plain は拒否） | internal/pkce |
| RFC 7662 Token Introspection | full（feature.Introspect で有効化） | internal/introspectendpoint |
RFC 7800 Confirmation Methods (cnf) | full | internal/dpop、internal/mtls、internal/tokens |
| RFC 8252 OAuth 2.0 for Native Apps | partial（OP 側の native redirect / loopback 制約を強制。client app 側の挙動は対象外） | internal/registrationendpoint、internal/authorize |
| RFC 8414 Authorization Server Metadata | full | internal/discovery |
| RFC 8485 Vectors of Trust | partial（ACR/AAL マッピング経由で消費） | op/aal.go、op/acr.go |
| RFC 8628 Device Authorization Grant | full（op.WithDeviceCodeGrant で有効化） | internal/devicecode、internal/devicecodeendpoint、op/devicecodekit |
| RFC 8693 OAuth 2.0 Token Exchange | full（op.WithTokenExchangeGrant で有効化） | internal/customgrant/tokenexchange |
| RFC 8705 OAuth 2.0 mTLS Client Auth & Cert-Bound Tokens | full（feature.MTLS は証明書バインドアクセストークン、mtls_endpoint_aliases、クライアントを認証するすべてのエンドポイントでの tls_client_auth / self_signed_tls_client_auth によるクライアント認証を接続） | internal/mtls |
| RFC 8707 Resource Indicators | partial（authorize / token / device / CIBA での正規化と client 許可リスト検証を実装） | internal/resourceindicator、internal/authorize、internal/tokenendpoint、internal/devicecodeendpoint、internal/cibaendpoint |
| RFC 8725 JWT Best Current Practices | full（alg 許可リスト、typ チェック） | internal/jose |
| RFC 9068 JWT Profile for Access Tokens | partial（JWT の発行は OP の単一アルゴリズム（既定は ES256）で行います） | internal/tokens |
| RFC 9101 JAR (JWT-Secured Authorization Request) | full（feature.JAR で有効化） | internal/jar |
| RFC 9126 PAR (Pushed Authorization Requests) | full（feature.PAR で有効化） | internal/parendpoint |
| RFC 9207 OAuth 2.0 Authorization Server Issuer Identifier | full | internal/authorize（応答に iss パラメータを付与） |
RFC 9396 Rich Authorization Requests (authorization_details) | full（op.WithAuthorizationDetailTypes で有効化） | internal/authorizationdetails、op/authorization_details.go |
| RFC 9449 DPoP | full（§8 nonce フロー含む。feature.DPoP で有効化） | internal/dpop、op.WithDPoPNonceSource |
| RFC 9470 OAuth 2.0 Step Up Authentication Challenge | full（OP は ACR rule で acr_values / max_age の再認証を尊重） | op/rule.go（RuleACR）、op/stepup.go |
| RFC 9700 OAuth 2.0 Security Best Current Practice | partial（OP 側の BCP 方針。リフレッシュトークンのローテーションと §2.2.2 の再利用時の連鎖失効を含む） | コードベース全体 |
| RFC 9701 JWT Response for OAuth 2.0 Token Introspection | full（既定は signed JWT） | internal/introspectendpoint、internal/jose |
| RFC 9728 OAuth 2.0 Protected Resource Metadata | full（op.WithProtectedResources で有効化） | internal/protectedresource、op/protected_resource.go |
- RFC 6749 OAuth 2.0 Framework：implicit grant と password grant は意図的に非実装
- RFC 6750 Bearer Token Usage：一般的な RS challenge 挙動はリソースサーバ側の責務
- RFC 7009 Token Revocation：リフレッシュトークンを失効させると、そのローテーションチェーンは長さに関係なく全体が、加えて grant のアクセストークンが失効する。同じクライアントでのユーザの別のリフレッシュチェーンは引き続き使える
- RFC 7521 Assertion Framework：SAML bearer grant と
client_secret_jwtは意図的に非実装 - RFC 7523 JWT Bearer Assertions for Client Auth and Authorization Grants：
jtiが空または長すぎる assertion は拒否し、クライアントの JWKS 取得で障害が起きたときはinvalid_clientではなく 503 を返す。urn:ietf:params:oauth:grant-type:jwt-bearergrant は、明示的に信頼した issuer の assertion について実装済みで、assertion はすべてjtiで単回使用。client_secret_jwtは非実装で、登録時点でinvalid_client_metadataとして拒否 - RFC 7591 Dynamic Client Registration：
software_statementはinvalid_software_statementで拒否。jwksとjwks_uriの両方を持つクライアントレコードは、§2 が併用を禁じているため、あらゆる経路で拒否 - RFC 7592 DCR Management：PUT の省略はフィールド削除ではなくサーバの既定値へのリセットとして扱い、応答での
client_secret再掲はnone→ confidential への auth method 昇格、または明示的な rotation 要求のいずれかに限定 - RFC 7662 Token Introspection：有効なリフレッシュトークンに
token_typeを付けないのは、リソースサーバがアクセストークンと取り違えないようにするため - RFC 8628 Device Authorization Grant：
slow_downの段階的な延長はLastPolledAtと原子的に永続化。引き換え時にstore.Grantを記録するため、失効と pairwise の/userinfoがトークンに届く。op/devicecodekitが総当たり対策と、grant 配下を連鎖して失効させるRevokeを同梱し、Deps.Grantsを渡せば grant レコードも削除する - RFC 8693 OAuth 2.0 Token Exchange：actor が subject と異なる場合は
actチェーン必須で、subject_token 自身のチェーンを 5 段まで入れ子にして引き継ぐ。発行したトークンは subject_token の grant の配下に置かれ、grant を失効させると一緒に失効する。cnf はリクエストの DPoP / mTLS で再バインド。クライアントの登録 scope を超えるscopeはinvalid_scopeで拒否 - RFC 8707 Resource Indicators：組み込み grant は現在、多くの発行経路を単一 resource 値に絞る
- RFC 9068 JWT Profile for Access Tokens：§2.1 は RS256 対応を求めており、
op.WithSigningAlgorithm(op.AlgRS256)で構築した OP はこれを満たします。また、検証側がjtiを要求するのは失効戦略がjtiを使う場合だけで、戦略がNoneなら §2.2 で必須のjtiを持たないトークンも受け付けます - RFC 9396 Rich Authorization Requests (
authorization_details)：/auth、/par、/tokenで検証し、認可コード・リフレッシュチェーン・アクセストークンごとに永続化して、後からの認可で変わらないようにし、JWT アクセストークンと introspection に反映し、discovery で公開 - RFC 9470 OAuth 2.0 Step Up Authentication Challenge：
op.StepUpChallengeが組み込み側 RS の返すWWW-Authenticatechallenge を組み立てる - RFC 9700 OAuth 2.0 Security Best Current Practice：リソースサーバ / client 側要件は組み込み側の責務
- RFC 9701 JWT Response for OAuth 2.0 Token Introspection：client の
introspection_encrypted_response_alg/_encメタデータに応じて JWE で wrap - RFC 9728 OAuth 2.0 Protected Resource Metadata：
/.well-known/oauth-protected-resourceで配信し、authorization_serversに issuer を刻む
IETF ドラフト
| ドラフト | ステータス | 場所 |
|---|---|---|
OAuth 2.0 Grant Management（draft-ietf-oauth-grant-management） | partial（op.WithGrantManagement で有効化） | internal/grantmgmtendpoint、op/grant_management.go |
Identity Assertion JWT Authorization Grant (ID-JAG)（draft-ietf-oauth-identity-assertion-authz-grant、draft-06） | partial（リソース認可サーバ側: jwt-bearer grant による ID-JAG の償還に対応） | internal/assertiongrant、internal/customgrant/tokenexchange |
OAuth Client ID Metadata Document（draft-ietf-oauth-client-id-metadata-document、draft-02） | partial（op.WithClientIDMetadataDocuments で有効化） | internal/cimd、op/cimd.go |
- OAuth 2.0 Grant Management（
draft-ietf-oauth-grant-management）：grant_management_action/grant_idを処理し、query / revoke エンドポイントをマウントし、token 応答にgrant_idを載せ、discovery で公開。IETF draft 追跡のため draft 更新で surface が変わり得る - Identity Assertion JWT Authorization Grant (ID-JAG)（
draft-ietf-oauth-identity-assertion-authz-grant、draft-06）：IdP 側: token exchange による ID-JAG の発行に対応。ID-JAG は OP の発行アルゴリズムで署名する。既定の ES256 では、draft が実装必須とする RS256 は満たさず、RS256 しか実装しないリソース AS には拒否される。op.WithSigningAlgorithm(op.AlgRS256)で構築した OP は ID-JAG を RS256 で署名する。experimental。IETF draft 追跡のため draft 更新で surface が変わり得る - OAuth Client ID Metadata Document（
draft-ietf-oauth-client-id-metadata-document、draft-02）：HTTPS URL のclient_idを取得したメタデータ文書に解決し、noneとprivate_key_jwtのクライアントがauthorization_codeとrefresh_tokenを使えます。共有秘密を使う confidential クライアントと mTLS クライアントは非対応で、文書が変わっても既存の grant は失効しません。experimental で明示的な opt-in。IETF draft 追跡のため draft 更新で surface が変わり得る。MCP 認可仕様は draft-00 を引用している
Shared Signals（transmitter）
以下はすべて transmitter 側の対応です。他の transmitter からイベントを受け取る機能はありません。有効化は op.WithSharedSignals で行います。詳しくは Shared Signals を参照してください。
| 仕様 | ステータス | 場所 / オプション |
|---|---|---|
| OpenID Shared Signals Framework 1.0 | partial（transmitter メタデータ、stream の作成・取得・更新・置換・削除、stream status、verification、push / poll 配送を実装） | internal/ssf、op.WithSharedSignals |
| OpenID CAEP 1.0 | partial（session-revoked と credential-change のみ） | internal/ssf、op.SessionRevoked、op.CredentialChange |
| OpenID RISC 1.0 | partial（account-disabled、account-enabled、account-purged、credential-compromise） | internal/ssf、op.AccountDisabled、op.AccountEnabled、op.AccountPurged、op.CredentialCompromise |
| RFC 8417 Security Event Token | full（発行側: typ: secevent+jwt、1 トークン 1 イベント、sub と exp は持たない） | internal/ssf |
| RFC 8935 Push-Based SET Delivery | full（transmitter 側。再送と SSRF 防御つきの配送） | internal/ssf |
| RFC 8936 Poll-Based SET Delivery | full（transmitter 側。long poll を含む） | internal/ssf |
| CAEP Interoperability Profile 1.0 | partial（transmitter の要件は §2.6 を除いて満たす。§2.6 は RS256 署名を求める） | internal/ssf |
- OpenID Shared Signals Framework 1.0：
add_subject/remove_subject、inactivity_timeout、min_verification_intervalは未実装。メタデータはdefault_subjects: "ALL"を広告し、これは Receiver のクライアントに対する grant を持つすべての subject を指す - OpenID RISC 1.0：experimental: 公開されている RISC の本文がまだ draft のため、マイナーリリースで surface が変わり得る
- CAEP Interoperability Profile 1.0：SET は OP の単一の発行アルゴリズムで署名し、既定の ES256 では §2.6 を満たさず、
op.WithSigningAlgorithm(op.AlgRS256)を指定すれば RS256 になる
JOSE 系
| RFC | ステータス | 場所 |
|---|---|---|
| RFC 7515 JWS | partial（JWT / JAR / JARM / DPoP / client assertion で使う compact JWS surface） | internal/jose |
| RFC 7516 JWE | partial — 閉じた許可リスト（RSA-OAEP-256 / ECDH-ES{,+A128KW,+A256KW} × A{128,256}GCM） | internal/jose、op.WithEncryptionKeyset |
| RFC 7517 JWK | partial（対応済み非対称鍵種の JWK Set 公開と client JWKS 消費。署名用途の対称 oct 鍵は受理しない） | internal/jwks |
| RFC 7518 JWA | partial — 発行は OP ごとに 1 つのアルゴリズムで、既定は ES256、op.WithSigningAlgorithm で RS256 | internal/jose |
| RFC 7519 JWT | partial（OIDC / OAuth 拡張で使う signed / encrypted JWT surface。unsecured JWT は拒否） | internal/jose |
| RFC 7638 JWK Thumbprint | full（DPoP cnf.jkt で使用） | internal/dpop |
RFC 8037 Edwards-curve DSA / EdDSA | partial（Ed25519。Ed448 は無効） | internal/jose |
- RFC 7515 JWS：general JSON serialization は公開しない
- RFC 7516 JWE：inbound JWE request_object（JAR / PAR §6.1）、outbound JWE id_token、JWT-shape userinfo、JARM authorization 応答、RFC 9701 introspection 応答を実装済み。
RSA1_5は refused（CVE-2017-11424 padding oracle）。RSA-OAEP-384/512、dir、対称鍵のみのA*KWは v2+ で対応 - RFC 7518 JWA：検証は
RS256、PS256、ES256、EdDSAを受理。HS*とnoneは refused
FAPI 系
Go の識別子 FAPI2Baseline には旧称の Baseline が残っています。現行の Final 仕様名は FAPI 2.0 Security Profile です。ここで参照する OFCS の結果は、スイートの FAPI 2.0 Final テストプラン（および FAPI-CIBA ID1 プラン）に対する回帰実行であり、認証ではありません。Final 仕様の全要件への適合を示すものでもありません。FAPI2Baseline と FAPI2MessageSigning では、本ライブラリは private_key_jwt の aud として issuer 識別子の文字列だけを受け付け（§5.3.2.1(8)）、リフレッシュトークンをローテーションしません（§5.3.2.1(9)）。ほかのプロファイルは、より広い aud の集合を受け付け、ローテーションします。
| プロファイル | ステータス | 切り替え |
|---|---|---|
| FAPI 2.0 Security Profile | partial（PAR、PKCE、送信者制約付きトークンを実装。この設定はライブラリ独自の選択として JAR も要求します） | op.WithProfile(profile.FAPI2Baseline) |
| FAPI 2.0 Message Signing | partial（JAR と JARM を実装。Final 仕様では署名機能ごとの適合が可能で、Security Profile の要件も引き継ぎます） | op.WithProfile(profile.FAPI2MessageSigning) |
| FAPI 1.0 Advanced | out | —（FAPI 2.0 を使用） |
| FAPI-CIBA | partial（ライブラリの設定: poll モード、JAR、DPoP または mTLS、アクセストークンの有効期間の上限 10 分、requested_expiry の上限 600 秒、アクセストークンの失効処理） | op.WithProfile(profile.FAPICIBA) |
| OpenID iGov High | out | — |
- FAPI 2.0 Security Profile：上記の注記と OFCS を参照
- FAPI-CIBA：旧 ID1 プランは mTLS を使い、デモも明示的に選びます。リクエストオブジェクトの経過時間 60 分という上限はライブラリの制約です。OFCS を参照
プロファイル列挙には、FAPI プロファイルではないものがさらに 2 つあります。profile.OAuth21 はプロファイル未宣言時の既定で、OAuth 2.1 / RFC 9700 の姿勢を表し、confidential client も含めたすべての authorization-code request に PKCE を要求します。profile.OIDCCore は OpenID Connect Core 1.0 の形（confidential client では PKCE 任意）を、旧来の RP 向けに宣言するもので、他のプロファイルとは組み合わせられません。ユースケース: セキュリティプロファイルの宣言 を参照。
その他、ライブラリが参照する RFC
| RFC | 用途 |
|---|---|
| RFC 1918 | Back-Channel Logout SSRF 防御のプライベートネットワーク拒否リスト |
| RFC 2045 | request object の typ で使う、大文字小文字を区別しないメディアタイプ比較 |
| RFC 2606 | テスト / 例で使う予約済み example domain |
| RFC 3986 | URI パース |
| RFC 4122 | UUIDv4 生成 |
| RFC 4226 | TOTP authenticator が使う HOTP の土台 |
| RFC 4514 | mTLS subject DN の DN 処理 |
| RFC 4647 | ロケールバンドルを選ぶときの言語タグ lookup |
| RFC 4648 | Base64url エンコーディング |
| RFC 5280 | X.509 証明書検証 |
| RFC 5321 | Email OTP 入力に対する SMTP アドレス長の上限 |
| RFC 6238 | TOTP authenticator |
| RFC 6265 | Cookie 構文 |
| RFC 6711 | Authentication Context Class Reference 値レジストリ |
| RFC 6761 | 特殊用途ドメイン名。WithAllowInsecureOutboundForDev が受け付ける開発用 issuer ホスト |
| RFC 6838 | 取得した文書の media type の suffix（+json）照合 |
| RFC 7230 / 7231 / 7232 / 7235 | HTTP/1.1（現在は RFC 9110 が後継） |
| RFC 7239 | trusted proxy 処理での Forwarded header パース |
| RFC 7807 | application/problem+json（一部のエラー経路） |
| RFC 8017 | JOSE 経由で参照する RSA-PSS / RSA-OAEP アルゴリズム |
| RFC 8141 | PAR request_uri 値の URN 処理 |
| RFC 8176 | AMR 値レジストリ |
| RFC 8259 | JSON |
| RFC 9110 | HTTP セマンティクス |
| RFC 9111 | HTTP キャッシュ。取得した Client ID Metadata Document の鮮度の寿命 |
| RFC 9325 | TLS の推奨設定。op.FAPITLSConfig は FAPI の TLS 1.2 暗号スイート一覧と並べて TLS 1.3 を有効に保つ |
| RFC 9493 | Shared Signals イベントの iss_sub subject identifier |
設計上の対象外
OIDC Core や周辺 OAuth 仕様には登場するものの、本ライブラリでは意図的に実装していない項目があります。隣接リポジトリの test/scenarios/catalog/<feature>.yaml に status: out-of-scope 行として記録され、ほかのテストと同じ場所で棚卸しできるようになっています。
response_typeはcodeのみ。 Implicit（id_token、id_token token）、hybrid（code id_tokenほか）、response_type=noneはいずれも発行しません。RFC 9700 §2.1.2 が implicit grant を非推奨化しており、FAPI 2.0 は code を必須としています。Discovery もresponse_types_supported: ["code"]だけを広告します。fragmentresponse mode は配信路として実装していません。codeのみの発行では URL fragment に入れるものがないためです。queryとform_postは両方とも実装されています（form_postは OIDC Core Form Post Response Mode 1.0 に従って自動送信 HTML フォームを返します）。feature.JARMを有効にすると 4 種の*.jwtバリアントも有効になります。Discovery は既定でresponse_modes_supported: ["query", "form_post"]を広告し、JARM 有効時には*.jwtモードを追加で広告します。- Aggregated / Distributed claim types（OIDC Core §5.6.2）は emit しません。 Normal claim のみを出力します。
_claim_names/_claim_sourcesといったキーはトークンにも UserInfo 応答にも一切登場しません。 client_secret_jwtは登録時点で拒否します。 代わりにprivate_key_jwtを使ってください。HMAC 共有秘密 JWT プロファイルはinvalid_client_metadata: token_endpoint_auth_method client_secret_jwt is not supportedで拒否されます。- JWE alg / enc の許可リストは閉じています。 既定値は
RSA-OAEP-256+ECDH-ES{,+A128KW,+A256KW}（key-wrap）とA{128,256}GCM（content）です。WithSupportedEncryptionAlgsは 狭める だけで、広げることはできません。RSA1_5は永続的に拒否（CVE-2017-11424）。RSA-OAEP-384/RSA-OAEP-512、dir、対称鍵のみのA*KWは v2+ で対応します。 - CIBA の push / ping 配信モードは未実装。 Discovery は
backchannel_token_delivery_modes_supported: ["poll"]のみを広告するので、クライアント側からこの 2 モードを交渉することはできません。 - Custom-grant ハンドラはリフレッシュトークン値を渡せません。 リフレッシュトークンを発行したいハンドラは
CustomGrantResponse.IssueRefreshTokenを立てます。OP が自分のRefreshTokenStoreで資格情報を生成・永続化するため、親子関係、ローテーション、再利用時の連鎖失効、DPoP / mTLS バインディングが保たれます。クライアントがrefresh_tokengrant に登録されていない場合でもアクセストークン応答は成功し、リフレッシュトークンだけが省略され、custom_grant.refresh_droppedが記録されます。
範囲外（意図的）
OAuth / OIDC 圏のすべての RFC が OP の責務というわけではありません。以下は意図的に対応していない仕様で、リソースサーバ・クライアント SDK・その他のレイヤが受け持つべき領域です。
| 仕様 | 対応状況 | 備考 |
|---|---|---|
| RFC 9421 — HTTP Message Signatures | out | リソースサーバ（API 保護）側の関心事であり、OP の責務ではありません。 |
- RFC 9421 — HTTP Message Signatures：OP 側の対応する仕組みは、認可リクエスト署名に JAR (RFC 9101)、認可レスポンス署名に JARM、
/tokenと/userinfoの所持証明に DPoP (RFC 9449) です。RS 側の HTTP 署名は組み込み側で実装してください。
検証方法
この一覧は最新のソース（op/ と internal/）を grep して作成しています。手元で再現できます。
sh
git clone https://github.com/libraz/go-oidc-provider.git
cd go-oidc-provider
grep -rhoE 'RFC [0-9]+' op/ internal/ | sort -u上の表はこのコマンドの出力に沿っています。ライブラリが実装する規格には個別の行を設け、付随的に参照しているだけのものは「その他、ライブラリが参照する RFC」にまとめました。