├── .github ├── workflows │ ├── LICENSE.md │ ├── update.yml │ ├── archive.yml │ ├── ghpages.yml │ └── publish.yml └── CODEOWNERS ├── LICENSE.md ├── .editorconfig ├── .gitignore ├── Makefile ├── CONTRIBUTING.md ├── README.md └── draft-ipsie-common-requirements-profile.md /.github/workflows/LICENSE.md: -------------------------------------------------------------------------------- 1 | This project is in the public domain. 2 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Automatically generated CODEOWNERS 2 | # Regenerate with `make update-codeowners` 3 | draft-saxe-ipsie-common-requirements-profile.md dean@thesax.es 4 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/deansaxe/draft-saxe-ipsie-common-requirements-profile/blob/main/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # See http://editorconfig.org 2 | 3 | root = true 4 | 5 | [*.{md,xml,org}] 6 | charset = utf-8 7 | insert_final_newline = true 8 | trim_trailing_whitespace = true 9 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .tags 2 | *.html 3 | *.pdf 4 | *.redxml 5 | *.swp 6 | *.txt 7 | *.upload 8 | *~ 9 | /.*.mk 10 | /.gems/ 11 | /.idea/ 12 | /.refcache 13 | /.venv/ 14 | /.vscode/ 15 | /*-[0-9][0-9].xml 16 | /lib 17 | /node_modules/ 18 | /versioned/ 19 | archive.json 20 | draft-saxe-ipsie-common-requirements-profile.xml 21 | Gemfile.lock 22 | package-lock.json 23 | report.xml 24 | !requirements.txt 25 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update --init 8 | else 9 | ifneq (,$(wildcard $(ID_TEMPLATE_HOME))) 10 | ln -s "$(ID_TEMPLATE_HOME)" $(LIBDIR) 11 | else 12 | git clone -q --depth 10 -b main \ 13 | https://github.com/martinthomson/i-d-template $(LIBDIR) 14 | endif 15 | endif 16 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # IPSIE Common Requirements Profile 4 | 5 | This is the working area for the individual Internet-Draft, "IPSIE Common Requirements Profile". 6 | 7 | * [Editor's Copy](https://openid.github.io/ipsie-common-requirements-profile/draft-ipsie-common-requirements-profile.html) 8 | 9 | 10 | ## Contributing 11 | 12 | See the 13 | [guidelines for contributions](https://github.com/openid/ipsie-common-requirements-profile/blob/main/CONTRIBUTING.md). 14 | 15 | Contributions can be made by creating pull requests. 16 | The GitHub interface supports creating pull requests using the Edit (✏) button. 17 | 18 | 19 | ## Command Line Usage 20 | 21 | Formatted text and HTML versions of the draft can be built using `make`. 22 | 23 | ```sh 24 | $ make 25 | ``` 26 | 27 | Command line usage requires that you have the necessary software installed. See 28 | [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). 29 | 30 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update Generated Files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update Files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v4 28 | 29 | - name: "Update Generated Files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | inputs: 10 | archive_full: 11 | description: 'Recreate the archive from scratch' 12 | default: false 13 | type: boolean 14 | 15 | jobs: 16 | build: 17 | name: "Archive Issues and Pull Requests" 18 | runs-on: ubuntu-latest 19 | permissions: 20 | contents: write 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v4 24 | 25 | # Note: No caching for this build! 26 | 27 | - name: "Update Archive" 28 | uses: martinthomson/i-d-template@v1 29 | env: 30 | ARCHIVE_FULL: ${{ inputs.archive_full }} 31 | with: 32 | make: archive 33 | token: ${{ github.token }} 34 | 35 | - name: "Update GitHub Pages" 36 | uses: martinthomson/i-d-template@v1 37 | with: 38 | make: gh-archive 39 | token: ${{ github.token }} 40 | 41 | - name: "Save Archive" 42 | uses: actions/upload-artifact@v4 43 | with: 44 | name: archive 45 | path: archive.json 46 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | permissions: 22 | contents: write 23 | steps: 24 | - name: "Checkout" 25 | uses: actions/checkout@v4 26 | 27 | - name: "Setup" 28 | id: setup 29 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 30 | 31 | - name: "Caching" 32 | uses: actions/cache@v4 33 | with: 34 | path: | 35 | .refcache 36 | .venv 37 | .gems 38 | node_modules 39 | .targets.mk 40 | key: i-d-${{ steps.setup.outputs.date }} 41 | restore-keys: i-d- 42 | 43 | - name: "Build Drafts" 44 | uses: martinthomson/i-d-template@v1 45 | with: 46 | token: ${{ github.token }} 47 | 48 | - name: "Update GitHub Pages" 49 | uses: martinthomson/i-d-template@v1 50 | if: ${{ github.event_name == 'push' }} 51 | with: 52 | make: gh-pages 53 | token: ${{ github.token }} 54 | 55 | - name: "Archive Built Drafts" 56 | uses: actions/upload-artifact@v4 57 | with: 58 | name: drafts 59 | path: | 60 | draft-*.html 61 | draft-*.txt 62 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | workflow_dispatch: 8 | inputs: 9 | email: 10 | description: "Submitter email" 11 | default: "" 12 | type: string 13 | 14 | jobs: 15 | build: 16 | name: "Publish New Draft Version" 17 | runs-on: ubuntu-latest 18 | steps: 19 | - name: "Checkout" 20 | uses: actions/checkout@v4 21 | 22 | # See https://github.com/actions/checkout/issues/290 23 | - name: "Get Tag Annotations" 24 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 25 | 26 | - name: "Setup" 27 | id: setup 28 | run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" 29 | 30 | - name: "Caching" 31 | uses: actions/cache@v4 32 | with: 33 | path: | 34 | .refcache 35 | .venv 36 | .gems 37 | node_modules 38 | .targets.mk 39 | key: i-d-${{ steps.setup.outputs.date }} 40 | restore-keys: i-d- 41 | 42 | - name: "Build Drafts" 43 | uses: martinthomson/i-d-template@v1 44 | with: 45 | token: ${{ github.token }} 46 | 47 | - name: "Upload to Datatracker" 48 | uses: martinthomson/i-d-template@v1 49 | with: 50 | make: upload 51 | env: 52 | UPLOAD_EMAIL: ${{ inputs.email }} 53 | 54 | - name: "Archive Submitted Drafts" 55 | uses: actions/upload-artifact@v4 56 | with: 57 | name: published 58 | path: "versioned/draft-*-[0-9][0-9].*" 59 | -------------------------------------------------------------------------------- /draft-ipsie-common-requirements-profile.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "IPSIE Common Requirements Profile" 3 | abbrev: "IPSIE Common Requirements" 4 | category: info 5 | 6 | docname: draft-ipsie-common-requirements-profile-latest 7 | submissiontype: "independent" 8 | number: 9 | date: 10 | v: 3 11 | # area: AREA 12 | workgroup: IPSIE Working Group 13 | keyword: 14 | - openid 15 | - ipsie 16 | venue: 17 | group: IPSIE 18 | type: Working Group 19 | mail: openid-specs-ipsie@lists.openid.net 20 | arch: https://openid.net/wg/ipsie/ 21 | github: "openid/ipsie-common-requirements-profile" 22 | latest: https://openid.github.io/ipsie-common-requirements-profile/draft-ipsie-common-requirements-profile.html 23 | 24 | author: 25 | - 26 | fullname: Dean H. Saxe 27 | organization: Full Frontal Nerdity Industries 28 | email: dean@thesax.es 29 | 30 | normative: 31 | BCP195: 32 | RFC2119: 33 | RFC8174: 34 | RFC6749: 35 | RFC6750: 36 | RFC6797: 37 | RFC7636: 38 | RFC8252: 39 | RFC8414: 40 | RFC8725: 41 | RFC9126: 42 | RFC9207: 43 | RFC9449: 44 | RFC9525: 45 | RFC9700: 46 | OpenID: 47 | title: OpenID Connect Core 1.0 incorporating errata set 2 48 | target: https://openid.net/specs/openid-connect-core-1_0.html 49 | date: December 15, 2023 50 | author: 51 | - ins: N. Sakimura 52 | - ins: J. Bradley 53 | - ins: M. Jones 54 | - ins: B. de Medeiros 55 | - ins: C. Mortimore 56 | OpenID.Discovery: 57 | title: OpenID Connect Discovery 1.0 incorporating errata set 2 58 | target: https://openid.net/specs/openid-connect-discovery-1_0.html 59 | date: December 15, 2023 60 | author: 61 | - ins: N. Sakimura 62 | - ins: J. Bradley 63 | - ins: M. Jones 64 | - ins: E. Jay 65 | NIST.FAL: 66 | title: NIST SP 800-63-4 Digital Identity Guidelines Federation Assurance Level (FAL) 67 | target: https://pages.nist.gov/800-63-4/sp800-63c/fal/ 68 | date: August 1, 2025 69 | 70 | informative: 71 | 72 | --- abstract 73 | 74 | 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. 75 | 76 | --- middle 77 | 78 | # Introduction 79 | 80 | TODO Introduction to the common requirements 81 | 82 | # Conventions and Definitions 83 | 84 | 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. 85 | 86 | # Profile 87 | 88 | ## Security Controls 89 | (to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/72) 90 | This section is non-normative. 91 | 92 | * All IPSIE compliant identity providers and applications should implement a security controls program, such as NIST SP800-53, FEDRAMP, or other relevant program. 93 | * The program should identify how personal attributes of users are stored at rest by the provider, whether an identity provider or application. 94 | * This program and its controls should be documented and made available to relevant parties in an IPSIE compliant federation. 95 | 96 | ## Network Layer Requirements 97 | 98 | ### Requirements for all endpoints 99 | 100 | To protect against network attacks, clients, authorization servers, and resource servers: 101 | 102 | * MUST only offer TLS protected endpoints and MUST establish connections to other servers using TLS; 103 | * MUST set up TLS connections using TLS version 1.2 or later; 104 | * MUST follow the recommendations for Secure Use of Transport Layer Security in [BCP195]; 105 | * SHOULD use DNSSEC to protect against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates; and 106 | * MUST perform a TLS server certificate check, as per [RFC9525]. 107 | 108 | ### Requirements for endpoints not used by web browsers 109 | 110 | For server-to-server communication endpoints that are not used by web browsers, the following requirements apply: 111 | 112 | * When using TLS 1.2, servers MUST only permit the cipher suites recommended in [BCP195]; 113 | * When using TLS 1.2, clients SHOULD only permit the cipher suites recommended in [BCP195]. 114 | 115 | ### Requirements for endpoints used by web browsers 116 | 117 | For endpoints that are used by web browsers, the following additional requirements apply: 118 | 119 | * 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. 120 | * When using TLS 1.2, servers MUST only use cipher suites allowed in [BCP195]. 121 | * Servers MUST NOT support [CORS] for the authorization endpoint, as clients must perform an HTTP redirect rather than access this endpoint directly. 122 | 123 | 124 | ## Cryptography and Secrets 125 | 126 | The following requirements apply to cryptographic operations and secrets: 127 | 128 | * Authorization servers, clients, and resource servers when creating or processing JWTs: 129 | * MUST adhere to [RFC8725]; 130 | * MUST use PS256, ES256, or EdDSA (using the Ed25519 variant) algorithms; and 131 | * MUST NOT use or accept the `none` algorithm. 132 | * RSA keys MUST have a minimum length of 2048 bits. 133 | * Elliptic curve keys MUST have a minimum length of 224 bits. 134 | * 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}}). 135 | 136 | ## Federation 137 | 138 | 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. 139 | 140 | * (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) 141 | * Identity providers and applications SHALL minimize account attribute disclosures to those required for business operations. 142 | 143 | * (to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/78) 144 | * Account linking as defined in Section 3.7.1 of [NIST.FAL] MAY be supported by RPs. 145 | * RPs MUST disable account linking by default. 146 | * RPs that allow account linking MUST follow the requirements of [NIST.FAL]. 147 | 148 | * (to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/80) 149 | * 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. 150 | * 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. 151 | * Alternative authentication mechanisms MUST meet the minimum requirements of IPSIE authentication, including the use of multifactor authentication. 152 | * Phishing resistant authentication is RECOMMENDED. 153 | * 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. 154 | 155 | * (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) 156 | * Encryption of assertions passed through the back channel MUST be offered by identity providers and MAY be used by applications. 157 | * Assertions passed through the front channel MUST be encrypted. 158 | * 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. 159 | 160 | * (to be removed later: note the following bullets are related to https://github.com/openid/ipsie/issues/93) 161 | * 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. 162 | 163 | * (to be removed later: note the following bullet is related to https://github.com/openid/ipsie/issues/94) 164 | * The IdP MAY signal to the RP that the user should be authenticated via federation. 165 | 166 | 167 | # Security Considerations 168 | 169 | TODO Security 170 | * Alternative authN mechanisms/break glass security risks 171 | 172 | # IANA Considerations 173 | 174 | This document has no IANA actions. 175 | 176 | 177 | --- back 178 | 179 | # Notices 180 | 181 | Copyright (c) 2025 The OpenID Foundation. 182 | 183 | The OpenID Foundation (OIDF) grants to any Contributor, developer, 184 | implementer, or other interested party a non-exclusive, royalty free, 185 | worldwide copyright license to reproduce, prepare derivative works from, 186 | distribute, perform and display, this Implementers Draft, Final 187 | Specification, or Final Specification Incorporating Errata Corrections 188 | solely for the purposes of (i) developing specifications, 189 | and (ii) implementing Implementers Drafts, Final Specifications, 190 | and Final Specification Incorporating Errata Corrections based 191 | on such documents, provided that attribution be made to the OIDF as the 192 | source of the material, but that such attribution does not indicate an 193 | endorsement by the OIDF. 194 | 195 | The technology described in this specification was made available 196 | from contributions from various sources, including members of the OpenID 197 | Foundation and others. Although the OpenID Foundation has taken steps to 198 | help ensure that the technology is available for distribution, it takes 199 | no position regarding the validity or scope of any intellectual property 200 | or other rights that might be claimed to pertain to the implementation 201 | or use of the technology described in this specification or the extent 202 | to which any license under such rights might or might not be available; 203 | neither does it represent that it has made any independent effort to 204 | identify any such rights. The OpenID Foundation and the contributors to 205 | this specification make no (and hereby expressly disclaim any) 206 | warranties (express, implied, or otherwise), including implied 207 | warranties of merchantability, non-infringement, fitness for a 208 | particular purpose, or title, related to this specification, and the 209 | entire risk as to implementing this specification is assumed by the 210 | implementer. The OpenID Intellectual Property Rights policy 211 | (found at openid.net) requires 212 | contributors to offer a patent promise not to assert certain patent 213 | claims against other contributors and against implementers. 214 | OpenID invites any interested party to bring to its attention any 215 | copyrights, patents, patent applications, or other proprietary rights 216 | that may cover technology that may be required to practice this 217 | specification. 218 | 219 | 220 | # Document History 221 | 222 | [[ To be removed from the final specification ]] 223 | 224 | -00 225 | 226 | * Initial draft 227 | * Moved the sections Network Layer Requirements and Cryptography and Secrets from the IPSIE SL1 OIDC profile draft. 228 | 229 | # Acknowledgements 230 | {:numbered="false"} 231 | 232 | TODO acknowledge Aaron Parecki for his initial documentation of the Network Layer Requirements and Cryptography and Secrets from the IPSIE SL1 OIDC profile draft. Acknowledge feedback and contributions from the IPSIE WG. 233 | --------------------------------------------------------------------------------