Skip to content

docname: draft-openid-ipsie-sl1-profile-latest submissiontype: "independent" number: date: v: 3

area: AREA

workgroup: IPSIE Working Group keyword:

  • openid
  • ipsie venue: group: IPSIE type: Working Group mail: openid-specs-ipsie@lists.openid.net arch: https://openid.net/wg/ipsie/ github: "openid/ipsie-openid-sl1" latest: "https://openid.github.io/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html"

author:

fullname: Aaron Parecki
organization: Okta
email: aaron@parecki.com

normative: BCP195: RFC2119: RFC8174: RFC6749: RFC6750: RFC6797: RFC7636: RFC8252: RFC8414: RFC8725: RFC9126: RFC9207: RFC9449: RFC9525: RFC9700: OpenID: title: OpenID Connect Core 1.0 incorporating errata set 2 target: https://openid.net/specs/openid-connect-core-1_0.html date: December 15, 2023 author: - ins: N. Sakimura - ins: J. Bradley - ins: M. Jones - ins: B. de Medeiros - ins: C. Mortimore OpenID.Discovery: title: OpenID Connect Discovery 1.0 incorporating errata set 2 target: https://openid.net/specs/openid-connect-discovery-1_0.html date: December 15, 2023 author: - ins: N. Sakimura - ins: J. Bradley - ins: M. Jones - ins: E. Jay OpenID.IPSIE-Common-Requirements: title: IPSIE Common Requirements Profile target: https://deansaxe.github.io/draft-saxe-ipsie-common-requirements-profile/draft-saxe-ipsie-common-requirements-profile.html date: July 9, 2025 author: - ins: D. H. Saxe NIST.FAL: title: NIST SP 800-63 Digital Identity Guidelines Federation Assurance Level (FAL) target: https://pages.nist.gov/800-63-4/sp800-63c/fal/ date: August 28, 2024

informative:

--- abstract

TBD

--- middle

Introduction

本仕様は、企業向け連携のために IPSIE の SL1 要件を満たすよう OpenID Connect を実装する方法を定義します。このプロファイルは、フェデレーション認証に関するセキュリティおよび相互運用性の標準を定め、アプリケーションがユーザーを認証し、OpenID Connect の userinfo endpoint から追加のユーザー claims を取得できるようにします。

本プロファイルは認証シナリオに特化しており、広範な API アクセスのユースケースは対象としません。そのため、Refresh Token の使用および／または OAuth DPoP（Demonstration of Proof of Possession）は任意です。

Conventions and Definitions

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

Roles

本書では、「Identity Provider」という用語を、[OpenID] における「OpenID Provider」および [RFC6749] における「Authorization Server」を指すものとして用います。

本書では、「Application」という用語を、[OpenID] における「Relying Party」および [RFC6749] における「Client」を指すものとして用います。

Profile

Common Requirements

Application および Identity Provider は、IPSIE Common Requirements Profile [OpenID.IPSIE-Common-Requirements] にあるすべての要件に従わなければなりません（MUST）。

OpenID Connect

以下では、次の技術に関するプロファイルを定義します。

  • OpenID Connect Core 1.0 incorporating errata set 2 [OpenID.Discovery]
  • OpenID Connect Discovery [OpenID.Discovery]
  • OAuth 2.0 Authorization Framework [RFC6749]
  • Proof Key for Code Exchange (PKCE) [RFC7636]
  • OAuth 2.0 Authorization Server Metadata [RFC8414]
  • OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449]
  • OAuth 2.0 Authorization Server Issuer Identification [RFC9207]

Requirements for OpenID Providers

OpenID Providers:

  • [OpenID.Discovery] で規定されるとおり、メタデータドキュメントを介して（authorization endpoint などの）discovery metadata を配布しなければなりません（MUST）。
  • resource owner password credentials grant を用いたリクエストを拒否しなければなりません（MUST）。
  • [RFC6749] で定義される Public client をサポートしなければなりません（MUST）。
  • open redirectors を公開してはなりません（MUST NOT） {{Section 4.11 of RFC9700}}。
  • client authentication assertions で受け取る aud claim において、（[RFC8414] で定義される）自らの issuer identifier value を、文字列としてのみ受け付けなければなりません（MUST）。
  • Authorization Code を最大有効期間 60 秒で発行しなければなりません（MUST）。
  • client の事前登録を必須としなければならず（MUST）、未認証の Dynamic Client Registration リクエストをサポートしてはなりません（MUST NOT）（Note 1 参照）。
  • redirect URIs の事前登録を client に要求しなければなりません（MUST）。

