mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2025-08-03 03:37:01 -04:00
add org to title
This commit is contained in:
⧉ infominer
parent
6fe079c370
commit
a0564677fa
15 changed files with 7 additions and 7 deletions
|
|
@ -0,0 +1,179 @@
|
|||
---
|
||||
date: 2019-03-07
|
||||
title: Decentralized Identity Foundation - DIF
|
||||
excerpt: >
|
||||
A key piece of the decentralized identity equation is how people, organizations, and devices can be identified and located without centralized systems of identifiers (e.g. email addresses). DIF members are actively working on protocols and implementations that enable creation, resolution, and discovery of decentralized identifiers and names across decentralized systems, like blockchains and distributed ledgers.
|
||||
layout: single
|
||||
permalink: organizations/decentralized-identity-foundation/
|
||||
canonical_url: 'https://decentralized-id.com/organizations/identity-foundation/'
|
||||
redirect_from:
|
||||
- organizations/identity-foundation
|
||||
- identity-foundation.html
|
||||
- organizations/identity-foundation/
|
||||
categories: [Organizations]
|
||||
tags: ["DIF","Claims and Credentials WG","DIDComm WG","Claims and Credentials WG","Storage and Compute WG","Identifiers and Discovery WG","DIDAuth WG","Interop WG","GS1","Danube Tech","Sovrin Foundation","1Kosmos","Accenture","aetna","Authenteq","Auth0","BigchainDB","BlockPass","Blockchain Foundry","Blockstack","BC Ministry of Citizens Services","BOTLabs","Civic","Consent","Consensys","Datum","Distributed ID","diwala","Dominode","Enigma","Enterprise Ethereum Alliance","Evernym","Equinix","gamecredits","Gem","GS1","Humanized-internet","Hyperledger","ID2020","Ideo","Identos","IBM","IOTA","Jolocom","KYC-Chain","LNk-E","Mastercard","Meeco","MetaX","Microsoft","Mooti","netki","NuID","Nuggets","Ockam","Onfido","Ontology","Pillar","R_Block","R3","remme","RSA","SecureKey","sitekit","suru","Taqanu","Tierion","Transmute","Trusted key","uPort","Validatedid","Veridium","Tykn","Aries","Bitcoin","Universal Resolver"]
|
||||
last_modified_at: 2020-11-26
|
||||
---
|
||||
|
||||
>A key piece of the decentralized identity equation is how people, organizations, and devices can be identified and located without centralized systems of identifiers (e.g. email addresses). DIF members are actively working on protocols and implementations that enable creation, resolution, and discovery of decentralized identifiers and names across decentralized systems, like blockchains and distributed ledgers.
|
||||
|
||||
## Identity Foundation
|
||||
|
||||
|
||||
|
||||
* [Decentralized Identity Foundation](https://identity.foundation/) (DIF) [[**G**](https://github.com/decentralized-identity)] [[**T**](https://twitter.com/DecentralizedID)] [[**B**](https://medium.com/decentralized-identity)]
|
||||
* [DIF Organizational Materials](https://github.com/decentralized-identity/org)
|
||||
* [Identity Hubs Capabilities Perspective](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/identity-hubs-capabilities-perspective.md) - Identity Hubs currently proposed in the Decentralized Identity Foundation (DIF) are a subset of a general Decentralized Identifier (DID).
|
||||
* [On DIF Hubs and Sovrin Agents](https://forum.sovrin.org/t/on-dif-hubs-and-sovrin-agents/897?u=phil)
|
||||
* [A Universal Resolver for self-sovereign identifiers](https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c) [[**G**](https://github.com/decentralized-identity/universal-resolver)] [[**>**](#Decentralized-Identity-Foundation)]
|
||||
* [uniresolver.io](https://uniresolver.io/)
|
||||
627-masterclass-on-the-did-universal-resolver-identiverse-2018)
|
||||
* [Decentralized Identity Foundation](https://golden.com/wiki/Decentralized_Identity_Foundation) - golden.com
|
||||
|
||||
## Groups
|
||||
### Working groups
|
||||
- [Identifiers and Discovery](https://identity.foundation/working-groups/identifiers-discovery.html)
|
||||
- [Storage and Compute](https://identity.foundation/working-groups/storage-compute.html)
|
||||
- [DID Authentication](https://identity.foundation/working-groups/authentication.html)
|
||||
- [Claims and Credentials](https://identity.foundation/working-groups/claims-credentials.html)
|
||||
- [DID communication](https://identity.foundation/working-groups/did-comm.html)
|
||||
- [Sidetree](https://identity.foundation/working-groups/sidetree.html)
|
||||
- [Secure Data Storage](https://identity.foundation/working-groups/secure-data-storage.html)
|
||||
### Special Interest Groups
|
||||
- [Banking and Finance SIG](https://www.notion.so/dif/Banking-and-Finance-SIG-b2d528af578d44699aeb742ed47b81d2)
|
||||
- [Healthcare SIG](https://www.notion.so/dif/Healthcare-SIG-842bc686d12e4a508a951afc4d6df47d)
|
||||
### Open groups
|
||||
- [Glossary Project](https://identity.foundation/open-groups/glossary.html)
|
||||
- [APAC/ASEAN community call](https://dif.groups.io/g/dif-apac-asean) ([ANN](https://medium.com/decentralized-identity/decentralized-identity-meetings-for-the-apac-region-7221b9aad29))
|
||||
- [Product managers](https://dif.groups.io/g/id-productmanagers)
|
||||
|
||||
## Members
|
||||
|
||||
DIF members, who share the goal of “building an open source decentralized identity ecosystem for people, organizations, apps, and devices” include:
|
||||
• [1kosmos](https://onekosmos.com/product-details/)
|
||||
• [Accenture](https://www.accenture.com/us-en/insight-blockchain-id2020)
|
||||
• [aetna](https://www.aetna.com/)
|
||||
• [Authenteq](https://venturebeat.com/2018/08/30/authenteq-launches-blockchain-identity-verification-to-stop-online-trolls/)
|
||||
• [auth0](https://auth0.com/)
|
||||
• [BigchainDB](http://docs.bigchaindb.com/en/latest/)
|
||||
• [BlockPass](https://www.blockpass.org/downloads/BlockpassWhitepaper.v1.3.2.pdf)
|
||||
• [Blockchain-foundry](https://www.blockchainfoundry.co/blockchain-foundry-inc-announces-new-software-release-for-blockchain-based/)
|
||||
• [Blockstack](https://github.com/blockstack/blockstack-core/blob/feature/docs-bns/docs/blockstack_naming_service.md#decentralized-identifiers-dids)
|
||||
• [British Columbia Ministry of Citizens Services](https://vonx.io/about/)
|
||||
• [botlabs](https://botlabs.org/)
|
||||
• [Civic](https://www.civic.com/solutions/kyc-services/)
|
||||
• [Consent](https://sovrin.org/steward/global-consent/)
|
||||
• [Consensys](https://consensys.net/)
|
||||
• [Danube](https://github.com/projectdanube/xdi2)
|
||||
• [datum](https://datum.org/)
|
||||
• [Distributed ID](https://www.diid.io/)
|
||||
• [diwala](https://diwala.io/)
|
||||
• [Dominode](https://dominode.com/)
|
||||
• [Enigma](https://blog.enigma.co/off-chain-identity-claims-with-enigma-2d5b23c31f92)
|
||||
• [Enterprise Ethereum Alliance](https://entethalliance.org/participate/working-groups/)
|
||||
• [Evernym](https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf)
|
||||
• [Equinix](https://www.equinix.com/)
|
||||
• [gamecredits](https://medium.com/@gamecredits/introducing-blinking-blink-identity-management-on-the-blockchain-9258c7d76a8d)[[**ϟ**](https://blinking.id)]
|
||||
• [Gem](https://epicenter.tv/episode/207/)
|
||||
• [GS1](https://www.gs1.org/standards/id-keys)
|
||||
• [Humanized-internet](https://www.thehumanizedinternet.org/)
|
||||
• [Hyperledger](https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md)
|
||||
• [ID2020](https://id2020.org/manifesto/)
|
||||
• [Ideo](https://medium.com/ideo-colab/a-framework-for-identity-f7f072829cbb)
|
||||
• [identos](https://identos.com/)
|
||||
• [IBM](https://www.ibm.com/blogs/blockchain/2018/06/self-sovereign-identity-why-blockchain/)
|
||||
• [IOTA](https://medium.com/@iotasuppoter/iota-the-case-of-decentralized-digital-identity-de7b95042c12)
|
||||
• [Jolocom](https://stories.jolocom.com/jolocom-brings-blockchain-identity-to-privacy-week-berlin-acdaee665f0)
|
||||
• [KYC-Chain](https://kyc-chain.com/)
|
||||
• [LNKE](https://lnketech.com/)
|
||||
• [Mastercard](https://newsroom.mastercard.com/press-releases/mastercard-microsoft-join-forces-to-advance-digital-identity-innovatioeuns/)
|
||||
• [Meeco](https://meeco.me/)
|
||||
• [MetaX](https://adtoken.com/uploads/white-paper.pdf)
|
||||
• [Microsoft](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2DjfY)
|
||||
• [Mooti](https://mooti.co/)
|
||||
• [netki](https://bravenewcoin.com/insights/netki-launches-digital-id-solution-which-bitt-is-using-with-central-banks-in-the-caribbean)
|
||||
• [NuID](https://nuid.io/pdfs/solution-overview.pdf)
|
||||
• [Nuggets](https://www.mobilepaymentstoday.com/news/identity-and-payments-platform-nuggets-partners-with-iot-company/)
|
||||
• [Ockam](https://www.ockam.io/)
|
||||
• [Onfido](https://onfido.com/)
|
||||
• [ONTology](https://ont.io/)
|
||||
• [Pillar](https://pillarprojectfoundation.org/blog/announcing-the-pillar-project/)
|
||||
• [R_Block](https://zinc.work/)
|
||||
• [R3](https://www.gemalto.com/press/pages/gemalto-and-r3-pilot-blockchain-technology-to-put-users-in-control-of-their-digital-id.aspx)
|
||||
• [remme](https://remme.io/features)
|
||||
• [RSA](https://www.rsa.com/en-us/research-and-thought-leadership/rsa-labs)
|
||||
• [SecureKey](https://www.ibm.com/blogs/blockchain/2018/05/self-sovereign-identity-our-recent-activity-as-a-sovrin-steward/)
|
||||
• [\<sitekit>](https://www.sitekit.net/)
|
||||
• [Sovrin](https://github.com/sovrin-foundation/sovrin/blob/master/spec/did-method-spec-template.html)
|
||||
• [suru](https://surugroup.com/philosophy/suru-identity/)
|
||||
• [Taqanu](https://www.taqanu.com/)
|
||||
• [Tierion](https://medium.com/tierion/tierion-network-update-january-19-2018-fa88c6bee69f)
|
||||
• [Transmute](https://www.transmute.industries/)
|
||||
• [Trusted key](https://www.trustedkey.com/)
|
||||
• [uPort](https://github.com/uport-project/ethr-did/blob/develop/docs/index.md)
|
||||
• [Validatedid](https://www.validatedid.com/vidchain-the-future-of-digital-identity/)
|
||||
• [Veridium](https://www.veridiumid.com/)
|
||||
• [zinc](https://tykn.tech/project-zinc/)
|
||||
|
||||
### DIF Monthly Newsletter
|
||||
|
||||
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">DIF Monthly. Our new-<a href="https://twitter.com/hashtag/newsletter?src=hash&ref_src=twsrc%5Etfw">#newsletter</a>. Stay tuned & sign-up on our site: <a href="https://t.co/2kw65U4bP2">https://t.co/2kw65U4bP2</a> <a href="https://t.co/wxkbChCpVh">pic.twitter.com/wxkbChCpVh</a></p>— DIF (@DecentralizedID) <a href="https://twitter.com/DecentralizedID/status/1162408597835460608?ref_src=twsrc%5Etfw">August 16, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
|
||||
|
||||
* [Email Campaign Archive from Decentralized Identity Foundation](https://us3.campaign-archive.com/home/?u=7d1001f187a746b68d2ea0d28&id=866a6c17be)
|
||||
* [decentralized-identity/newsletter/issues/1#](https://us3.campaign-archive.com/?u=7d1001f187a746b68d2ea0d28&id=d03c08ac8b): Working Group Updates:
|
||||
* [decentralized-identity/newsletter/issues/2#](https://us3.campaign-archive.com/?u=7d1001f187a746b68d2ea0d28&id=39d596a7f0) - Working Group Updates
|
||||
* [decentralized-identity/newsletter/issues/4#](https://us3.campaign-archive.com/?u=7d1001f187a746b68d2ea0d28&id=8efd1e4a75)
|
||||
* [decentralized-identity/newsletter/issues/5#](https://us3.campaign-archive.com/?u=7d1001f187a746b68d2ea0d28&id=3dc94cb937)
|
||||
|
||||
Working Group Updates:
|
||||
* ☂️ InterOp Project - Demonstrating interoperability across various teams/project and technology stack.
|
||||
* 💡 Identifiers & Discovery - How people, organizations, and devices can be identified and located without centralized systems.
|
||||
* 💠 Storage & Compute - Secure, encrypted, privacy-preserving storage and computation of data.
|
||||
* 🛡️ Claims & Credentials - Verifying claims and assertions of identities.
|
||||
* 🔓 DID Auth - DID-based authentication specs, standards, and libraries.
|
||||
|
||||
|
||||
## /decentralized-identity - GitHub
|
||||
|
||||
* [decentralized-identity/decentralized-identity.github.io](https://github.com/decentralized-identity/decentralized-identity.github.io) - Site for the open source, community-driven group of dev and organizations working toward an interoperable, decentralized identity ecosystem
|
||||
* [decentralized-identity/org](https://github.com/decentralized-identity/org) - DIF docs, wiki, and organizational material
|
||||
* [decentralized-identity/credential-manifest](https://github.com/decentralized-identity/credential-manifest) - Format that normalizes the definition of requirements for the issuance of a credential
|
||||
* [decentralized-identity/universal-registrar](https://github.com/decentralized-identity/universal-registrar) - Specifications and implementation of a universal identifier registrar
|
||||
* [decentralized-identity/attestations](https://github.com/decentralized-identity/attestations) - Attestation API implementations for various languages and platforms.
|
||||
|
||||
### DIF - DID
|
||||
* [decentralized-identity/did-methods](https://github.com/decentralized-identity/did-methods) - DID Method specs, docs, and materials
|
||||
* [decentralized-identity/did-common-typescript](https://github.com/decentralized-identity/did-common-typescript) - A common bundle of shared code and modules for working with DIDs, DID Documents, and other DID-related activities
|
||||
* [decentralized-identity/did-security-csharp](https://github.com/decentralized-identity/did-security-csharp) - C# implementation of DID security and privacy controls
|
||||
* [decentralized-identity/did-security-typescript](https://github.com/decentralized-identity/did-security-typescript) - Typescript implementation of DID security and privacy controls
|
||||
* [decentralized-identity/did-common-java](https://github.com/decentralized-identity/did-common-java) - Shared DID Java library.
|
||||
* [decentralized-identity/ua-web-extension](https://github.com/decentralized-identity/ua-web-extension) - Basic web extension version of a DID User Agent
|
||||
* [decentralized-identity/did-recovery](https://github.com/decentralized-identity/did-recovery) - Various methods for DID recovery
|
||||
* [decentralized-identity/web-polyfills](https://github.com/decentralized-identity/web-polyfills) - Polyfills for proposed or emerging DID-centric Web APIs
|
||||
* [decentralized-identity/](https://github.com/decentralized-identity/)
|
||||
* [decentralized-identity/http-did-auth-proxy](https://github.com/decentralized-identity/http-did-auth-proxy) - Forked from bcgov/http-did-auth-proxy
|
||||
DID Auth HTTP proxy.
|
||||
|
||||
### DIF - DID-Auth
|
||||
* [decentralized-identity/did-auth-jose](https://github.com/decentralized-identity/did-auth-jose) - JOSE-based implementation of DID Authenticated Encryption
|
||||
|
||||
### DIF - Sidetree
|
||||
* [decentralized-identity/sidetree-ipfs](https://github.com/decentralized-identity/sidetree-ipfs) - IPFS module for storing and accessing Sidetree entity operation data via content addressable storage
|
||||
* [decentralized-identity/sidetree-core](https://github.com/decentralized-identity/sidetree-core) - The blockchain-agnostic server implementation of the Sidetree protocol.
|
||||
* [decentralized-identity/sidetree-bitcoin](https://github.com/decentralized-identity/sidetree-bitcoin) - Blockchain-specific code for the Sidetree-based DID Method implementation on Bitcoin
|
||||
* [decentralized-identity/ion](https://github.com/decentralized-identity/ion) - DID Method implementation using the Sidetree protocol on top of Bitcoin
|
||||
|
||||
### DIF - Hub
|
||||
* [decentralized-identity/hub-sdk-js-sample](https://github.com/decentralized-identity/hub-sdk-js-sample) - Sample app demonstrating use of the DIF Identity Hub JavaScript SDK.
|
||||
* [decentralized-identity/hub-sdk-js](https://github.com/decentralized-identity/hub-sdk-js) - JavaScript SDK for interacting with Identity Hubs
|
||||
* [decentralized-identity/hub-common-js](https://github.com/decentralized-identity/hub-common-js) - Common interfaces for working with Identity Hubs in JavaScript/TypeScript
|
||||
* [decentralized-identity/hub-node-core](https://github.com/decentralized-identity/hub-node-core) - Node.js implementation of the Identity Hub interfaces, business logic, and replication protocol.
|
||||
* [decentralized-identity/identity-hub](https://github.com/decentralized-identity/identity-hub) - Storage and compute nodes for decentralized identity data and interactions
|
||||
* [decentralized-identity/hub-node-reference](https://github.com/decentralized-identity/hub-node-reference) - The official Identity Hub reference implementation bundle for Node.js
|
||||
|
||||
### DIF - Uniresolver
|
||||
|
||||
* [decentralized-identity/universal-resolver](https://github.com/decentralized-identity/universal-resolver) - Universal Resolver implementation and drivers.
|
||||
* [decentralized-identity/universal-resolver-frontend](https://github.com/decentralized-identity/universal-resolver-frontend) - Frontend web UI for Universal Resolver
|
||||
* [decentralized-identity/universal-resolver-python](https://github.com/decentralized-identity/universal-resolver-python)
|
||||
* [decentralized-identity/universal-resolver-java](https://github.com/decentralized-identity/universal-resolver-java)
|
||||
138
_posts/web-standards/identity-foundation-DIF/2020-11-22-keri.md
Normal file
138
_posts/web-standards/identity-foundation-DIF/2020-11-22-keri.md
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
date: 2020-11-22
|
||||
title: KERI - Key Event Receipt Infrastructure
|
||||
description: The first truly fully decentralized identity system.
|
||||
excerpt: >
|
||||
An identity system based secure overlay for the Internet is presented. This includes a primary root-of-trust in self-certifying identifiers. It presents a formalism for Autonomic Identifiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI).
|
||||
layout: single
|
||||
permalink: organizations/identity-foundation/keri/
|
||||
canonical_url: 'https://decentralized-id.com/organizations/identity-foundation/keri/'
|
||||
categories: ["Web Standards"]
|
||||
tags: ["DIF","KERI","DKMI","DID","RWoT"]
|
||||
header:
|
||||
image: /images/keri-header.webp
|
||||
teaser: /images/keri-teaser.webp
|
||||
last_modified_at: 2020-11-22
|
||||
---
|
||||
|
||||
[Website](https://keri.one) - [Resources](https://keri.one/keri-resources/) - [GitHub](https://github.com/decentralized-identity/keri) - [Identifiers & Discovery WG](https://identity.foundation/working-groups/identifiers-discovery.html)
|
||||
|
||||
* [KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/KERI_WP_2.x.web.pdf) Samuel M. Smith Ph.D. v2.54 2020/10/22, v1.60 2019/07/03 [[arXiv](https://arxiv.org/abs/1907.02143)]
|
||||
> An identity system based secure overlay for the Internet is presented. This includes a primary root-of-trust in self-certifying identifiers. It presents a formalism for Autonomic Identifiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI). The primary root-of-trust are self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key-pair. These are self-contained until/unless control needs to be transferred to a new key-pair. In that event an append only chained key-event log of signed transfer statements provides end verifiable control provenance. This makes intervening operational infrastructure replaceable because the event logs may be therefore be served up by ambient infrastructure. End verifiable logs on ambient infrastructure enables ambient verifiability (verifiable by anyone, anywhere, at anytime). The primary key management operation is key rotation (transference) via a novel key pre-rotation scheme. Two primary trust modalities motivated the design, these are a direct (one-to-one) mode and an indirect (one-to-any) mode. In the direct mode, the identity controller establishes control via verified signatures of the controlling key-pair. The indirect mode extends that trust basis with witnessed key event receipt logs (KERLs) for validating events. The security and accountability guarantees of indirect mode are provided by KERIs Agreement Algorithm for Control Establishment (KACE) among a set of witnesses.
|
||||
* [Decentralized key management](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/10-ssi-key-management.pdf) Sam Smith (Manning)
|
||||
> ● Why any form of digital key management is hard\
|
||||
> ● Standardsand best practices for conventional key management\
|
||||
> ● The starting point for key management architectures: roots-of-trust\
|
||||
> ● The special challenges of decentralizedkey management\
|
||||
> ● The new tools that verifiable credentials (VCs), decentralized identifiers (DIDs), and self-sovereign identity (SSI) bring to decentralized key management\
|
||||
> ● Key management for ledger-based DID methods\
|
||||
> ● Key management for peer-based DID methods\
|
||||
> ● Fully autonomous decentralized key management with Key Event Receipt Infrastructure (KERI)
|
||||
* [UNIVERSAL IDENTIFIER THEORY](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/IdentifierTheory_web.pdf)
|
||||
> Abstract—A universal theory for identifiers is presented. This theory is based on a unified model of identifiers that include cryptographic autonomic identifiers (AIDs) and legitimized (authorized) human meaningful identifiers (LIDs). This model provides truly decentralized trust bases each derived from the cryptographic root-of-trust of a given AID. An AID is based on a self-certifying identifier (SCID) prefix. Self certifying identifiers are not human meaningful but have strong cryptographic properties. The associated self-certifying trust basis gives rise to a trust do- main for associated cryptographically verifiable non-repudiable statements. Every other type of identifier including human meaningful identifiers may then be secured in this resultant trust do- main via an end-verifiable authorization. This authorization legitimizes that human meaningful identifier as an LID though its association with an AID. The result is a secured trust domain specific identifier couplet of aid\|lid. AIDs are provided by the open standard key event receipt infrastructure (KERI). This unified model provides a systematic methodology for the design and implementation of secure decentralized identifier systems that underpin decentralized trust bases and their associated ecosystems of interactions.
|
||||
* [Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet – Sam Smith – Webinar 58](https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/) SSI-Meetup
|
||||
|
||||
{% include video id="izNZ20XSXR0" provider="youtube" %}
|
||||
|
||||
## Presentations
|
||||
|
||||
* [KERI Overview](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI2_Overview.web.pdf) Key Event Receipt Infrastructure Samuel M. Smith Ph.D. sam@keri.one https://keri.oneversion 2.54 2020/10/22
|
||||
> **Separation of Control**\
|
||||
> Shared (permissioned) ledger = shared control over shared data.
|
||||
> * Shared data = good, shared control = bad.
|
||||
> * Shared control between controller and validator may be problematic for governance, scalability, and performance.\
|
||||
> KERI = separated control over shared data.
|
||||
> * Separated control between controller and validator may provide better decentralization, more flexibility, better scalability, lower cost, higher performance, and more privacy at comparable security.
|
||||
* [The Duplicity Game: or why you can trust KERI](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/DuplicityGame_IIW_2020_A.pdf)
|
||||
> **Inconsistency vs. Duplicity**
|
||||
> - inconsistency: lacking agreement, as two or more things in relation to each other
|
||||
> - duplicity: acting in two different ways to different people concerning the same matter
|
||||
> **Internal vs. External Inconsistency**
|
||||
> - Internally inconsistent log = not verifiable.
|
||||
> - Log verification from self-certifying root-of-trust protects against internal inconsistency.
|
||||
> - Externally inconsistent log with a purported copy of log but both verifiable = duplicitous.
|
||||
> - Duplicity detection protects against external inconsistency.
|
||||
* [Key Event Receipt Infrastructure (KERI) Model for a Universal DKMI](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_Overview.pdf) - December 2019
|
||||
> **KERI Nomenclature**
|
||||
> * **self-certifying identifier**: includes public key
|
||||
> * **digital signature**: unique non-repudiable (cypher suite known)
|
||||
> * **digest**: collision resistant hash of content
|
||||
> * **signed digest**: commitment to content
|
||||
> * **controller**: controlling entity of identifier
|
||||
> * **message**: serialized data structure event: actionable message
|
||||
> * **key event**: key management operation
|
||||
> * **inception event**: unique self-signed event that creates identifier and controlling key(s)
|
||||
> * **rotation event**: self-signed uniquely ordered event from a sequence that changes the set of controlling keys
|
||||
> * **verifier**: cryptographically verifies signature(s) on an event message.
|
||||
> * **witness**: entity that may receive, verify, and store key events for an identifier. Each witness controls its own identifier used to sign key event messages, controller is a special case of witness.
|
||||
> * **receipt**: event message or reference with one or more witness signatures
|
||||
> * **key event log**: ordered record of all self-signed key event messages key event
|
||||
> * **receipt log**: ordered record of all key event receipts for a given set of witnesses
|
||||
> * **validator**: determines current authoritative key set for identifier from at least one key event (receipt) log.
|
||||
> * **judge**: determines current authoritative key set for identifier from the key event receipt logs from a set of witnesses.
|
||||
> * **pre-rotation**: commitment to next rotated key set in previous rotation or inception event
|
||||
* [KERI for Muggles IIW #31 Day 1 - Session #220 October 2020](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI_for_Muggles.pdf)
|
||||
> KERI is a new approach to decentralized identifiers and decentralized key management that promises significant benefits for SSI (self-sovereign identity) and ToIP (Trust over IP) infrastructure
|
||||
* [Verifiable Trust Bases](https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERIVerifiableTrustBases.web.pdf) Samuel M. Smith Ph.D. sam@keri.one https://keri.one version 2.53 2020/10/20 - Renewing the Web of Trust
|
||||
> * KERI enables cryptographic proof-of-control-authority (provenance) for each identifier.
|
||||
> * A proof is in the form of an identifier’s key event receipt log (KERL).
|
||||
> * KERLs are *End Verifiable*:
|
||||
> * End user alone may verify. Zero trust in intervening infrastructure.
|
||||
> * KERLs may be *Ambient Verifiable*:
|
||||
> * Anyone may verify anylog, anywhere, at anytime.
|
||||
> * KERI = self-cert root-of-trust + certificate transparency + KA2CE + recoverable + post-quantum.
|
||||
|
||||
## GitHub
|
||||
- [decentralized-identity/keri](https://github.com/decentralized-identity/keri) - Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
|
||||
- [KERI Whitepaper](https://raw.githubusercontent.com/decentralized-identity/keri/master/kids/KERI_WP.pdf)
|
||||
- [Implementation Notes for KERI](https://github.com/decentralized-identity/keri/blob/master/implementation.md) [[HackMD](https://hackmd.io/orhyiJkLT721v4PCPkvQiA?both)]
|
||||
> The interpretation of the data associated with the digest or hash tree root in the seal is independent of KERI. This allows KERI to be agnostic about anchored data semantics. Another way of saying this is that seals are data agnostic; they don’t care about the semantics of its associated data. This better preserves privacy because the seal itself does not leak any information about the purpose or specific content of the associated data. Furthermore, because digests are a type of content address, they are self-discoverable. This means there is no need to provide any sort of context or content specific tag or label for the digests. Applications that use KERI may provide discovery of a digest via a hash table (mapping) whose indexes (hash keys) are the digests and the values in the table are the location of the digest in a specific event. To restate, the semantics of the digested data are not needed for discovery of the digest within a key event sequence.
|
||||
- [decentralized-identity/keriox](https://github.com/decentralized-identity/keriox) - Rust Implementation of the KERI Core Library
|
||||
- [decentralized-identity/keripy](https://github.com/decentralized-identity/keripy) - Python Implementation of the KERI Core Libraries
|
||||
- [decentralized-identity/kerigo](https://github.com/decentralized-identity/kerigo) - Go implementation of KERI (Key Event Receipt Infrastructure)
|
||||
- [decentralized-identity/kerijs](https://github.com/decentralized-identity/kerijs) - JavaScript (nodes) Implementation of the KERI core library.
|
||||
|
||||
## Background
|
||||
|
||||
* [Resources](https://keri.one/keri-resources/)
|
||||
- [SmithSamuelM/Papers](https://github.com/SmithSamuelM/Papers/)
|
||||
* [Whitepapers](https://github.com/SmithSamuelM/Papers/tree/master/whitepapers)
|
||||
* [Presentations](https://github.com/SmithSamuelM/Papers/tree/master/presentations)
|
||||
|
||||
**Self-Certifying Identifiers**
|
||||
* Girault, M., “[Self-certifiepublic keys](https://link.springer.com/content/pdf/11007%2F3-540-46416-6_42.pdf),” EUROCRYPT 1991: Advances in Cryptology, pp. 490-497, 1991
|
||||
* Kaminsky, M. and Banks, E., “[SFS-HTTP: Securing the Web with Self-Certifying URLs](https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps),” MIT, 1999
|
||||
* Mazieres, D. and Kaashoek, M. F., “[Escaping the Evils of Centralized Control with self-certifying pathnames](http://www.sigops.org/ew-history/1998/papers/mazieres.ps),” MIT Laboratory for Computer Science, 2000
|
||||
* Mazieres, D., “[Self-certifying File System](https://pdos.csail.mit.edu/~ericp/doc/sfs-thesis.ps),” MIT Ph.D. Dissertation, 2000/06/01
|
||||
* TCG, “[Implicit Identity Based Device Attestation](https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf),” Trusted Computing Group, vol. Version 1.0, 2018/03/05
|
||||
|
||||
**Autonomic Identifiers**
|
||||
|
||||
Smith, S. M., “[Open Reputation Framework](https://github.com/SmithSamuelM/Paperblob/master/whitepapers/open-reputation-low-level-whitepaper.pdf),” vol. Version 1.2, 2015/05/13
|
||||
Smith, S. M. and Khovratovich, D., “[Identity System Essentials](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf),” 2016/03/29
|
||||
* Smith, S. M., “[Decentralized Autonomic Data (DAD) and the three R’s of Key Management](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf),” Rebooting the Web of Trust RWOT 6, Spring 2018
|
||||
* Smith, S. M., “[Key Event Receipt Infrastructure (KERI) Design and Build](https://arxiv.org/abs/1907.02143),” arXiv, 2019/07/03
|
||||
* Conway, S., Hughes, A., Ma, M. et al., “[A DID for Everything](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf),” Rebooting the Web of Trust RWOT 7, 2018/09/26
|
||||
* Stocker, C., Smith, S. and Caballero, J., “[Quantum Secure DIDs](https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf),” RWOT10, 2020/07/09
|
||||
|
||||
**Certificate Transparency**
|
||||
|
||||
Laurie, B., “[Certificate Transparency: Public, verifiable, append-only log(https://queue.acm.org/detail.cfm?id=2668154),” ACMQueue, vol. Vol 12, Issue 9, 2014/09/08
|
||||
* Google, “[Certificate Transparency](http://www.certificate-transparency.org/home),”
|
||||
* Laurie, B. and Kasper, E., “[Revocation Transparency](https://www.links.org/files/RevocationTransparency.pdf),”
|
||||
|
||||
### Related
|
||||
|
||||
* [W3C DID Security Concerns](https://github.com/SmithSamuelM/Papers/blob/master/presentations/W3C_DID_Security_Concerns.pdf) 2020/01/14
|
||||
> **Certificate Transparency Solution**
|
||||
> - Public end-verifiable append-only event log with consistency and inclusion proofs
|
||||
> - End-verifiable duplicity detection = ambient verifiability of duplicity
|
||||
> - Event log is third party infrastructure but it is not trusted because logs are verifiable.
|
||||
> - Sparse Merkle trees for revocation of certificates
|
||||
> - (related EFF SSL Observatory)
|
||||
|
||||
**Non Conformist Innovation Summit Closing Keynote #2 - Sam Smith**
|
||||
|
||||
The Economics of Its & Bits - Digital Identity - Freedom Privacy Control Security
|
||||
|
||||
{% include video id="L82O9nqHjRE" provider="youtube" %}
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
date: 2020-11-25
|
||||
title: Claims and Credentials Working Group - DIF
|
||||
description: Standards and technology that create, exchange, and verify claims and credentials in a decentralized identity ecosystem.
|
||||
excerpt: >
|
||||
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.
|
||||
permalink: organizations/decentralized-identity-foundation/wg/claims-and-credentials/
|
||||
canonical_url: https://decentralized-id.com/organizations/decentralized-identity-foundation/wg/claims-and-credentials/
|
||||
redirect_from:
|
||||
- organizations/identity-foundation/claims-and-credentials-wg/
|
||||
- organizations/identity-foundation/wg/claims-and-credentials/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["Verifiable Credentials","Claims and Credentials WG","JSON-LD","Credentials Community Group","DIF","W3C"]
|
||||
header:
|
||||
image: /images/claims-credentials-header.webp
|
||||
teaser: /images/claims-credentials-teaser.webp
|
||||
last_modified_at: 2020-11-25
|
||||
---
|
||||
|
||||
[DIF - Claims and Credentials Working Group](https://identity.foundation/working-groups/claims-credentials.html) - [GitHub](https://github.com/decentralized-identity/claims-credentials)
|
||||
|
||||
> 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.
|
||||
|
||||
## Claims and Credentials WG documentation
|
||||
|
||||
* [C&C WG Charter](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_CC_WG_charter_v1.pdf)
|
||||
> **Working Group Scope.**
|
||||
> - Claims & Credential Interoperable Formats: Develop interoperable formats for broad adoption around Claim & Credential processes within SSI. These include
|
||||
> - Static Payload Formats like: Verifiable Credential, Verifiable Presentation, CredentialSubject Schemas (building on top of the W3C formats - only if the extension is a requirement by DIF partners, see “out of scope”)
|
||||
> - Data formats that support the communication between one and more participants in regard to Credential processes. For Example: Credential Manifest (Requirements for Issuing a new Credential), Presentation Definition (Requirements for presenting existing proofs, (partial, verifiable) credentials and unverifiable data), Presentation Submission (Response format to a Presentation Definition).
|
||||
> - Documentation of existing formats and protocols that are in use or under active development by existing SSI ecosystems and industry partners. Support in unifying migrating those to more interoperable formats / standards.
|
||||
> - Claims & Credential Taxonomies: There is currently no coordinated effort to align the contexts used in the highly-flexible verifiable credentials format. For example, what is the best way to encode a KYC check, credit score, user consent, or proof of employment?
|
||||
* [CC WG Operating Addendum](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_CC_WG_Operating_Addendum_V1.pdf)
|
||||
> **Core Principles**
|
||||
> - Work on the request, creation, exchange, and verification of identity credentials or claims in avendor-agnostic manner
|
||||
> - Support the development of DIDs and Verifiable Credentials
|
||||
> - Actively support projects that demonstrate interoperable use-cases within the space of claims andcredentials utilization within self-sovereign identity systems
|
||||
> - Help community members advocate for the mainstream adoption of blockchain identity and credentials.
|
||||
> - Support industry-specific taxonomy development around credentials other identity-centric data formats
|
||||
* [Mailing list](https://dif.groups.io/g/cc-wg) - Develop interoperable formats for broad adoption around Claim & Credential processes within SSI.
|
||||
* [Meeting notes](https://www.notion.so/dif/Claims-and-Credentials-d236ac4366d54c76ba85c2f521c003e0)
|
||||
|
||||
## Specs and Projects
|
||||
|
||||
* [2019 JSON-LD Signature Suite](https://github.com/decentralized-identity/lds-ecdsa-secp256k1-2019.js)
|
||||
* [Ecdsa Secp256k1 Signature 2019](https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/) - CCG Draft Community Group Report 08 April 2020
|
||||
* [presentation-exchange](https://github.com/decentralized-identity/presentation-exchange)
|
||||
> Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions
|
||||
(Presentation Submission)
|
||||
* [presentation-request](https://github.com/decentralized-identity/presentation-request)
|
||||
> Requirements Analysis and Protocol Design for a VC Presentation Request Format
|
||||
|
||||
### [Credential Manifest](https://github.com/decentralized-identity/credential-manifest)
|
||||
|
||||
> The DID Credential Manifest is a format that aims to normalize the process of credential acquisition, wherein the issuer is able to describe the requirements the subject or participant in the credential generation process must meet for the issuer to generate the desired credential.
|
||||
|
||||
* [Explainer](https://github.com/decentralized-identity/credential-manifest/blob/master/explainer.md)
|
||||
> Creating trust between DIDs and gaining access to products, services, and systems with DIDs requires the acquisition, generation, and inspection of credentials (DID-signed data objects).
|
||||
|
||||
### [VC JSON Schemas](https://github.com/w3c-ccg/vc-json-schemas)
|
||||
|
||||
> The VC JSON Schema specification aims to provide a standardized mechanism to use JSON Schemas as the data backing for Verifiable Credentials. Though the repository lives in the W3C-CCG, this working group contains key contributors and has a vested interest in contributing to the development of the specification.
|
||||
|
||||
* [Specification](https://w3c-ccg.github.io/vc-json-schemas/)
|
||||
> The [VC_DATA_MODEL](https://www.w3.org/TR/vc-data-model/) specifies the models used for Verifiable Credentials and Verifiable Presentations, and explains the relationships between three parties: issuer, holder, and verifier. A critical piece of infrastructure out of the scope of those specifications is the Credential Schema.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
date: 2020-11-26
|
||||
title: DID Communications - DIF
|
||||
name: DIDComm
|
||||
layout: standards
|
||||
headings: ["Explainer","RFCs","Development","Implementation"]
|
||||
description: contribute to specs that embody a method for secure, private and authenticated message-based communication, where trust is rooted in DIDs and used over a wide variety of transports.
|
||||
excerpt: >
|
||||
Produce one or more high-quality specs that embody a method (“DIDComm”) for secure, private and (where applicable) authenticated message-based communication, where trust is rooted in DIDs and depends on the messages themselves, not on the external properties of the transport(s) used. The method must be usable over many means of transport, including those that are asynchronous and simplex, and ones that do not necessarily use the internet. It must support routing and relay through untrusted intermediaries, not just point-to-point delivery. In addition to the communication and protocols described above, the protocols for exchanging DIDs/keys to bootstrap such communication are within scope. These protocols can be the foundation of higher-level protocols such as credential exchange and higher-level authentication protocols.
|
||||
permalink: organizations/decentralized-identity-foundation/did-communications/
|
||||
canonical_url: https://decentralized-id.com/organizations/decentralized-identity-foundation/did-communications/
|
||||
redirect_from:
|
||||
- organizations/decentralized-identity-foundation/wg/did-comm/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["DIDComm WG","DIDComm","DIF","Aries","DID","W3C"]
|
||||
header:
|
||||
image: /images/DIDComm-header.webp
|
||||
teaser: /images/DIDComm-teaser.webp
|
||||
last_modified_at: 2023-06-03
|
||||
---
|
||||
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
date: 2020-11-26
|
||||
title: (DID) Authentication Working Group - DIF
|
||||
description: design, recommend, and implement authentication and authorization protocols that rely upon open standards and cryptographic protocols using DIDs and DID Documents.
|
||||
excerpt: >
|
||||
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.
|
||||
permalink: organizations/decentralized-identity-foundation/wg/secure-data-storage/
|
||||
canonical_url: https://decentralized-id.com/organizations/decentralized-identity-foundation/wg/secure-data-storage/
|
||||
redirect_from:
|
||||
- organizations/identity-foundation/wg/secure-data-storage/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["DIDAuth WG","DIDAuth","DIF","DID","SOIP","Aries","Verifiable Credentials","W3C","DIDComm"]
|
||||
header:
|
||||
image: /images/didauth-wg-head.webp
|
||||
teaser: /images/didauth-wg-teaser.webp
|
||||
last_modified_at: 2020-11-26
|
||||
---
|
||||
|
||||
[Webpage](https://identity.foundation/working-groups/authentication.html) - [GitHub](https://github.com/decentralized-identity/authentication-wg)
|
||||
|
||||
> 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](https://dif.groups.io/g/didauth-wg) - 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.
|
||||
* [DIDAuth WG Charter](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_DIDAuth_WG_charter_v1.pdf)
|
||||
> 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](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_DIDAuth_WG_Operating_Addendum_v1.pdf)
|
||||
> 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.
|
||||
|
||||
* [Self-Issued OpenID Connect Provider DID Profile v0.1](https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md) - DIF Working Group Draft
|
||||
> This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.
|
||||
* [decentralized-identity/did-siop/](https://github.com/decentralized-identity/did-siop/)
|
||||
* [decentralized-identity/did-siop-browser-ext](https://github.com/decentralized-identity/did-siop-browser-ext) - DID based SIOP
|
||||
|
||||
### 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](https://github.com/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](https://github.com/hyperledger/aries-rfcs/blob/master/features/0019-encryption-envelope/README.md)
|
||||
> 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](https://github.com/hyperledger/aries-rfcs/blob/master/features/0044-didcomm-file-and-mime-types/README.md#didcomm-messages-dm) are delivered via the second, lower layer of messaging - [DIDComm Encrypted Envelopes](https://github.com/hyperledger/aries-rfcs/blob/master/features/0044-didcomm-file-and-mime-types/README.md#didcomm-encrypted-envelope-dee). 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
|
||||
|
||||
## Related Resources
|
||||
|
||||
|
||||
|
||||
* [DID Auth and the Little I-am-Me](https://medium.com/@markus.sabadello/did-auth-and-the-little-i-am-me-ec14d757ff09)
|
||||
* [Introduction to DID Auth](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.md) [[**ϟ**](http://ssimeetup.org/introduction-did-auth-markus-sabadello-webinar-10/)]
|
||||
|
||||
<a href="http://ssimeetup.org/introduction-did-auth-markus-sabadello-webinar-10/"><img src="https://i.imgur.com/YNlk8RY.png"/></a>\
|
||||
http://ssimeetup.org/introduction-did-auth-markus-sabadello-webinar-10
|
||||
|
||||
|
|
@ -0,0 +1,136 @@
|
|||
---
|
||||
date: 2020-11-26
|
||||
title: Identifiers & Discovery Working Group - DIF
|
||||
description: Specifications, implementations, test suites, etc. related to creation, derivation, resolution, management, use of all forms of decentralized identifiers
|
||||
excerpt: >
|
||||
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.
|
||||
permalink: organizations/identity-foundation/identifiers-and-discovery-wg/wg/identifiers-and-discovery/
|
||||
redirect_from:
|
||||
- organizations/identity-foundation/identifiers-and-discovery-wg/
|
||||
- organizations/identity-foundation/wg/identifiers-and-discovery/
|
||||
canonical_url: https://decentralized-id.com/organizations/identity-foundation/wg/identifiers-and-discovery/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["Identifiers and Discovery WG","DID","DIF","Universal Resolver","Universal Registrar","KERI","Verifiable Credentials","JSON-LD","Ethereum","ION","BTCR","DID:PEER","ERC725","Linked Data"]
|
||||
header:
|
||||
image: /images/identifiers-discovery-head.webp
|
||||
teaser: /images/identifiers-discovery-teaser.webp
|
||||
last_modified_at: 2020-11-26
|
||||
---
|
||||
|
||||
[Webpage](https://identity.foundation/working-groups/identifiers-discovery.html) - [GitHub](https://github.com/decentralized-identity/identifiers-discovery) - [Slack](https://difdn.slack.com/messages/C4WED8JSH)
|
||||
|
||||
> 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.
|
||||
|
||||
* [I&D WG Charter](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_ID_WG_charter_v1.pdf)
|
||||
- Specifications, implementations, test suites, etc. related to creation, derivation, resolution, management, use of all forms of decentralized identifiers (i.e. including, but not limited to W3C DIDs)
|
||||
- Relationship between identifier systems (e.g. DID and domain names)
|
||||
- Relationship between identifiers and other decentralized identity building blocks (e.g. EDV)
|
||||
- Discovery protocols (e.g. for hubs, agents)
|
||||
- Establishment and maintenance of control authority over an identifier (e.g. KERI)
|
||||
- Security and trust in identifier infrastructure (e.g. Linked Data Security)
|
||||
- Work on concrete DID methods
|
||||
* [Mailing list](https://lists.identity.foundation/g/id-wg)
|
||||
> A key piece of the decentralized identity equation is how people, organizations, and devices can be identified and located without centralized systems of identifiers (e.g. email addresses). DIF members are actively working on protocols and implementations that enable creation, resolution, and discovery of decentralized identifiers and names across decentralized systems, like blockchains and distributed ledgers.
|
||||
* [Meeting page](https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md)
|
||||
> For this call, you are encouraged to turn your video on. This is a good way to build rapport given we are a large, disparate group experiencing a lot of churn.
|
||||
>
|
||||
> This document is live-edited DURING each call, and stable/authoritative copies live on our github repo under /agenda.md . Please note that we might not notice a pullrequest in time, but you are free to propose agenda items for future meetings via hackmd.
|
||||
|
||||
## Specs & Projects
|
||||
### [Universal Resolver](https://uniresolver.io/)
|
||||
|
||||
Spec and implementation of a driver-based framework that enables resolution of DIDs.
|
||||
|
||||
* [decentralized-identity/universal-resolver](https://github.com/decentralized-identity/universal-resolver)
|
||||
> A Universal Resolver is an identifier resolver that works with any decentralized identifier system, including Decentralized Identifiers (DIDs).
|
||||
* [Driver Development](https://github.com/decentralized-identity/universal-resolver/blob/master/docs/driver-development.md)
|
||||
> The Universal Resolver's function is wrapping an API around a number of co-located Docker containers running DID-method-specific drivers. The Universal Resolver is designed to support additional DID methods as they are developed by the community. The contribution for a new DID method driver consists of a Docker image which exposes an HTTP interface for resolving DIDs. New contributions are submitted as Pull Requests to the Universal Resolver (this) repository.
|
||||
* [decentralized-identity/universal-resolver-frontend](https://github.com/decentralized-identity/universal-resolver-frontend) - Frontend web UI for Universal Resolver.
|
||||
* [decentralized-identity/universal-resolver-java](https://github.com/decentralized-identity/universal-resolver-java)
|
||||
* [decentralized-identity/universal-resolver-python](https://github.com/decentralized-identity/universal-resolver-python)
|
||||
|
||||
#### Resolver Drivers
|
||||
|
||||
* [decentralized-identity/uni-resolver-driver-did-erc725](https://github.com/decentralized-identity/uni-resolver-driver-did-erc725) - A Universal Resolver driver for did:erc725 identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-ion](https://github.com/decentralized-identity/uni-resolver-driver-did-ion) - Universal Resolver Driver for Identity Overlay Network (ION) DIDs
|
||||
* [decentralized-identity/uni-resolver-driver-did-key](https://github.com/decentralized-identity/uni-resolver-driver-did-key) - A Universal Resolver driver for did:key identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-sov](https://github.com/decentralized-identity/uni-resolver-driver-did-sov) - A Universal Resolver driver for did:sov identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-stack](https://github.com/decentralized-identity/uni-resolver-driver-did-stack) - A Universal Resolver driver for did:stack identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-work](https://github.com/decentralized-identity/uni-resolver-driver-did-work) - A Universal Resolver driver for did:work identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-dns](https://github.com/decentralized-identity/uni-resolver-driver-dns) - A Universal Resolver driver for domain names.
|
||||
|
||||
### [Universal Registrar](https://uniregistrar.io/)
|
||||
Spec and implementation of a driver-based framework that enables creation/updates/deactivation of DIDs.
|
||||
|
||||
* [decentralized-identity/universal-registrar](https://github.com/decentralized-identity/universal-registrar)
|
||||
> A Universal Registrar is an identifier registrar that works with any decentralized identifier system, including Decentralized Identifiers (DIDs).
|
||||
* [Driver Development](https://github.com/decentralized-identity/universal-registrar/blob/master/docs/driver-development.md)
|
||||
> The Universal Registrar's function is wrapping an API around a number of co-located Docker containers running DID-method-specific drivers. The Universal Registrar is designed to support additional DID methods as they are developed by the community. The contribution for a new DID method driver consists of a Docker image which exposes an HTTP interface for creating/updating/deactivating DIDs. New contributions are submitted as Pull Requests to the Universal Registrar (this) repository.
|
||||
* [decentralized-identity/universal-registrar-frontend](https://github.com/decentralized-identity/universal-registrar-frontend) - Frontend web UI for Universal Registrar.
|
||||
|
||||
#### Registrar Drivers
|
||||
|
||||
* [decentralized-identity/uni-registrar-driver-did-btcr](https://github.com/decentralized-identity/uni-registrar-driver-did-btcr) - A Universal Registrar driver for did:btcr identifiers.
|
||||
* [decentralized-identity/uni-registrar-driver-did-key](https://github.com/decentralized-identity/uni-registrar-driver-did-key) - A Universal Registrar driver for did:key identifiers.
|
||||
* [decentralized-identity/uni-registrar-driver-did-sov](https://github.com/decentralized-identity/uni-registrar-driver-did-sov) - A Universal Registrar driver for did:sov identifiers.
|
||||
* [decentralized-identity/uni-registrar-driver-did-v1](https://github.com/decentralized-identity/uni-registrar-driver-did-v1) - A Universal Registrar driver for did:v1 identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-btcr](https://github.com/decentralized-identity/uni-resolver-driver-did-btcr) - A Universal Resolver driver for did:btcr identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-ccp](https://github.com/decentralized-identity/uni-resolver-driver-did-ccp) - A Universal Resolver driver for Baidu did:ccp identifiers.
|
||||
* [decentralized-identity/uni-resolver-driver-did-dom](https://github.com/decentralized-identity/uni-resolver-driver-did-dom) - A Universal Resolver driver for did:dom identifiers.
|
||||
|
||||
### .well-known DID configuration
|
||||
Spec, docs, and implementations for discovering DIDs from .well-known HTTP(S) URIs.
|
||||
|
||||
* [decentralized-identity/.well-known/](https://github.com/decentralized-identity/.well-known/)
|
||||
* [Repo Webpage](https://identity.foundation/.well-known/)
|
||||
> Making it possible to connect existing systems and Decentralized Identifiers (DIDs) is an important undertaking that can aid in bootstrapping adoption and usefulness of DIDs. One such form of connection is the ability of a DID controller to prove they are the same entity that controls an origin.
|
||||
>
|
||||
> The DID Configuration resource provides proof of a bi-directional relationship between the controller of an origin and a DID via cryptographically verifiable signatures that are linked to a DID's key material. This document describes the data format of the resource and the resource location at which origin controllers can publish their DID Configuration.
|
||||
* [Spec](https://identity.foundation/specs/did-configuration/)
|
||||
> Making it possible to connect existing systems and Decentralized Identifiers (DIDs) is an important undertaking that can aid in bootstrapping adoption and usefulness of DIDs. One such form of connection is the ability of a DID controller to prove they are the same entity that controls an Internet domain.
|
||||
>
|
||||
> The DID Configuration resource provides proof of a bi-directional relationship between the controller of an Internet domain and a DID via cryptographically verifiable signatures that are linked to a DID's key material. This document describes the data format of the resource and the resource location at which Internet domain controllers can publish their DID Configuration.
|
||||
>
|
||||
> Due to the location of the DID Configuration resource, discovery of associated Decentralized Identifiers against a domain is trivial. However, the inverse (i.e given a DID-URI discover the associated domains) is deemed out of scope.
|
||||
|
||||
|
||||
### KERI - Key Event Receipt InfrastructureSpec and implementation of an identifier and key
|
||||
rotation technology, where your primary root of trust is entropy, not
|
||||
any particular ledger.
|
||||
|
||||
* [decentralized-identity/keri](https://github.com/decentralized-identity/keri) - Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
|
||||
* [decentralized-identity/kerigo](https://github.com/decentralized-identity/kerigo) - Go implementation of KERI (Key Event Receipt Infrastructure)
|
||||
* [decentralized-identity/kerijs](https://github.com/decentralized-identity/kerijs) - JavaScript (nodes) Implementation of the KERI core library.
|
||||
* [decentralized-identity/keriox](https://github.com/decentralized-identity/keriox) - Rust Implementation of the KERI Core Library
|
||||
* [decentralized-identity/keripy](https://github.com/decentralized-identity/keripy) - Python Implementation of the KERI Core Libraries
|
||||
|
||||
### Peer DID Method Specification
|
||||
|
||||
A rich DID method that has no blockchain dependencies. The verifiable data registry is a synchronization protocol between peers.
|
||||
|
||||
* [decentralized-identity/peer-did-method-spec](https://github.com/decentralized-identity/peer-did-method-spec)
|
||||
* [Spec](https://identity.foundation/peer-did-method-spec/)
|
||||
> This document defines a "peer" DID Method that conforms to the DID Spec. The method can be used independent of any central source of truth, and is intended to be cheap, fast, scalable, and secure. It is suitable for most private relationships between people, organizations, and things. We expect that peer-to-peer relationships in every blockchain ecosystem can benefit by offloading pairwise and n-wise relationships to peer DIDs.
|
||||
|
||||
### DID Spec Extensions
|
||||
|
||||
Extension parameters, properties, and values for the DID spec registries.
|
||||
|
||||
* [decentralized-identity/did-spec-extensions](https://github.com/decentralized-identity/did-spec-extensions)
|
||||
|
||||
### Other Repositories
|
||||
|
||||
* [decentralized-identity/did-common-java](https://github.com/decentralized-identity/did-common-java) - Shared DID Java library.
|
||||
* [decentralized-identity/did-jwt](https://github.com/decentralized-identity/did-jwt) - Create and verify DID verifiable JWT's in Javascript
|
||||
* [decentralized-identity/did-jwt-vc](https://github.com/decentralized-identity/did-jwt-vc) - Create and verify W3C Verifiable Credentials and Presentations in JWT format
|
||||
* [decentralized-identity/did-resolver](https://github.com/decentralized-identity/did-resolver) - Universal did-resolver for javascript environments
|
||||
* [decentralized-identity/did-spec-extensions](https://github.com/decentralized-identity/did-spec-extensions) - Extension parameters, properties, and values for the DID spec registries.
|
||||
* [decentralized-identity/ethr-did-resolver](https://github.com/decentralized-identity/ethr-did-resolver) - DID resolver for Ethereum Addresses with support for key management
|
||||
* [decentralized-identity/horcrux](https://github.com/decentralized-identity/horcrux) - Horcrux Protocol
|
||||
* [activestorage-horcrux](https://github.com/decentralized-identity/activestorage-horcrux)
|
||||
> An ActiveStorage service option that uploads shares across one or more other storage services using Shamir Secret Sharing (via the tss-rb gem). Use it in your storage.yml file. It is not a mirror, but can be named as a storage service.
|
||||
* [decentralized-identity/context](https://github.com/decentralized-identity/context) - DIF Security Contexts & Schemas for Linked Data
|
||||
* [decentralized-identity/fuzzy-encryption](https://github.com/decentralized-identity/fuzzy-encryption) - A variant of a Fuzzy Vault cryptographic scheme designed for encrypting data with better human recovery features.
|
||||
* [decentralized-identity/jsonld-common-java](https://github.com/decentralized-identity/jsonld-common-java) - Shared JSON-LD Java library.
|
||||
* [jsonld-document-loader](https://github.com/decentralized-identity/jsonld-document-loader)
|
||||
> Document loaders enable decentralized security, interoperability and extensibility while gaurding against vendor lock in.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
date: 2020-11-26
|
||||
title: Interop Working Group - DIF
|
||||
description: Interoperability WG is a community effort to achieve decentralized identity interop.
|
||||
excerpt: >
|
||||
Community collaboration and project management on Interoperability. Develop and publish definitions of success with respect to business interoperability, at the highest level. Defining points of protocol-defined touchpoints for maximum interchangeability of components at every layer; it is assumed that over time, that number will increase, not decrease.
|
||||
|
||||
Community collaboration and project management on interoperability goal to seek the greatest interoperability in the greater good, not to pick winners. Provide feedback, input documents, members, and guidance to working groups producing standards, specifications, reference implementations and demonstrations hosted by community organizations including but not limited to IETF, W3C, W3C CCG, Hyperledger, Trust over IP.
|
||||
permalink: organizations/decentralized-identity-foundation/wg/interop/
|
||||
canonical_url: https://decentralized-id.com/organizations/decentralized-identity-foundation/wg/interop/
|
||||
redirect_from:
|
||||
- organizations/identity-foundation/wg/interop/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["Interop WG","DIF","IETF","W3C","Credentials Community Group","Hyperledger","Trust over IP"]
|
||||
header:
|
||||
image: /images/dif-interop-head.webp
|
||||
teaser: /images/dif-interop-teaser.webp
|
||||
last_modified_at: 2020-11-26
|
||||
---
|
||||
|
||||
[Webpage](https://identity.foundation/interop/) - [Wiki](https://www.notion.so/dif/Interoperability-WG-a42995c37e2a4511a10aea96cdbccc38) - [GitHub](https://github.com/decentralized-identity/interoperability)
|
||||
|
||||
> Community collaboration and project management on Interoperability. Develop and publish definitions of success with respect to business interoperability, at the highest level. Defining points of protocol-defined touchpoints for maximum interchangeability of components at every layer; it is assumed that over time, that number will increase, not decrease.
|
||||
>
|
||||
> Community collaboration and project management on interoperability goal to seek the greatest interoperability in the greater good, not to pick winners. Provide feedback, input documents, members, and guidance to working groups producing standards, specifications, reference implementations and demonstrations hosted by community organizations including but not limited to IETF, W3C, W3C CCG, Hyperledger, Trust over IP.
|
||||
|
||||
* [Interop Charter](https://docs.google.com/document/d/1a01GQVtZB7tDVcm9avS8zuYPHQzEEDtTOEh4Bqu-8Bs/edit)
|
||||
> - Develop and publish definitions of success with respect to business interoperability, expressed in functional, non-technical terms where possible.
|
||||
>
|
||||
> - Defining protocol-specified touchpoints for maximum interchangeability of components at every layer; it is assumed that over time, that number will increase, not decrease
|
||||
>
|
||||
> - Cross-Community collaboration and project management on pragmatic interoperability goals, and recommendations i.e. seeking to support the work beneficial to the most contributing organizations and allowing a healthy and interoperable competition, while striving to avoid “picking winners” or any kind of lock-in as table stakes...
|
||||
* [Mailing list](https://dif.groups.io/g/interop-wg/)
|
||||
> Interoperability WG is a community effort to achieve decentralized identity interop.
|
||||
>
|
||||
> The current focus of the group is to establish cross-community buy-in.
|
||||
- [Wiki](https://www.notion.so/dif/Interoperability-WG-a42995c37e2a4511a10aea96cdbccc38)
|
||||
* [Interoperability WG Rolling Agenda & Minutes](https://github.com/decentralized-identity/interoperability/blob/master/agenda.md)
|
||||
> For this call, you are encouraged to turn your video on. This is a good way to build rapport given we are a large, disparate group experiencing a lot of churn.
|
||||
>
|
||||
> This document is live-edited DURING each call, and stable/authoritative copies live on our github repo under /agenda.md . Please note that we might not notice a pullrequest in time, but you are free to propose agenda items for future meetings via hackmd .
|
||||
* [Input Documents + Bibliography](https://www.notion.so/dif/be6763341a014d248f655aea187d7890)
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
date: 2020-11-26
|
||||
title: Secure Data Storage WG - DIF
|
||||
description: data models for storage and transport, syntax, data at rest protection, CRUD API, access control, synchronization, and at least a minimum viable HTTP-based interface compatible with W3C DIDs/VCs.
|
||||
excerpt: >
|
||||
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.
|
||||
permalink: organizations/decentralized-identity-foundation/wg/secure-data-storage/
|
||||
canonical_url: https://decentralized-id.com/organizations/decentralized-identity-foundation/wg/secure-data-storage/
|
||||
redirect_from:
|
||||
- organizations/identity-foundation/wg/secure-data-storage/
|
||||
categories: ["Web Standards"]
|
||||
tags: ["Storage and Compute WG","DIF","Secure Data Storage","Data Hubs","W3C","Encrypted Data Vaults"]
|
||||
header:
|
||||
image: /images/secure-data-storage-head.webp
|
||||
teaser: /images/secure-data-storage-teaser.webp
|
||||
last_modified_at: 2020-11-26
|
||||
---
|
||||
|
||||
[Webpage](https://identity.foundation/working-groups/storage-compute.html) - [Wiki](https://dif.groups.io/g/sds-wg/wiki) - [GitHub](https://github.com/decentralized-identity/confidential-storage/)
|
||||
|
||||
> 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.
|
||||
|
||||
- [Mailing List](https://dif.groups.io/g/sds-wg/wiki/home)
|
||||
- [Working Group Wiki](https://lists.identity.foundation/g/sds-wg/wiki)
|
||||
> Create one or more specifications to establish a foundational layer for secure data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, CRUD HTTP API, access control, synchronization, and a minimum viable HTTP-based interface compatible with W3C DIDs/VCs.
|
||||
- [Secure Data Storage Working Group Charter](https://drive.google.com/file/d/1vf2CsD9QZstzrd6CJ4WFVHw0WKwwNLHf/view)
|
||||
> - Create one or more specifications to establish a foundational layer for secure data storage (including personal data), specifically data models for storage and transport, syntax, data at rest protection, CRUD API, access control, synchronization, and at least a minimum viable HTTP-based interface compatible with W3C DIDs/VCs.
|
||||
> - The [Identity Hubs](https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md) and [Encrypted Data Vaults](https://digitalbazaar.github.io/encrypted-data-vaults/) documents will be used as a use case, requirements, and technical input for the collaborative effort.
|
||||
|
||||
## Specs & Projects
|
||||
|
||||
The active work items that are underway in the DIF Storage and Compute Working Group
|
||||
|
||||
### Confidential Storage
|
||||
|
||||
- [decentralized-identity/confidential-storage/](https://github.com/decentralized-identity/confidential-storage/)
|
||||
- [Latest Editors Draft](https://identity.foundation/confidential-storage/)
|
||||
> We store a significant amount of sensitive data online, such as personally identifying information (PII), trade secrets, family pictures, and customer information. The data that we store is often not protected in an appropriate manner.
|
||||
>
|
||||
> This specification describes a privacy-respecting mechanism for storing, indexing, and retrieving encrypted data at a storage provider. It is often useful when an individual or organization wants to protect data in a way that the storage provider cannot view, analyze, aggregate, or resell the data. This approach also ensures that application data is portable and protected from storage provider data breaches.
|
||||
* [DIF SDS/CS WG: CS Refactoring Proposal 0.2](https://hyperonomy.com/2021/03/28/cs-refactoring-proposal/) Hyperonomy
|
||||
> 1. Latest Version of the Proposal (0.2 – March 24, 2021)
|
||||
> 2. Agent-Hub-EDV Architecture Reference Model (AHE-ARM) 0.1
|
||||
> 3. Transcription of Selected Parts of the DIF SDS/CS March 11, 2021 Zoom Call
|
||||
> 4. OSI Stack Proposal for Confidential Storage Specification
|
||||
>
|
||||
> Based on the March 11 Zoom discussion where we worked hard to discern the differences between Agents, Hubs, and EDVs (and I believe were largely successful IMO), I’ve like to propose to the SDS/CS WG that we refactor the current Confidential Storage specification into 3 separable parts/specifications. I also present a high-level roadmap (simple ordering) for how the WG might proceed if this refactoring is accepted (or at least, if the first part/first new specification is accepted).
|
||||
|
||||
### Identity Hubs (Archived)
|
||||
|
||||
Encrypted personal datastore for identity interactions and decentralized apps.
|
||||
|
||||
* [Identity Hubs](https://github.com/decentralized-identity/identity-hub/)
|
||||
* [Explainer](https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md)
|
||||
> Hubs let you securely store and share data. A Hub is a datastore containing semantic data objects at well-known locations. Each object in a Hub is signed by an identity and accessible via a globally recognized API format that explicitly maps to semantic data objects. Hubs are addressable via unique identifiers maintained in a global namespace.
|
||||
* [System Diagram](https://raw.githubusercontent.com/decentralized-identity/hubs/master/diagrams/full-system.png)
|
||||
|
||||
[](https://raw.githubusercontent.com/decentralized-identity/hubs/master/diagrams/full-system.png)
|
||||
|
||||
### Encrypted Data Vaults (Archived)
|
||||
|
||||
* [Encrypted Data Vaults](https://digitalbazaar.github.io/encrypted-data-vaults/)
|
||||
> We store a significant amount of sensitive data online, such as personally identifying information (PII), trade secrets, family pictures, and customer information. The data that we store is often not protected in an appropriate manner.
|
||||
>
|
||||
> Legislation, such as the General Data Protection Regulation (GDPR), incentivizes service providers to better preserve individuals' privacy, primarily through making the providers liable in the event of a data breach. This liability pressure has revealed a technological gap, whereby providers are often not equipped with technology that can suitably protect their customers. Encrypted Data Vaults fill this gap and provide a variety of other benefits.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
date: 2020-01-04
|
||||
title: JSON-LD
|
||||
title: JSON-LD - W3C
|
||||
name: JSON-LD
|
||||
layout: standards
|
||||
headings: ["Main","Explainer","Presentation","Working Group","Development"]
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: WebAuthN
|
||||
title: WebAuthN - W3C
|
||||
name: WebAuthN
|
||||
layout: standards
|
||||
headings: ["Main","FIDO Alliance","Working Group","Development"]
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "(DID) the Decentralized Identifier"
|
||||
title: "(DID) the Decentralized Identifier - W3C"
|
||||
name: Decentralized Identifiers
|
||||
layout: standards
|
||||
headings: ["Main","Explainer","Working Group","Literature","About DID Methods","The DID Methods","Critique","Discussion","Tools and Utilities","W3C Recommendation"]
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
date: 2020-01-10
|
||||
name: Verifiable Credentials
|
||||
name: Verifiable Credentials - W3C
|
||||
layout: standards
|
||||
headings: ["About","Comparisons","Working Group","Credentials Community Group","Claims and Credentials WG","Development","Varieties","Interoperability","Literature","Use Case","User Experience"]
|
||||
title: "Verifiable Credentials"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
date: 2020-11-09
|
||||
name: W3C
|
||||
layout: standards
|
||||
title: World Wide Web Consortium
|
||||
title: World Wide Web Consortium - W3C
|
||||
headings: ["Main","W3C ID History","ID in the Browser 2011"]
|
||||
description: An international community that develops open standards to ensure the long-term growth of the Web.
|
||||
excerpt: "First started as an IETF application area at the beginning of 1990, the Web standard stack, given its foreseen volume and applicative nature on top of the Internet protocols, quickly spun off its own forum. The W3C then laid the foundations of the Web with the development of HTML 4 and XML at the end of the last century. It still works closely with IETF today, on the HTTP or URL specifications and in other areas of common interest (e.g. crypto, security, video)."
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
date: 2020-11-27
|
||||
title: Schema.org Community Group
|
||||
title: Schema.org Community Group - W3C
|
||||
description: The Schema.org Community Group provides a forum for discussing all changes, additions and extensions to schema.org.
|
||||
excerpt: >
|
||||
The Schema.org Community Group provides a forum for discussing all changes, additions and extensions to schema.org. In addition to providing a public setting for the day to day operation of the project, it serves as the mechanism for reviewing extensions and as a liaison point for all parties developing independent extensions to the schema.org core.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: W3C Credentials Community Group
|
||||
title: Credentials Community Group - W3C
|
||||
description: "to explore the creation, storage, presentation, verification, and user control of credentials."
|
||||
excerpt: >
|
||||
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue