1F/ Open ID for SSI 101 (aka SJOP w/Demo)

From IIW

OpenID for SSI


Session Convener: Torsten & Kristina

Notes-taker(s): Hannah Sutor

Tags / links to resources / technology discussed, related to this session:

https://de.slideshare.net/TorstenLodderstedt/openid-for-ssi


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Want to leverage well known advantages of OpenID Connect - Simplicity and Security

Existing libraries - HTTPs and a little bit of JSON

Great for mobile applications, no firewall hassles

Not about legacy transformation - it’s about supporting SSI applications natively

Self-Issued OP v2 - users can control their own authentication methods, key material

Important: To be as broad and flexible as possible when it comes to the rest of the SSI stack Goal: To be flexible, allow any credential format, mechanism, etc

OpenID connect has a decentralized/federated architecture since the beginning -> not used only by the “big guys”

Important for the design to be as flexible and general as possible when it comes to integrating SSi into OID

Selling points are both self-hosted OPs and edge-based OIPs (e.g.,, smart cars) -> could be used in Linkedin for “checkmarked” certificates or working experiences

Key management is different between the standard model and SIOP: in the latter, the user manages their own key, and the website trusts such an identifier. It does not have any mentions of credentials yet, it is just a way for a user to IDENTIFY themselves

Credentials enter the picture with SIOP v2 + OpenID Connect 4 Verifiable Presentations -> The RP needs to verify any details, like the revocation status, which means that the verifier (or RP) has to have knowledge of the tech stack underlying the credential used in the flow


Use Cases

Why should I move to this model vs the model we have none?

  • Completely hosted locally on your device - not dependent on third party hosting
  • Authentication as edge
  • In one translation, I can present credentials from multiple issuers
    • I as a user, I already proved I work for company X, now LinkedIn can consume that and verify me

Self-Issued OP Model Instead of having trust in a third party, we have our trust in the cryptographically verifiable identifier. Opens up for verification via DID

Are DIDs replacing authorization tokens?

No. ID token and Access tokens are inherently different. DIDs are an identifier which just sends out identity token.


Benefits:

  • Format Agnostic
  • Passing `presentation_defiition` PE object by value or by reference
  • Support for trust schemes -
  • Dynamic SIOP discovery and invocation via HTTPS URLs (enables use of app/universal links and web wallets)
  • Leverages all OpenID Connect flows. Can be locally hosted, cloud components, or cloud-based
  • Cross device flow enabled - “I’m starting here, but I’m presenting a credential that’s on my phone”
  • Leverages OpenID connect metadata for verifiers and wallet management


Demo Extending existing wallet. Built on top of Indy SDK to come up with most incremental solution

  • Use Wallet to log into NextCloud
  • Goal: all members in consortium can use wallet for logging into NextCloud
  • QR code contain SIOP request
  • Wallet shows you where data is being sent. Data is sent directly from Wallet to verifier using HTTPS

Goal: Interoperability.

Retrieved from "https://iiw.identitycommons.net/index.php?title=1F/_Open_ID_for_SSI_101_(aka_SJOP_w/Demo)&oldid=24173"