OpenID Providers が発行する Access Tokens:

  • RP が OpenID Provider において identity claims を取得するためにのみ使用されなければなりません（MUST）。
  • DPoP [RFC9449] を用いた sender-constrained access tokens のみを発行することが望ましいです（SHOULD）。

OpenID Providers が発行する ID Tokens:

  • RP の OAuth Client ID を、単一の audience 値として文字列で含めなければなりません（MUST）（Note 2 参照）。
  • [OpenID] の Section 2 に記載されるとおり、実行された認証が満たした Authentication Context Class を識別する文字列として acr claim を含めなければなりません（MUST）。
  • [OpenID] の Section 2 に記載されるとおり、IANA Authentication Method Reference Values registry に登録されたものの中から、認証で使用された認証方法の識別子を示す文字列配列として amr claim を含めなければなりません（MUST）。
  • end user 認証が最後に行われた時刻を示すために auth_time claim を含めなければなりません（MUST）（Note 4 参照）。
  • RP セッションの期待される失効時刻を session_expiry claim に示さなければなりません（MUST）。値は Unix timestamp（epoch からの秒数）を表す JSON の整数でなければなりません（Note 3 参照）。

Note 1: 事前登録済み client を要求することは、[NIST.FAL] の Section 3.4「Trust Agreements」に対応します。

Note 2: audience 値は、[NIST.FAL] の audience restriction を満たすために単一の文字列でなければなりません。

Note 3: この claim は現在 AB Connect WG で定義中です。最新ドラフトは https://openid.github.io/connect-enterprise-extensions/main.html を参照してください。

Note 4: この claim は [NIST.FAL] の Section 4.7 の要件を満たすために必要です。

Authorization Code Flow について、OpenID Providers:

  • [RFC6749] で記述される response_type の値として code を要求しなければなりません（MUST）。
  • code challenge method として S256 を用いる PKCE [RFC7636] を必須としなければなりません（MUST）（下記 Note 1 参照）。
  • {{Section 2.1 of RFC9700}} に記載されるとおり、登録済み redirect_uri との完全一致を要求しなければなりません（MUST）。
  • Authorization Code を最大有効期間 60 秒で発行しなければなりません（MUST）。
  • [RFC9207] に従い、authorization response に iss parameter を返さなければなりません（MUST）。
  • 暗号化されていないネットワーク接続上で authorization responses を送信してはならず（MUST NOT）、そのため http scheme を使用する redirect URIs を許可してはなりません（MUST NOT）。
  • 以前に使用されたことのある authorization code（[RFC6749] の Section 1.3.1）を拒否しなければなりません（MUST）。
  • 意図せず第三者に資格情報が転送されることを避けるため、user credentials を含むリクエストをリダイレクトする際に HTTP 307 ステータスコードを使用してはなりません（MUST NOT）（{{Section 4.12 of RFC9700}} 参照）。
  • ステータスコードを用いて user agent をリダイレクトする際、HTTP 303 ステータスコードを使用することが望ましいです（SHOULD）。
  • 長さ 64 文字までの nonce parameter 値をサポートしなければならず（MUST）、64 文字を超える nonce 値は拒否しても構いません（MAY）。
  • OP がユーザーを認証してからの経過秒数として許容される最大値を表す max_age parameter をサポートしなければなりません（MUST）。認証からの経過時間がこの値より短い場合、OP はユーザーの再認証を積極的に行うことを選択しても構いません（MAY）。認証からの経過時間がこの値より長い場合、OP はユーザーを積極的に再認証しなければなりません（MUST）。

Note 1: nonce と PKCE はどちらも authorization code injection からの保護を提供し得ますが、nonce は client（RP）側でのチェック実装とその強制に依存します。IdP はそれが正しく実装されているか検証できず、トークンがすでに発行された後にしか攻撃を止められません。これに対し、PKCE は IdP によって強制され、トークンが発行される前に攻撃を止めます。

Requirements for OpenID Relying Parties

OpenID Relying Parties:

  • [OpenID] の Section 4 で定義される third-party initiated login をサポートしなければなりません（MUST）。
  • client authentication assertions の aud claim に、authorization server の issuer identifier value（[RFC8414] で定義）を使用しなければなりません（MUST）。issuer identifier value は配列の要素としてではなく、文字列として送られなければなりません（shall）。
  • open redirectors を公開してはなりません（MUST NOT）（{{Section 4.11 of RFC9700}} 参照）。
  • [OpenID.Discovery] および [RFC8414] で規定されるとおりメタデータドキュメントから取得した authorization server metadata（authorization endpoint など）だけを使用しなければなりません（MUST）。
  • authorization server metadata の取得の基礎として用いる issuer URL は、権威ある情報源から、かつ安全なチャネルを通じて取得され、攻撃者により改変され得ないようにしなければなりません（MUST）。
  • この issuer URL と、取得したメタデータ内の issuer 値が一致することを保証しなければなりません（MUST）。

