Making a Map of all the Working Groups Working on SSI/Decntralized ID + how it fits together + making a weekly/monthly + yearly calendar

Making A Map of All The Working Groups Working On SSI/Decentralized ID + How It Fits Together & Making a Weekly/Monthly/Yearly Calendar (Part 1)

Wednesday 7I

Convener: Kaliya Young & Pam Dingle

Notes-taker(s): Kaliya Young

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

We started out brainstorming all the groups we could think of and clustering them.

DIF

Identifiers Names and Discovery

https://identity.foundation/working-groups/identifiers-names-discovery.html

-> SideTree protocol

-> Universal Resolver

Members of the Working Group are engaged in development of protocols and systems that enable creation, resolution, and discovery of decentralized identifiers and names across underlying decentralized systems, like blockchains and distributed ledgers.

DIF Storage and Compute

https://identity.foundation/working-groups/storage-compute.html

Secure, encrypted, privacy-preserving storage and computation of data is a critical component of decentralized identity systems. As with identifiers and names must be self-sovereign to the owning entity, a user's identity data must remain private, only accessible to the entities they allow. DIF members are actively developing specs and reference implementations for provider-agnostic, run-anywhere solutions that provides these features.

DIF Claims and Credentials

BiWeekly on Thursday

https://identity.foundation/working-groups/claims-credentials.html

Join this group to contribute to the standards and technology that create, exchange, and verify claims and credentials in a decentralized identity ecosystem. For example, a cryptographically verifiable credential that proves an individual has a college degree or is of a certain age. Our members focus on specs that are vendor agnostic and based on industry standards.

DIF Security <- New

DIDAuth

We will have the DIF DID Auth WG page soon. Meetings are bi-weekly: Next meeting is May 23th, 7-8 pm (CEST) - In the meantime, the group agreed to have the following charter and scope:

The purpose of this working group is to design, recommend and implement a universal authentication protocol that relies upon open standards and cryptographic protocols, including DIDs and DID Documents.

Recommendations and development of specifications, protocols, and formats for data structures used for authentication. The Working Group’s areas of activity may include, but are not limited to, the following: 

- Define the formats and protocols necessary for authentication using DIDs and DID Documents which we intend to recognize as formally DIF-approved

- Implement DIF-approved DID Auth proposal

- Develop tools for validation and programmatic interaction with DID Auth.

Interop Project

Indy

https://github.com/hyperledger/indy-node#about-indy-node

Hyperledger Indy is a distributed ledger, purpose-built for decentralized identity. It provides tools, libraries, and reusable components for creating and using independent digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other “silo.”

AREIS (Indy Agent) -

https://github.com/hyperledger/indy-agent

Agents come in all varieties. Some are simple and static; these might be appropriate for IoT use cases that are hard-wired for a single connection. Others are complex and cloud-based, suitable for enterprise use. Still others run on mobile devices for individual users.

Wednesday Noon Pacific

Indy SDK

Wednesday 7am

Peer/Pariwise

W3C

Credentials Community Group

https://www.w3.org/community/credentials/

The mission of the W3C Credentials Community Group is to explore the creation, storage, presentation, verification, and user control of credentials. We focus on a verifiable credential (a set of claims) created by an issuer about a subject—a person, group, or thing—and seek solutions inclusive of approaches such as: self-sovereign identity; presentation of proofs by the bearer; data minimization; and centralized, federated, and decentralized registry and identity systems. Our tasks include drafting and incubating Internet specifications for further standardization and prototyping and testing reference implementations.

Part of this Group meets in

DID Spec and DID Resolution Spec

Weekly Meetings

https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/edit#

Will become the DID Working Group

Verifiable Credentials Working Group

https://www.w3.org/TR/verifiable-claims-data-model/

Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

WebAuthN

Standard: https://www.w3.org/TR/webauthn/

Working Group Page: https://www.w3.org/Webauthn/

The Web Authentication Working Group published Web Authentication: An API for accessing Public Key Credentials Level 1 (WebAuthn) as a W3C Recommendation on March 4, 2019. This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. As a core component of the FIDO Alliance’s FIDO2 set of specifications,

Activity Streams 2.0

https://www.w3.org/TR/activitystreams-core/

This specification details a model for representing potential and completed activities using the JSON format. It is intended to be used with vocabularies that detail the structure of activities, and define specific types of activities.

OpenID

OpenIDConnect Self-Issued

https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued

OpenID Connect supports Self-Issued OpenID Providers - personal, self-hosted OPs that issue self-signed ID Tokens. Self-Issued OPs use the special Issuer Identifier https://self-issued.me.

The messages used to communicate with Self-Issued OPs are mostly the same as those used to communicate with other OPs. Specifications for the few additional parameters used and for the values of some parameters in the Self-Issued case are defined in this section.

Kantara

Consent & Information Sharing Work Group

https://kantarainitiative.org/groups/ciswg/

Project VRM and other related parties wish to build a framework around which a new type of personal information can be enabled to flow, and in doing so improve the relationship between demand and supply. Our contention is that when individuals are forced to sign organization-centric privacy policies/ terms of use then this places limitations on the information that will be shared. If such constraints were removed, and capabilities built on the side of the individual, then new, rich information will flow – including actual demand data (as opposed to derived/ predicted demand). The goal of this working group is to identify and document the use cases and scenarios that illustrate the various sub-sets of user driven information, the benefits therein, and specify the policy and technology enablers that should be put in place to enable this information to flow.

Consent Management

https://kantarainitiative.org/confluence/display/consentmanagement/WG+-+Consent+Management+Solutions+Home - Consent Management Solutions are used to manage the full lifecycle of an individual’s consent for the processing of their personal data. That consent needs to be: freely given, specific, informed and unambiguous.

Consent Receipt Standard

https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification

A Consent Receipt is record of authority granted by a Personally Identifiable Information (PII) Principal to a PII Controller for processing of the Principal's PII. The record of consent is human-readable and can be represented as standard JSON. This specification defines the requirements for the creation of a consent record and the provision of a human-readable receipt. The standard includes requirements for links to existing privacy notices & policies as well as a description of what information has been or will be collected, the purposes for that collection as well as relevant information about how that information will be used or disclosed. This specification is based on current privacy and data protection principles as set out in various data protection laws, regulations and international standards.

IEEE

Blockchain for Healthcare https://transmitter.ieee.org/blockchain-in-healthcare/

IEEE Data Governance 7000 series

P7002 Data Privacy Process

https://standards.ieee.org/project/7002.html

This standard defines requirements for a systems/software engineering process for privacy oriented considerations regarding products, services, and systems utilizing employee, customer or other external user's personal data. It extends across the life cycle from policy through development, quality assurance, and value realization. It includes a use case and data model (including metadata). It applies to organizations and projects that are developing and deploying products, systems, processes, and applications that involve personal information. By providing specific procedures, diagrams, and checklists, users of this standard will be able to perform a conformity assessment on their specific privacy practices. Privacy impact assessments (PIAs) are described as a tool for both identifying where privacy controls and measures are needed and for confirming they are in place.

P7004 Child and Student Data Governance

https://standards.ieee.org/project/7004.html

The standard defines specific methodologies to help users certify how they approach accessing, collecting, storing, utilizing, sharing, and destroying child and student data. The standard provides specific metrics and conformance criteria regarding these types of uses from trusted global partners and how vendors and educational institutions can meet them.

P7005 Employment

https://standards.ieee.org/project/7005.html

The standard defines specific methodologies to help employers to certify how they approach accessing, collecting, storing, utilizing, sharing, and destroying employee data. The standard provides specific metrics and conformance criteria regarding these types of uses from trusted global partners and how vendors and employers can meet them.

P7006 Personal Data AI Agent

https://standards.ieee.org/project/7006.html - This standard describes the technical elements required to create and grant access to a personalized Artificial Intelligence (AI) that will comprise inputs, learning, ethics, rules and values controlled by individuals.

P7012 Machine Readable Privacy Terms

https://standards.ieee.org/project/7012.html

The standard identifies/addresses the manner in which personal privacy terms are proffered and how they can be read and agreed to by machines.

ISO

TC 307 Blockchain Process Policy

- Blockchain and distributed ledger technologies -- Terminology

- Blockchain and distributed ledger technologies -- Privacy and personally identifiable information protection considerations

- Blockchain and distributed ledger technologies -- Security risks, threats and vulnerabilities

- Blockchain and distributed ledger technologies -- Overview of identity management using blockchain and distributed ledger technologies

Other Things

JLINC (JSON-LD Link Contracts) for Data Sharing Governance

https://jlinc.org - The protocol is open (anyone can use it) but it is not at a standards body.

JLINC is an open protocol for sharing data protected by an agreement on the terms under which the data is being shared. The agreement is known as an Information Sharing Agreement, and can be a reference to a standardized agreement (a Standard Information Sharing Agreement or SISA) or a one-off specialized contract. The base profile is HTTP-based, but any protocol that affords methods for initiating and responding to data transactions, along with metadata (headers) accompanying those interactions could be adapted.

NIST 800-63-3

ERC 725

FIDO

Then we organized it into a map of where the different groups and their work fit in a map of the ecosystem.