Binary Globe by GDj

Identity Decentralized

4 minute read

  • DID Authentication Working Group - GitHub

    Join this group to contribute to standards and technology that designs and implements authentication protocols that rely upon open standards and cryptographic protocols, including DIDs and DID Documents. This group develops specifications, protocols, and formats for data structures used for authentication.

    • Mailing list
    • Charter

      The purpose of this working group is to design, recommend and implement authentication and authorization protocols that rely upon open standards and cryptographic protocols using DIDs and DID Documents. Recommendations and development of specifications, protocols, and formats for data structures used for authentication and authorization. The Working Group’s areas of activity may include, but are not limited to, the following:

      • Define the formats and protocols necessary for authentication and authorization using DIDs, DID Documents, and verifiable credentials which we intend to recognize as formally DIF-approved.
      • Implement DIF-approved DID Auth proposals.
      • Develop tools for validation and programmatic interaction for authentication and authorization using DIDs, DID Documents,and verifiable credentials.
      • Create specifications and reference implementations that integrate current authentication and authorization protocols withDIDs, DID Documents, and verifiable credentials.
      • Security analysis and formal DIF-approved reviews of authentication and authorization protocols involving DIDs, DIDDocuments, and verifiable credentials.
  • DIDAuth WG Operating Addendum

    We are designing communications protocols specifically for use with the decentralized identifier specification at W3C (​https://www.w3.org/TR/did-core/​). The DID Core specification and the surrounding family of DID specifications (e.g ​https://w3c-ccg.github.io/did-resolution/​) represent the format for entity identification in our DID Authentication efforts.

Specs & Projects

DID Authentication Profile for SIOP

This specification defines the SIOP DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of DID for everyone who wants to have a generic way to integrate SSI wallets into their web applications.

DIDComm JS Lib \ Encrypted Envelope

A shared effort with the HL Aries project to create a standardized means of authenticated general message passing between DID controllers.

  • decentralized-identity/DIDComm-js

    Javascript (written in typescript) version of the cryptographic envelope of DIDComm. This library is built for any javascript environment that needs to . It is built on libsodium-js and follows the specs documented in the docs folder.

  • HL Aries Explainer

    There are two layers of messages that combine to enable interoperable self-sovereign agent-to-agent communication. At the highest level are DIDComm Plaintext Messages - messages sent between identities to accomplish some shared goal (e.g., establishing a connection, issuing a verifiable credential, sharing a chat). DIDComm Plaintext Messages are delivered via the second, lower layer of messaging - DIDComm Encrypted Envelopes. A DIDComm Encrypted Envelope is a wrapper (envelope) around a plaintext message to permit secure sending and routing. A plaintext message going from its sender to its receiver passes through many agents, and an encryption envelope is used for each hop of the journey

  • SSI Interaction Patterns

    While the DID Authn pattern is simple, it is not as flexible as we need in some situations. For more complicated scenarios, we can use verifiable credentials. The first scenario we’ll consider is where the same organization is issuing and verifying the credential.

  • Introduction to DID Auth for SSI with Markus Sabadello 2018-07-04 SSI-Meetup

    Markus Sabadello, CEO of Danube Tech, will talk about DID Auth, an emerging building block in the SSI ecosystem. Although the technical details of DID Auth are not well-defined at this point, its general concept is clear: With self-sovereign identity infrastructure, the most trivial and straightforward functionality for identity owners should be the ability to authenticate, i.e. to prove control of a DID in some relationship or during a transaction. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to authenticate to web sites and applications, and to establish mutually authenticated communication channels. In this webinar, we will discuss the current state of the DID Auth concept, and how it relates to other efforts such as Verifiable Credentials and agent protocols.

  • DID Auth and the Little I-am-Me 2018-09-04

    We recently published a report on “DID Auth” (PDF, MD), which summarizes ideas and possible architectures that allow you to prove that you control a certain Decentralized Identifier (DID). This report originated at the sixth Rebooting-the-Web-of-Trust workshop and is the result of a collaborative effort by several authors and contributors. There is also a webinar.

  • Introduction to DID Auth

    The term DID Auth has been used in different ways and is currently not well-defined. We define DID Auth as a ceremony where an identity owner, with the help of various components such as web browsers, mobile devices, and other agents, proves to a relying party that they are in control of a DID. This means demonstrating control of the DID using the mechanism specified in the DID Document’s “authentication” object. This could take place using a number of different data formats, protocols, and flows. DID Auth includes the ability to establish mutually authenticated communication channels and to authenticate to web sites and applications. Authorization, Verifiable Credentials, and Capabilities are built on top of DID Auth and are out of scope for this document. This paper gives on overview of the scope of DID Auth, supported protocols and flows, and the use of components of the DID Documents that are relevant to authentication, as well as formats for challenges and responses.

BCGov - GitHub

See Also


Ecosystem Overview

This page includes a breakdown of the Web Standards, Protocols,Open Source Projects, Organizations, Companies, Regions, Government and Policy surrounding Verifiable Credentials and Self Sovereign Identity.

Updated: 2024-02-26 4 minute read

Tags:

Verifiable Credentials with JSON-LD and BBS+ Signatures

BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’...

Updated: 2023-09-29 8 minute read

Tags:
BBS
Data Integrity
JSON-LD
Verifiable Credentials
W3C

Verifiable Credentials with JOSE (JWT) / COSE (CBOR)

Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key h...

Updated: 2023-09-09 12 minute read

Tags:
COSE
IANA
JOSE
JWT
Verifiable Credentials
W3C

Verifiable Credentials (ZKP-CL) Anoncreds

This credential format was created specifically to leverage the CL Signatures. JSON-JWT and JSON-LD Signatures each have their own way of representing the meaning of the attributes within a VC. JSON-JWT references an IANA registry and assumes a “closed world” authority model based on that authori...

Updated: 2023-09-29 6 minute read

Tags:
Anoncreds
Evernym
Hyperledger Foundation
IBM
IDEMIX
Sovrin Foundation
Verifiable Credentials
W3C
ZKP-CL