Skip to content

title: "IPSIE Common Requirements Profile" abbrev: "IPSIE Common Requirements" category: info

docname: draft-ipsie-common-requirements-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-common-requirements-profile" latest: https://openid.github.io/ipsie-common-requirements-profile/draft-ipsie-common-requirements-profile.html

author:

fullname: Dean H. Saxe
organization: Full Frontal Nerdity Industries
email: dean@thesax.es

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 NIST.FAL: title: NIST SP 800-63-4 Digital Identity Guidelines Federation Assurance Level (FAL) target: https://pages.nist.gov/800-63-4/sp800-63c/fal/ date: August 1, 2025

informative:

--- abstract

IPSIE Common Requirements Profile は、すべての IPSIE レベル（SL および IL）とプロトコルに適用可能な、複数の共通セキュリティ要件のプロファイルです。これらの共通要件は、1 つ以上の IPSIE プロファイルを利用する enterprise のセキュリティおよび相互運用性の要件を満たすことを意図しています。

--- middle

Introduction

TODO 共通要件の Introduction

Conventions and Definitions

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

Profile

Security Controls

（後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/72 に関連） 本節は非規範的です。

  • すべての IPSIE 準拠の Identity Provider および Application は、NIST SP800-53、FEDRAMP、またはその他の関連プログラムなどの security controls program を実装することが望ましいです（should）。
  • 当該プログラムは、Identity Provider または Application のいずれであっても、ユーザーの personal attributes が provider により保存時にどのように保存されるかを特定することが望ましいです（should）。
  • このプログラムおよびその controls は文書化され、IPSIE 準拠 federation の関係者に提供されることが望ましいです（should）。

Network Layer Requirements

Requirements for all endpoints

ネットワーク攻撃から保護するため、clients、Authorization Server、Resource Server は次を満たさなければなりません（MUST）。

  • TLS で保護された endpoints のみを提供し、他のサーバーへの接続を TLS で確立しなければなりません（MUST）。
  • TLS version 1.2 以降を用いて TLS 接続を確立しなければなりません（MUST）。
  • [BCP195] における Secure Use of Transport Layer Security の推奨事項に従わなければなりません（MUST）。
  • rogue domain-validated TLS certificates の発行につながり得る DNS spoofing attacks から保護するため、DNSSEC を使用することが望ましいです（SHOULD）。
  • [RFC9525] に従って TLS server certificate check を実施しなければなりません（MUST）。

Requirements for endpoints not used by web browsers

web browsers により使用されない server-to-server communication endpoints には、次の要件が適用されます。

  • TLS 1.2 を使用する場合、サーバーは [BCP195] で推奨される cipher suites のみを許可しなければなりません（MUST）。
  • TLS 1.2 を使用する場合、clients は [BCP195] で推奨される cipher suites のみを許可することが望ましいです（SHOULD）。

Requirements for endpoints used by web browsers

web browsers により使用される endpoints には、追加で次の要件が適用されます。

  • サーバーは、TLS stripping attacks により接続がダウングレードされないことを保証する方法を使用しなければなりません（MUST）。この目的には、preloaded [preload] HTTP Strict Transport Security policy [RFC6797] を使用できます。.bank や .insurance など一部の top-level domains はこのようなポリシーを設定しており、その配下のすべての second-level domains を保護しています。
  • TLS 1.2 を使用する場合、サーバーは [BCP195] で許可される cipher suites のみを使用しなければなりません（MUST）。
  • client はこの endpoint に直接アクセスするのではなく HTTP redirect を実行しなければならないため、サーバーは authorization endpoint に対する [CORS] をサポートしてはなりません（MUST NOT）。

Cryptography and Secrets

暗号処理および secrets には、次の要件が適用されます。

  • Authorization Server、clients、Resource Server が JWTs を作成または処理する場合：
  • [RFC8725] に従わなければなりません（MUST）。
  • PS256、ES256、または EdDSA（Ed25519 variant を使用）アルゴリズムを使用しなければなりません（MUST）。
  • none algorithm を使用または受け入れてはなりません（MUST NOT）。
  • RSA keys は最小長 2048 bits でなければなりません（MUST）。
  • Elliptic curve keys は最小長 224 bits でなければなりません（MUST）。
  • end-users による取り扱いを意図しない Credentials（例：access tokens、refresh tokens、authorization codes など）は、少なくとも 128 bits のエントロピーを用いて生成されなければなりません（MUST）。これは、攻撃者が値を正しく推測することが計算上現実的でないようにするためです（{{Section 10.10 of RFC6749}}）。

Federation

IPSIE federation protocols は、[NIST.FAL] において FAL2 で定義される多くの technical controls に準拠するよう設計されています。以下の federation 要件は FAL2 の要件に由来し、IPSIE WG が策定するすべての federation protocol profiles に適用されます。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/77 および https://github.com/openid/ipsie/issues/81 に関連）

  • Identity Provider および Application は、業務運用に必要な範囲に account attribute disclosures を最小化しなければなりません（SHALL）。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/78 に関連）

  • [NIST.FAL] の Section 3.7.1 で定義される account linking は、RP によりサポートされても構いません（MAY）。
  • RP は account linking をデフォルトで無効化しなければなりません（MUST）。

  • account linking を許可する RP は、[NIST.FAL] の要件に従わなければなりません（MUST）。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/80 に関連）

  • フェデレーション認証を迂回する alternative authentication mechanisms は、すべての SL レベルにおいて IPSIE 準拠 Application によりサポートされても構いません（MAY）。これらの仕組みは一般に「break-glass」accounts として知られています。
  • これらの仕組みはデフォルトで無効化されなければならず（MUST）、個々のユーザー単位で有効化しても構いません（MAY）。有効化の仕組みは IPSIE では規定しません。
  • alternative authentication mechanisms は、多要素認証の使用を含む IPSIE 認証の最低要件を満たさなければなりません（MUST）。
  • phishing resistant authentication は推奨されます（RECOMMENDED）。

  • ユーザーの account が Application から無効化または削除された場合に、account へのアクセスを防ぐため、alternative authentication mechanisms は identity provisioning protocol を通じて無効化されなければなりません（MUST）。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/81 および https://github.com/openid/ipsie/issues/75 に関連）

  • back channel を通過する assertions の暗号化は、Identity Provider により提供されなければならず（MUST）、Application により使用されても構いません（MAY）。
  • front channel を通過する assertions は暗号化されなければなりません（MUST）。

  • 複数の RPs をまたいだユーザー活動の相関を防ぐための pairwise identifiers は、Identity Provider により提供されなければならず（MUST）、Application により使用されても構いません（MAY）。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/93 に関連）

  • subject identifiers は、追加情報がない場合にはグローバルに一意ではない可能性があります。subject identifier の一意性を確保するため、RP は subject identifier と tenant identifier の両方を使用して、tenant に紐付いたグローバルに一意な subjects を作成しなければなりません（MUST）。

  • （後で削除予定：以下の箇条書きは https://github.com/openid/ipsie/issues/94 に関連）

  • IdP は、ユーザーが federation を通じて認証されるべきであることを RP に示しても構いません（MAY）。

Security Considerations

TODO Security

  • alternative authN mechanisms / break glass のセキュリティリスク

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 ]]

-00

  • Initial draft
  • IPSIE SL1 OIDC profile draft から、Network Layer Requirements と Cryptography and Secrets の節を移動した。

Acknowledgements

{:numbered="false"}

TODO IPSIE SL1 OIDC profile draft からの Network Layer Requirements と Cryptography and Secrets の初期文書化について Aaron Parecki に感謝する。IPSIE WG からのフィードバックと貢献に感謝する。