| Internet-Draft | IPSIE Common Requirements | June 2025 |
| Saxe | Expires 1 January 2026 | [Page] |
The IPSIE Common Requirements Profile is a profile of multiple common security requirements that are applicable to all IPSIE levels (SL* and IL*) and protocols. These common requirements are intended to meet the security and interoperability requirements of enterprise using one or more IPSIE profiles.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://deansaxe.github.io/ipsie-common/draft-saxe-ipsie-common-requirements-profile.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-saxe-ipsie-common-requirements-profile/.¶
Source for this draft and an issue tracker can be found at https://github.com/deansaxe/draft-saxe-ipsie-common-requirements-profile.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
TODO Introduction to the common requirements¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/72) All IPSIE compliant identity providers and applications SHOULD implement a security controls program, such as NIST SP800-53, FEDRAMP, or other relevant program. The program SHOULD identify how personal attributes of users are stored at rest by the provider, whether an identity provider or application. This program and its controls SHOULD be documented and made available to relevant parties in an IPSIE compliant federation.¶
To protect against network attacks, clients, authorization servers, and resource servers¶
MUST only offer TLS protected endpoints and MUST establish connections to other servers using TLS;¶
MUST set up TLS connections using TLS version 1.2 or later;¶
MUST follow the recommendations for Secure Use of Transport Layer Security in [BCP195];¶
SHOULD use DNSSEC to protect against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates; and¶
MUST perform a TLS server certificate check, as per [RFC9525].¶
For server-to-server communication endpoints that are not used by web browsers, the following requirements apply:¶
For endpoints that are used by web browsers, the following additional requirements apply:¶
Servers MUST use methods to ensure that connections cannot be downgraded using TLS stripping attacks. A preloaded [preload] HTTP Strict Transport Security policy [RFC6797] can be used for this purpose. Some top-level domains, like .bank and .insurance, have set such a policy and therefore protect all second-level domains below them.¶
When using TLS 1.2, servers MUST only use cipher suites allowed in [BCP195].¶
Servers MUST NOT support [CORS] for the authorization endpoint, as clients must perform an HTTP redirect rather than access this endpoint directly.¶
The following requirements apply to cryptographic operations and secrets:¶
Authorization servers, clients, and resource servers when creating or processing JWTs:¶
RSA keys MUST have a minimum length of 2048 bits.¶
Elliptic curve keys MUST have a minimum length of 224 bits.¶
Credentials not intended for handling by end-users (e.g., access tokens, refresh tokens, authorization codes, etc.) MUST be created with at least 128 bits of entropy such that an attacker correctly guessing the value is computationally infeasible (Section 10.10 of [RFC6749]).¶
IPSIE federation protocols are designed to be compliant with many of the technical controls defined in [NIST.FAL] at FAL2. The following federation requirements are derived from the FAL2 requirements and apply to all federation protocol profiles developed by the IPSIE WG.¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/77 and https://github.com/openid/ipsie/issues/81) * Identity providers and applications SHALL minimize account attribute disclosures to those required for business operations. * Personally identifiable information SHOULD be minimized, except where required to support necessary business functions, e.g. human resources, hiring. * Additional restrictions on attribute disclosure MAY be implemented through business agreements. These business agreements are out of scope for IPSIE.¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/78) * Account linking as defined in Section 3.7.1 of [NIST.FAL] MAY be supported by RPs. * RPs MUST disable account linking by default. * RPs that allow account linking MUST follow the requirements of [NIST.FAL].¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/80) * Alternative authentication mechanisms that bypass federated authentication MAY be supported by IPSIE compliant applications at all SL levels. These mechanisms are commonly known as "break-glass" accounts. * These mechanisms MUST be disabled by default and MAY be enabled on an individual user basis. The mechanism of enablement is not specified by IPSIE. * Alternative authentication mechanisms MUST meet the minimum requirements of IPSIE authentication, including the use of multifactor authentication. Phishing resistant authentication is RECOMMENDED. * Alterntive authentication mechanisms MUST be disabled through an identity provisioning protocol when the user's account is disabled or deleted from the application to prevent access to the account.¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/81 and https://github.com/openid/ipsie/issues/75) * Encryption of assertions passed through the front or back channel MUST be offered by identity providers and MAY be used by applications. * Pairwise identifiers to prevent correlation of the user's activities across multiple RPs MUST be offered by identity providers and MAY be used by applications.¶
(to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/93)¶
Subject identifiers may not be globally unique in the absence of additional information. To ensure subject identifier uniqueness RP's MUST use both the subject identifier and a tenant identifier to create globally unique subjects that are bound to the tenant.¶
(to be removed later: note the following bullet is related to https://github.com/openid/ipsie/issues/94)¶
All federation transactions MUST originate from the RP. Federation requests SHALL NOT originate from the IdP.¶
TODO Security * Alternative authN mechanisms security risks¶
This document has no IANA actions.¶
Copyright (c) 2025 The OpenID Foundation.¶
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶
[[ To be removed from the final specification ]]¶
-00¶
TODO acknowledge Aaron Parecki for his initial documentation of the Network Layer Requirements and Cryptography and Secrets from the IPSIE SL1 OIDC profile draft.¶