OpenID Provider への resource requests を行う OpenID Relying Parties:

  • [RFC9449] に記載される DPoP を用いた sender-constrined access tokens をサポートしなければなりません（MUST）。
  • （{{Section 8 of RFC9449}} で定義される）server-provided nonce mechanism をサポートしなければなりません（MUST）。
  • {{Section 7.1 of RFC9449}} に記載されるとおり、HTTP header で Access Tokens を送らなければなりません（MUST）。

Authorization Code Flow について、Relying Parties:

  • [RFC6749] に記載される authorization code grant を使用しなければなりません（MUST）。
  • code challenge method として S256 を用いる PKCE [RFC7636] を使用しなければなりません（MUST）。
  • 各 authorization request ごとに PKCE challenge を生成し、フローを開始した client と user agent にその challenge を安全に紐付けなければなりません（MUST）。
  • mix-up attacks を防ぐため、[RFC9207] に従って authorization response の iss parameter を確認しなければなりません（MUST）。
  • 64 文字を超える nonce parameter 値は使用しないことが望ましいです（SHOULD NOT）。
  • 認証リクエストにおいて、OP に対し許容される認証の最大経過時間（秒）を指定するために max_age parameter を使用することが望ましいです（SHOULD）。max_age parameter の値は、RP の業務ルールに基づいて決定しても構いません（MAY）。

[OpenID] の Section 3.1.37 に記載される ID Token validation 要件に加えて、Relying Parties:

  • aud claim が単一の文字列であり、かつ RP の OAuth Client ID と一致することを検証しなければなりません（MUST）。
  • session_expiry claim で示される時刻以降、OpenID Provider を通じてユーザーを再認証しなければなりません（MUST）。再認証は、新たな Authorization Code Flow を開始するか、以前に取得した Refresh Token を用いて新しい ID Token を要求することで行います（Note 1 参照）。

Note 1: この claim は現在 AB Connect WG で定義中です。最新ドラフトは https://openid.github.io/connect-enterprise-extensions/main.html を参照してください。

Security Considerations

IANA Considerations

本書に IANA に関するアクションはありません。

--- back

Notices

Copyright (c) 2025 The OpenID Foundation.

The OpenID Foundation (OIDF) は、あらゆる Contributor、developer、implementer、またはその他の利害関係者に対し、非独占的で、ロイヤルティフリーの、全世界的な著作権ライセンスを付与します。これは、(i) 仕様の策定、および (ii) Implementers Drafts、Final Specifications、ならびに Final Specification Incorporating Errata Corrections に基づく Implementers Drafts、Final Specifications、Final Specification Incorporating Errata Corrections の実装を目的として、本 Implementers Draft、Final Specification、または Final Specification Incorporating Errata Corrections を複製し、二次的著作物を作成し、配布し、上演し、表示するためのものです。なお、OIDF が当該資料の提供元であることを明示する帰属表示（attribution）を行うことが条件ですが、その帰属表示は OIDF による推奨（endorsement）を示すものではありません。

本仕様で記述される技術は、OpenID Foundation のメンバーを含む様々な提供元からの貢献により利用可能となりました。OpenID Foundation は、その技術が配布可能であることを確保するための手段を講じてはいるものの、本仕様で記述される技術の実装または使用に関して主張され得るいかなる知的財産権その他の権利の有効性または範囲についても、また、そのような権利に基づくライセンスが利用可能か否か、あるいはどの程度利用可能であるかについても、いかなる立場も取りません。さらに、当該権利を特定するための独自の努力を行ったことを表明するものでもありません。OpenID Foundation および本仕様への貢献者は、本仕様に関連するいかなる保証（明示、黙示、その他）も行わず（ここに明示的に否認します）、これには商品性、非侵害、特定目的への適合性、または権原に関する黙示の保証を含みます。したがって、本仕様を実装することに伴う一切のリスクは実装者が負うものとします。OpenID Intellectual Property Rights policy（openid.net に掲載）は、貢献者に対し、他の貢献者および実装者に対して特定の特許請求を主張しない旨の patent promise を申し出ることを求めています。OpenID は、当該技術を実施するために必要となり得る技術を対象とする著作権、特許、特許出願、またはその他の専有権が存在する場合、いかなる関係者もそれを OpenID に通知するよう求めます。

Document History

[[ To be removed from the final specification ]]

-01

  • keywords を大文字の IETF keywords に置き換えた
  • common requirements を削除し、新しい IPSIE Common Requirements draft から参照するようにした

-00

初期ドラフト

Acknowledgments

{:numbered="false"}

TODO acknowledge.