Since we posted in July about the availability of preliminary OpenID Connect specifications, developers have been building implementations and submitting feedback on the specs.  The specs have been revised to incorporate their feedback.  A new map of the specs is as follows: The biggest difference you’ll notice is that there is now only one spec to implement for “Minimal” clients (rather than previously three).  A number of people had asked that there be a single, simple, self-contained spec that basic relying parties could implement.  That spec is the OpenID Connect Basic Client Profile.  That’s all you need for a web-based relying party utilizing a pre-configured set of OpenID Providers. For “Dynamic” configurations, where the set of OpenID Providers is not pre-configured, Discovery and Dynamic Client Registration capabilities are added to enable RPs to discover OP endpoints and to connect with the OP selected.  This functionality is needed for “open” OpenID Connect interactions. OpenID Providers, native client applications, and clients needing more functionality than that provided by the Basic Client Profile implement the OpenID Connect Standard binding for the OpenID Connect Messages.  Finally, OPs and RPs needing session management capabilities, including logout, also implement OpenID Connect Session Management. As you can see, the current organization remains highly modular, where implementations can build and deploy only what they need.  Now that modularity is even better reflected in the way that the specs are written – particularly that there is a single, self-contained basic client specification. In closing, we’d like to thank developers for the valuable feedback provided to date.  Your input has both improved the technical content of OpenID Connect, and possibly even more importantly, made the specs simpler and easier to understand.