What are OpenID Specifications
OpenID specifications are developed by working groups in three phases: Drafts, Implementer’s Drafts, and Final Specifications. Implementer’s Drafts and Final Specifications provide intellectual property protections to implementers. Final Specifications are OpenID Foundation standards.
Final Specifications
- Financial-grade API Security Profile (FAPI) 1.0 – Part 1: Baseline – A secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability.
- Financial-grade API Security Profile (FAPI) 1.0 – Part 2: Advanced – A highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability.
- JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) – This specification was created to bring some of the security features defined as part of OpenID Connect to OAuth 2.0
- OpenID Connect Core – Defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of claims to communicate information about the End-User
- OpenID Connect Discovery – Defines how clients dynamically discover information about OpenID Providers
- OpenID Connect Dynamic Client Registration – Defines how clients dynamically register with OpenID Providers
- OAuth 2.0 Multiple Response Types – Defines several specific new OAuth 2.0 response types
- OAuth 2.0 Form Post Response Mode – Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User-Agent using HTTP POST
- OpenID 2.0 to OpenID Connect Migration 1.0 – Defines how to migrate from OpenID 2.0 to OpenID Connect
- OpenID Connect RP-Initiated Logout – Defines how a Relying Party requests that an OpenID Provider log out the End-User
- OpenID Connect Session Management – Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
- OpenID Connect Front-Channel Logout – Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
- OpenID Connect Back-Channel Logout – Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
- OpenID Connect Core Error Code unmet_authentication_requirements – Defines the unmet_authentication_requirements authentication response error code
- Initiating User Registration via OpenID Connect – Defines the prompt=create authentication request parameter
Specifications with Implementer's Drafts
- Token Bound Authentication – (Optional) Defines how to apply Token Binding to OpenID Connect ID Tokens
– Most recent Implementer’s Draft - EAP ACR Values – (Optional) Enables OpenID Connect RPs to request that specific authentication context classes be applied to authentications performed and for OPs to inform RPs whether these requests were satisfied
– Most recent Implementer’s Draft
- OpenID Connect for Identity Assurance 1.0. – Defines an extension to OpenID Connect for providing Relying Parties with identity information, i.e., Verified Claims, along with an explicit statement about the verification status of these Claims (what, how, when, according to what rules, using what evidence).
– Most recent Implementer’s Draft
- Financial-grade API: Client Initiated Backchannel Authentication Profile – FAPI CIBA is a profile of the OpenID Connect’s CIBA specification that supports the decoupled flow
– Most recent Implementer’s Draft - FAPI 2.0 Security Profile – FAPI 2.0 has a broader scope than FAPI 1.0 as it aims for complete interoperability at the interface between client and authorization server as well as interoperable security mechanisms at the interface between client and resource server
– Most recent Implementer’s Draft - FAPI 2.0 Attacker Model
– Most recent Implementer’s Draft - Grant Management for OAuth 2.0 – This profile specifies a standards based approach to managing “grants” that represent the consent a data subject has given. It was born out of experience with the roll out of PSD2 and requirements in Australia.
– Most recent Implementer’s Draft
- FastFed Core 1.0 – FastFed simplifies the administrative effort to configure identity federation between an identity provider and a hosted application. The specification defines metadata documents, APIs, and flows to enable an administrator to quickly connect two providers that support common standards such as OpenID Connect, SAML, and SCIM, and allows configuration changes to be communicated directly between the identity provider and hosted application on a recurring basis.
– Most recent Implementer’s Draft - FastFed 1.0 SAML Profile – This specification defines the requirements to implement the FastFed Enterprise SAML Profile.
– Most recent Implementer’s Draft - FastFed 1.0 SCIM Profile – This specification defines the requirements to implement the FastFed Profile for SCIM 2.0 Enterprise provisioning. This profile supports continual provisioning, update, and deprovisioning of end-users between the Identity Provider and Application Provider.
– Most recent Implementer’s Draft
- Health Relationship Trust Profile for OAuth 2.0 – This specification profiles the OAuth 2.0 protocol framework to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes – This specification profiles the OAuth 2.0 protocol scopes to be used with the FHIR protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for User-Managed Access 2.0 – This specification profiles the UMA protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft - Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) UMA 2 Resources – This specification profiles the resource types and claim types to be used with the FHIR protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain.
– Most recent Implementer’s Draft
- International Government Assurance Profile (iGov) for OAuth 2.0 – Profiles the OAuth 2.0 protocol framework to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable, but not limited to consumer-to-government deployments
– Most recent Implementer’s Draft - International Government Assurance Profile (iGov) for OpenID Connect 1.0 – Profiles the OpenID Connect protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) government and public service domains
– Most recent Implementer’s Draft
- OpenID Connect MODRNA Authentication Profile – RPs are keen to use high quality authentication methods, which can be provided by Mobile Network Operators (MNO). However a RP must be able to describe its demands for an authentication request and it must be able to do this in an interoperable way. The MODRNA Authentication Profile will specify how RP’s request a certain level of assurance for the authentication. In addition, the profile will specify an encrypted login hint token to allow for the transport of user identifiers to the OP in a privacy preserving fashion. Lastly, the profile will specify an additional message parameter intended to serve as an interlock between the user’s consumption device and authentication device.
– Most recent Implementer’s Draft - OpenID Connect Account Porting – This specification defines mechanisms to support a user porting from one OpenID Connect Provider to another, such that relying parties can automatically recognize and verify the change.
– Most recent Implementer’s Draft - OpenID Connect User Questioning API – This specification defines an API offered by an OpenID Provider (OP) that can be used by an application to send a question to a user of the OP. The user does not need to be interacting with the application when the question is asked. The user’s answer is returned asynchronously, digitally-signed by the OP.
– Most recent Implementer’s Draft
- OpenID Federation – Defines how sets of parties can establish trust by utilizing a Federation Operator
– Most recent Implementer’s Draft - Self-Issued OpenID Provider V2 – Enables End-users to use OpenID Providers (OPs) that they control
– Most recent Implementer’s Draft - OpenID for Verifiable Presentations – This specification defines a mechanism on top of OAuth 2.0 to allow presentation of claims in the form of verifiable credentials as part of the protocol flow
– Most recent Implementer’s Draft
- OpenID Connect Native SSO for Mobile Apps – Enables native applications by the same vendor to share login information
– Most recent Implementer’s Draft
- OpenID Shared Signals and Events Framework Specification 1.0 – This Shared Signals and Events (SSE) Framework enables sharing of signals and events between cooperating peers. It enables multiple applications such as Risk Incident Sharing and Coordination (RISC) and the Continuous Access Evaluation Profile ([CAEP])
– Most recent Implementer’s Draft - OpenID Continuous Access Evaluation Profile 1.0 – Defines the Continuous Access Evaluation Profile (CAEP) of the Shared Signals and Events Framework [SSE-FRAMEWORK]. It specifies a set of event types conforming to the SSE Framework. These event types are intended to be used between cooperating Transmitters and Receivers such that Transmitters may send continuous updates using which Receivers can attenuate access to shared human or robotic users, devices, sessions and applications.
– Most recent Implementer’s Draft - OpenID RISC Profile Specification 1.0 – Defines the Risk Incident Sharing and Coordination (RISC) Event Types based on the Shared Signals and Events (SSE) Framework. Event Types are introduced and defined in Security Event Token (SET).
– Most recent Implementer’s Draft
Obsolete Drafts
- OpenID Authentication 2.0 (txt)
- OpenID Attribute Exchange 1.0 (txt)
- OpenID Provider Authentication Policy Extension 1.0 (txt)
- OpenID Simple Registration Extension 1.0 (txt)
- Yadis Discovery Protocol (Developed separately from OpenID, though used in OpenID 2.0)
- OpenID Simple Registration Extension 1.1 – Draft 1 (txt)
- Contract Exchange 1.0