OpenID Connect - OpenID Foundation
Main
- OpenID Connect From: OpenID Type: Page Date: 2014-02-04
- Frequently Asked Questions From: OpenID Type: Faq Date: 2014-02-20
- OpenID Certification Program From: OpenID Type: Page Date: 2015-02-18
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure verifiable, answer to the question: “What is the identity of the person currently using the browser or native app that is connected to me?”
OpenID Certified markThe OpenID Foundation enables deployments of OpenID Connect and the Financial-grade API (FAPI) Read/Write Profile to be certified to specific conformance profiles to promote interoperability among implementations. The OpenID Foundation’s certification process utilizes self-certification and conformance test suites developed by the Foundation. Certified implementations can use the “OpenID Certified” certification mark.
About
- I've read every decentralized identity protocol so you don't have to By: Kim D Hamilton Type: Tweet Date: 2021-05-25
- OpenID Connect Presentation at IIW XXXII From: Self Issued By: Mike Jones Type: Presentation Date: 2021-04-21
- OpenID Presentations at December 2021 OpenID Virtual Workshop From: Self Issued By: Mike Jones Type: Presentation Date: 2021-12-09
- OpenID Connect Working Group (PowerPoint) (PDF)
* OpenID Enhanced Authentication Profile (EAP) Working Group (PowerPoint) (PDF)
use of IETF Token Binding specifications with OpenID Connect and integration with FIDO relying parties and/or other strong authentication technologies.” - Let’s talk about digital identity with Oscar Santolalla, Nat Sakimura and Petteri Stenius From: Ubisecure By: Francesca Hobson Type: Episode Date: 2021-11-03
- Differences between SAML, OAuth & OIDC (OpenID Connect) From: Ubisecure By: Petteri Stenius Type: Post Date: 2020-08-10
- Distributed Open Identity: Self-Sovereign OpenID: A Status Report From: Identiverse By: Preeti Rastogi, Nat Sakimura Type: Video Date: 2020-08-26 Event: Identiverse
- Personal Digital Transformation and Holistic Digital Identity From: OpenID Japan Related: OpenID Type: Video Date: 2021-12-03
They all just read like “nothing to see here, just f- right off” Oh, except for OIDC Credential Provider. Well done to them!
If you have an Android phone or log in at Apple, AOL, Deutsche Telekom, Google, KDDI, Microsoft, NEC, NTT, Salesforce, Softbank, Symantec, Verizon, or Yahoo! Japan, you’re already using OpenID Connect – Many other sites and apps large and small also use OpenID Connect
the history of OpenID Connect and how it became so prevalent, with special guests Nat Sakimura, Chairman at the OpenID Foundation, and Petteri Stenius, Principal Scientist at Ubisecure. […] “New technology seldomly completely replaces the older technologies. They will form additional layers, and slowly start replacing it.”
This article is an update to the popular Difference between SAML and OAuth blog post we published in 2017. This blog expands to cover OpenID Connect (OIDC) vs OAuth 2.0 vs SAML 2.0 (Security Assertion Markup Language).
This session will provide an overview of the development since then and brings the audience up-to-speed on what is happening in the space including Demo of such implementations. It is a follow up of the Identiverse 2019 session “SSO: Self-sovereign OpenID Connect – a ToDo list”.
from the OpenID Summit Tokyo 2020 Keynote […] about Claims, Identity, Self-ness, Who-ness, and OpenID Connect and Decentralized Identity.
Organization
- Announcing GAIN: Global Assured Identity Network From: personal By: Nat Sakimura Type: Post Date: 2021-09-14
- DIF and OIDF cooperation From: DIF Type: Post Date: 2020-11-09
All business entities in the network are vetted as part of the creation and maintenance of their business accounts at their hosting organization, and they cannot remain anonymous. They will be accountable. As a result, the consumer has the assurance that they will be safe to transact with them—meaning more business for the Relying Parties. All of the good actors benefit.
to work together on areas of mutual interest, allowing working groups to align and coordinate through dual-members. The first major collaboration, which has already been underway for weeks, is a process for revising the Self-Issued OpenID Connect (SIOP) chapter of the OpenID Connect (OIDC) specification
Working Group
- A/B Connect Working Group From: OpenID Type: Working group Established: 2015-02-18
- Certified OpenID Connect Implementations Featured for Developers From: OpenID Type: Page Date: 2017-02-11
- First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved From: OpenID Type: Post Date: 2022-02-08
- Self-Issued OpenID Provider v2
- OpenID Connect for Verifiable Presentations
An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. These are the first Implementer’s Drafts of these specifications. These specifications are products of the OpenID Connect Working group - OpenID Connect Client-Initiated Backchannel Authentication Flow – Core 1.0 From: OpenID By: Rodriguez Fernandez Type: Specification Date: 2021-08-01
- OpenID Connect for Verifiable Presentations From: OpenID By: Oliver Terbu Type: Specification Date: 2022-01-28
- Self-Issued OpenID Provider v2 From: OpenID By: Kristina Yasuda Type: Specification Date: 2022-01-28
- OpenID Connect for Identity Assurance 1.0 From: OpenID Type: Specification Date: 2022-08-19
- OpenID Connect for Identity Assurance – Overview & Call to Action From: OpenID Type: Post Date: 2022-08-25
- OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 From: OpenID Type: Specification Date: 2021-10-03
- The OpenID Connect Logout specifications are now Final Specifications From: Self Issued By: Mike Jones Type: Post Date: 2022-09-27
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly. OpenID Connect can also be extended to include more robust mechanisms for signing and encryption. Integration of OAuth 1.0a and OpenID 2.0 required an extension (called the OpenID/OAuth hybrid); in OpenID Connect, OAuth 2.0 capability is built into the protocol itself.
OpenID Certified markThe following OpenID Connect Implementations have attained OpenID Certification for one or more certification profiles, including an authentication profile. Their certifications are listed at https://openid.net/certification/.
OpenID Connect Client Initiated Backchannel Authentication Flow is an authentication flow like OpenID Connect. However, unlike OpenID Connect, there is direct Relying Party to OpenID Provider communication without redirects through the user’s browser. This specification has the concept of a Consumption Device (on which the user interacts with the Relying Party) and an Authentication Device (on which the user authenticates with the OpenID Provider and grants consent). This specification allows a Relying Party that has an identifier for a user to obtain tokens from the OpenID Provider. The user starts the flow with the Relying Party at the Consumption Device, but authenticates and grants consent on the Authentication Device
This specification defines an extension of OpenID Connect to allow presentation of claims in the form of W3C Verifiable Credentials as part of the protocol flow in addition to claims provided in the id_token and/or via UserInfo responses.
This specification extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User’s local control. End-Users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the RPs. This allows users to interact with RPs directly, without relying on third-party providers or requiring the End-User to operate their own hosted OP infrastructure.
This specification defines an extension to OpenID Connect [OpenID] 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). This specification is aimed at enabling use cases requiring strong assurance, for example, to comply with regulatory requirements such as Anti-Money Laundering laws or access to health data, risk mitigation, or fraud prevention.
OpenID Connect for Identity Assurance is primarily focussed on addressing use-cases where the details of the assurance process used to verify and validate the end-users identity need to be explicitly communicated.
The working group believes it’s a good fit for account opening, staff on-boarding, account recovery and access to restricted services where communication of how the underlying identity was established is needed.
This specification enables OpenID Connect Relying Parties to request that specific authentication context classes be applied to authentications performed and for OpenID Providers to inform Relying Parties whether these requests were satisfied. Specifically, an authentication context class reference value is defined that requests that phishing-resistant authentication be performed and another is defined that requests that phishing-resistant authentication with a hardware-protected key be performed. These policies can be satisfied, for instance, by using W3C scoped credentials or FIDO authenticators.
The OpenID Connect Logout specifications are now Final Specifications
Thanks to all who helped us reach this important milestone! This was originally announced on the OpenID blog.
Verifiable Credentials
- Use-cases: OIDC for Verifiable Credentials - How do you want to use Identity Provider you control? From: IDCommons By: Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker Type: Session notes Date: 2021-05-07 Event: IIW
- OpenID Connect for W3C Verifiable Credential Objects From: IDCommons By: Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker Type: Session notes Date: 2021-05-06 Event: IIW
- OpenID Connect Claims Aggregation From: IDCommons By: Nat Sakimura, Edmund Jay, Kristina Yasuda Type: Session notes Date: 2021-05-06 Event: IIW
- The Era of Self-Sovereign Identity From: Chakaray Type: Post Date: 2020-12-01
- How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding By: Pranav Kirtani Type: Post Date: 2021-07-18
- SIOP Use-cases - IIW Spring 2021 From: personal By: Kristina Yasuda Type: Presentation Date: 2021 Event: IIW
- Continuity of a service
* Offline Authentication
* Speed, reduced latency
* Choice, Portability
* Privacy - OIDC with SIOPv2 and DIF Presentation Exchange From: Sphereon Type: Video Date: 2021-10-12
- Using OpenID4VC for Credential Exchange; Technometria - Issue #62 From: personal By: Phil Windley Type: Post Date: 2022-10-11
- DID chooser for SIOP From: IDCommons By: Tom Jones Type: Session notes Date: 2021-05-06 Event: IIW
We talk about users controlling their own identities, but what does it really mean in “real-life”?
For example, in OpenID Connect, what are the real-life use-cases and concrete needs to move from Identity Providers offered by Identity Companies to users controlling their own Identity Provider
Have been incubated in OpenID Foundation and DIF’s joint Self-Issued OpenID Provider WG - contact Kristina ([email protected] for participation details)
This session discussed how OIDC Claims Aggregation Draft solves certain problems left open in Connect-Core: 1/ How to get a token from CP is hand-wavy; 2/ No specified method to down scope the userinfo of the CP; 3/ No way to provide a binding information between CP:sub and IdP:sub.
VC-AuthN OIDC uses the OpenID connect standards to easily integrate with the supported systems and also provides a way to authenticate using the verifiable credentials, giving the control back to the user. This is similar to the traditional OpenID connect, the only difference is in the token information. Rather than using the user’s information to construct the token, this uses claims in the verifiable credentials presented by the user.
Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding.
I gave the following presentation on the OpenID Connect Working Group during the September 13, 2021 OpenID Workshop at the 2021 European Identity and Cloud (EIC) conference. As I noted during the talk, this is an exciting time for OpenID Connect; there’s more happening now than at any time since the original OpenID Connect specs were created!
Extending OAuth and OIDC to support the issuance and presentation of verifiable credentials provides for richer interactions than merely supporting authentication. All the use cases we’ve identified for verifiable credentials are available in OpenID4VC as well.
Goal is to allow folks to pick their DID they want to use for a website.
“Subject choosing which DID to present”
