Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-12-14 01:54:28 -05:00
Code Issues Packages Projects Releases Wiki Activity
148d3df255
decentralized-id.github.io/_posts/identosphere-dump/open-standards/exchange-protocol/oidc.md
⧉ infominer 18794aca8f credentials, dids, diacc
2022-12-03 04:05:47 -05:00

25 KiB
Raw Blame History

OpenID Connect

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.

OIDC-SOIP

Self-Issued OpenID Connect Provider or  OIDC-SOIP  was created to take advantage of the fact that there are several 100,000 implementations of OpenID Connect on todays web. This method of exchange verifiable credentials leverages that infrastructure with a few small changes to support OpenID enabled sites to be able to accept verifiable credentials. Holders have wallets or agents that they use to interact with a system. The protocols to do this are being worked on jointly by the OpenID Foundation and Decentralized Identity Foundation.

Current MATTR spec for OpenID Credential Exchange: OpenID Connect Credential Provider

  • More Killer Whale Jello Salad…figuring out how credential exchange can harmonize. by Kaliya Young et al.
    • 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+
  • OpenID Connect Presentation at IIW XXXII

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?

  • Classification problem - browsers do not know it is a logout now
  • Easiest way
  • Browser asks for a user consent
  • Hard from a permission implementation perspective
  • Tim: No issues with this idea
  • If user logged into several OPs, user will not look to all the ones they log out from
  • Option2
  • Browser classifies signing-in event
  • On log out does not prompt the user and IdP has no incentives to lie
  • RPs get to determine if they want to log the user out or not
  • Whether you can swap generic frame with fenced frame, frame can see it’s own cookies
  • May not be able to pass any parameters that you need to pass; no link decoration for framed frame
  • Subdomains also considered, but not well thought out
  • Logout URL - other option to add, but more work for RP: Resource metadata. Specification - not much adoption. It just feels like a place where RP metadata could be declared which could be useful in this context of the RP defining its metadata (e.g. what IDP it uses
  • draft-jones-oauth-resource-metadata-01 - OAuth 2.0 Protected Resource Metadata (ietf.org)
  • On digression: https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png
  • Messy real-life situation - sign in to AAD with OIDC and WS-fed; register something at sign-in. From a user, same account, does not matter which protocol is used
  • What needs more to be discussed what log out means to the user
  • User does not understand when they log out from office, they also log out from Azure
  • Also a developer choice
  • Relevant one, but not much browsers can do about
  • If a bigger picture is browser wants to be in the middle, browser can do something in this area too.
  • Ugly part of logout - mechanisms to allow the range of services
  • IdP does not need to send back list of all RPs user is logging out from
  • Idea not entirely off for IdP to tell a browser from there it wants to log user out from
  • Browser have confident of the user intent
  • Prompt the user for the intent - never a good idea
  • Logout API that community can control a behaviour of
  • You call it, browser logs it, and tell where the user left of
  • Browser observes the login - passively. Heuristics - what if the browser has not seen it..
  • some of this is already starting to show up in chrome canarie
  • https://chromium-review.googlesource.com/c/chromium/src/+/2837551
  • If domain name ETLD of the issuer is the same as IdP, automatically logs out
  • […]
  • Looks like we can preserve session management if we figure out logout
  • Next would be good to see pseudo code with concrete scenario and sequence diagrams
  • Pseudo text: https://github.com/WICG/WebID/blob/main/cookies.md#logout
  • Prototype is being built
  • AOB? At IIW?
  • Understand what third party cookies actually mean - no cookies at all? Partition cookies going away. The way firefox is doing it?
  • The State of Identity on the Web Mattr

    This article discusses how the success of Open ID Connect shaped the state of identity on the web, how new web standards enable a new model, and describes a bridge between those worlds: OIDC Credential provider. This cycle perpetuates the dominance of a few major IdPs and likewise forces users to keep choosing from the same set of options or risk losing access to all of their online accounts. In addition, many of these IdPs have leveraged their role as central intermediaries to increase surveillance and user behavior tracking, not just across their proprietary services, but across a user’s entire web experience. [...] OIDC Credential Provider allows you to extend OIDC to allow IdPs to issue reusable VCs about the end-user instead of simple identity tokens with limited functionality. It allows end-users to request credentials from an OpenID Provider and manage their own credentials in a digital wallet under their control.

  • @kimdhamilton · May 25

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.

  • Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
  • Implementer’s Drafts vote announcement: Tuesday, January 18, 2022
  • Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *

The official voting period will be between Tuesday, February 1, 2022 and Tuesday, February 8, 2022, following the 45-day review of the specifications.

OAuth 2.0 - Web Authorization Protocol OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0

use of IETF Token Binding specifications with OpenID Connect and integration with FIDO relying parties and/or other strong authentication technologies.”

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!

The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect.

  • Nat describes GAIN as an overlay network on top of the Internet with all its participants identity proofed. One key benefit of the approach proposed in the white paper is that the standards required to enable this network already exist: OpenID Connect and eKYC/IDA.

A Final Specification provides intellectual property protections to implementers of the specification and is not subject to further revision.

  • Intro to OpenID Connect at IIW XXXI. It is a great overview of the key design principles of OpenID and how we got to now with the protocol
  • Identity, Unlocked... SIOP with Kristina Yasuda

    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/

To recap:

  • Front-channel logout is simple
  • …but brittle and doesn’t give good security guarantees
  • Back-channel logout is robust
  • …but difficult to implement/support, can still miss signals
  • Session Management is useful for some apps
  • …but is broken in many browsers

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

  • Have been incubated in OpenID Foundation and DIF’s joint Self-Issued OpenID Provider WG - contact Kristina (kristina.yasuda@microsoft.com for participation details)
  • Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
  • Implementer’s Drafts vote announcement: Tuesday, January 18, 2022
  • Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *

OAuth 2.0 - Web Authorization Protocol OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0

from the OpenID Summit Tokyo 2020 Keynote […] about Claims, Identity, Self-ness, Who-ness, and OpenID Connect and Decentralized Identity.

  • Continuity of a service
  • Offline Authentication
  • Speed, reduced latency
  • Choice, Portability
  • Privacy

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.