Unless issues are identified during the review that the working group believes must be addressed by revising the drafts, this review period will be followed by a seven-day voting period during which OpenID Foundation members will vote on whether to approve these drafts as OpenID Final Specifications.
Because what we need is interoperable - issuance - issue-> holder holder -> verifier some conversation about SIOP - has not been the focus of the discussion. - Goal to create a bridge between
- the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
- Aries protocols run on top of DIDComm
- If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
- Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
- So can be tested with next SVIP - testing.
- Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
- Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
The Self-Sovereign Identity System of CodeB does not only support W3C DID’s but comes also with an inbuilt OpenID Connect (OIDC) Identity Provider. OpenID Connect meets distributed Self-Sovereign Identities.
We’ve set up a release pipeline and had our first witnessed deployment for the ENS Community-Maintained OIDC IdP (more info here
How does logout in OIDC happen?
If domain name ETLD of the issuer is the same as IdP, automatically logs out
[…]
I’ve read every decentralized identity protocol so you don’t have to. They all just read like “nothing to see here, just f- right off” Oh, except for OIDC Credential Provider. Well done to them!
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.
First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started OpenID
Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *
First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved OpenID
The official voting period will be between Tuesday, February 1, 2022 and Tuesday, February 8, 2022, following the 45-day review of the specifications.
SAML 2.0 - Security Assertion Markup Language
OAuth 2.0 - Web Authorization Protocol OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0
OpenID Presentations at December 2021 OpenID Virtual Workshop
use of IETF Token Binding specifications with OpenID Connect and integration with FIDO relying parties and/or other strong authentication technologies.”
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.
The OpenID Foundation membership has approved the following MODRNA specification as an OpenID Final Specification:
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!
OpenID Connect Working Group (PowerPoint) (PDF)
OpenID Connect Presentation at IIW XXXIII Mike Jones
Introduction to OpenID Connect (PowerPoint) (PDF)
The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect.
First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved OpenID
A Final Specification provides intellectual property protections to implementers of the specification and is not subject to further revision.
As a discovery mechanism to invoke a Self-Issued OP, the discussion on the podcast covered the usage of a custom schema ‘openid://’. Alternative mechanisms to address the limitations of custom schemas are being actively explored in the WG.
The conversation meanders through deeper details, from how the current SIOP specification draft under the OpenID Foundation picks up the mission from a former attempt under DIF to encoding approaches for verifiable presentations (embedding in JWTs, LD proofs, how to represent attributes
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.
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.”
Described at: https://openid.net/connect/
OpenID Connect Claims Aggregation by Nat Sakimura, Edmund Jay, Kristina Yasuda 2021-04-21_OpenID Connect Claims Aggregation
https://www.slideshare.net/TorstenLodderstedt/openid-connect-4-identity-assurance-at-iiw-32
Jacob Dilles proposed to allow RPs to use handles for pre-configured eKYC requests. I filled an issue for discussion by the WG (https://bitbucket.org/openid/ekyc-ida/issues/1245/pre-configured-claims-ekyc-requests.
To recap:
On their own independent schedules, all browsers have either broken or have plans to break state sharing via cross-site iframes to limit user tracking - arguably making the Session Management approach unusable.
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.
Slides: https://www.slideshare.net/TorstenLodderstedt/openid-connect-for-w3c-verifiable-credential-objects
First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started OpenID
Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *
SAML 2.0 - Security Assertion Markup Language
OAuth 2.0 - Web Authorization Protocol OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0
follow up of the Identiverse 2019 session “SSO: Self-sovereign OpenID Connect – a ToDo list”. (Decentralized Identity, Mobile, Verified Claims & Credentials, Standards, Preeti Rastogi, Nat Sakimura)
from the OpenID Summit Tokyo 2020 Keynote […] about Claims, Identity, Self-ness, Who-ness, and OpenID Connect and Decentralized Identity.
DID chooser for SIOP by tom jones & friends
Goal is to allow folks to pick their DID they want to use for a website. “Subject choosing which DID to present”.
Use case: A user goes to an RP, and decides to register for return visits. RP can’t offer folks the Nascar Problem (too many IDP logos on the login screen).
Select a Wallet vs Select a Wallet and Identifier.
What happens when SIOP arrives? We will need a DID chooser.
Some wallets will hold credentials for multiple identifiers, some will hold only 1.
An RP offers users multiple options for registration (Google, Facebook, Yahoo…. And coming soon… Personal)
RP should disclose their ID and why they are asking the user for what data.
Options we consider:
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.
