mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2025-01-25 22:05:59 -05:00
1522 lines
160 KiB
XML
1522 lines
160 KiB
XML
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.3">Jekyll</generator><link href="https://decentralized-id.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://decentralized-id.com/" rel="alternate" type="text/html" /><updated>2024-11-30T07:56:32+13:00</updated><id>https://decentralized-id.com/feed.xml</id><title type="html">Verifiable Credentials and Self Sovereign Identity Web Directory</title><subtitle>The largest, and longest-running, web directory surrounding decentralized identity and verifiable credentials.</subtitle><author><name>DIDecentral</name></author><entry><title type="html">Ecosystem Overview</title><link href="https://decentralized-id.com/ecosystem/" rel="alternate" type="text/html" title="Ecosystem Overview" /><published>2023-10-05T00:00:00+13:00</published><updated>2024-02-26T00:00:00+13:00</updated><id>https://decentralized-id.com/ecosystem</id><content type="html" xml:base="https://decentralized-id.com/ecosystem/"><p class="notice--info"><strong>Note to reader</strong>
|
||
<strong>This is a Work in Progress, and should not be taken as authoritative or comprehensive.</strong>
|
||
<em>Internal Links in Italic</em></p>
|
||
|
||
<h2 id="open-standards">Open Standards</h2>
|
||
<h3 id="decentralized-identifiers"><a href="/web-standards/w3c/decentralized-identifier/"><em>Decentralized Identifiers</em></a></h3>
|
||
|
||
<ul>
|
||
<li><a href="/web-standards/w3c/decentralized-identifier/#Explainer"><em>Explainer</em></a></li>
|
||
<li><a href="/web-standards/w3c/decentralized-identifier/#literature"><em>Literature</em></a></li>
|
||
<li><a href="/web-standards/w3c/decentralized-identifier/did-methods/"><em>DID</em> Methods</a></li>
|
||
<li><a href="/web-standards/w3c/decentralized-identifier/#Supporting"><em>Supporting</em> Tech</a>
|
||
<ul>
|
||
<li><a href="/projects/decentralized-identity-foundation/did-authentication/"><em>DIDAuth</em></a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/self-sovereign-identity/critique-caution/"><em>Critique</em></a></li>
|
||
</ul>
|
||
|
||
<h3 id="verifiable-credentials">Verifiable Credentials</h3>
|
||
|
||
<ul>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/#About"><em>Explainer</em></a></li>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/#Comparisons"><em>Comparisons</em></a></li>
|
||
<li>Varieties
|
||
<ul>
|
||
<li>Data Integrity
|
||
<ul>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs/"><em>JSON</em>-LD LD-Proof</a> (w3c)</li>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs/"><em>JSON</em>-LD ZKP BBS+</a> (w3c)</li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/jose-jwt+cose-cbor/"><em>JOSE / COSE</em></a>
|
||
<ul>
|
||
<li><a href="https://www.ietf.org/id/draft-terbu-sd-jwt-vc-02.html">JSON SD-JWT</a> (ietf)</li>
|
||
<li><a href="https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof-00.html">JWP</a> (ietf)</li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/zkp-cl_anoncreds/"><em>ZKP-CL</em></a> (Hyperledger)</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="related">Related</h3>
|
||
|
||
<ul>
|
||
<li><a href="/web-standards/w3c/json-ld/"><em>JSON-LD</em></a> (W3C)</li>
|
||
<li><a href="https://datatracker.ietf.org/doc/html/rfc8259">JSON</a> (IETF)</li>
|
||
<li><a href="/web-standards/w3c/verifiable-credentials/data-integrity-bbs+/#blum-blum-shub"><em>BBS</em></a> (SIAM 1986)</li>
|
||
</ul>
|
||
|
||
<h3 id="exchange-protocols">Exchange Protocols</h3>
|
||
|
||
<ul>
|
||
<li><a href="/projects/decentralized-identity-foundation/did-communications/"><em>DIDComm</em></a> (DIF)</li>
|
||
<li><a href="/web-standards/exchange-protocol/#CHAPI"><em>CHAPI</em></a> (DIF)</li>
|
||
<li><a href="/web-standards/openid/openid-connect/#Verifiable Credentials"><em>OIDC4VC</em></a> (OpenID)</li>
|
||
<li><a href="/web-standards/mobile-drivers-license-mdl-iso-18013/"><em>mDL</em></a> (ISO/IEC)</li>
|
||
<li><a href="/web-standards/exchange-protocol/#WACI"><em>WACI-Pex</em></a> (DIF)</li>
|
||
<li><a href="/web-standards/exchange-protocol/#VC%20Api"><em>VC-HTTP-API</em></a> (CCG)</li>
|
||
</ul>
|
||
|
||
<h3 id="authorization-protocols">Authorization Protocols</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://w3c-ccg.github.io/zcap-spec/">zCap</a> (w3c)</li>
|
||
<li><a href="https://github.com/ucan-wg/spec/">UCAN</a> (Fission, Bluesky, Protocol Labs)</li>
|
||
<li><a href="https://datatracker.ietf.org/wg/gnap/about/">GNAP</a> (IETF)</li>
|
||
<li><a href="https://www.ietf.org/rfc/rfc6749.txt">OAuth</a> (IETF)</li>
|
||
</ul>
|
||
|
||
<h3 id="iso-standards">ISO Standards</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.iso.org/standard/69084.html">mDL</a> (ISO/IEC 18013-5)</li>
|
||
<li><a href="https://standards.iteh.ai/catalog/tc/iso/58084a13-b883-4f4a-a372-7a5f9e4dca60/iso-iec-jtc-1-sc-17-wg-3">JTC 1/SC 17/WG 3 - Travel Documents</a> (ISO/IEC)</li>
|
||
<li><a href="https://www.iso.org/standard/27001">ISO 27001</a></li>
|
||
</ul>
|
||
|
||
<h3 id="data-stores">Data Stores</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://identity.foundation/edv-spec/">Encrypted Data Vaults</a> - EDV (DIF)</li>
|
||
<li><a href="https://identity.foundation/decentralized-web-node/spec/">Decentralized Web Node</a> - DWN (DIF)</li>
|
||
</ul>
|
||
|
||
<h3 id="trust-frameworks">Trust Frameworks</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://pages.nist.gov/800-63-3/">800-63-3</a> (NIST)</li>
|
||
<li><a href="/government/canada/pctf/"><em>PCTF</em></a> (DIACC)</li>
|
||
</ul>
|
||
|
||
<h3 id="non-ssi-identity-standards">Non SSI Identity Standards</h3>
|
||
|
||
<ul>
|
||
<li><a href="/organizations/openid/"><em>OpenID</em></a> (OpenID)</li>
|
||
<li><a href="https://fidoalliance.org/">FIDO</a> (FIDO)</li>
|
||
<li><a href="https://datatracker.ietf.org/wg/oauth/about/">OAuth</a> (IETF)</li>
|
||
<li><a href="https://datatracker.ietf.org/wg/scim/about/">SCIM</a> (IETF)</li>
|
||
<li><a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html">SAML</a> (OASIS)</li>
|
||
<li><a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip">KMIP</a> (OASIS)</li>
|
||
<li><a href="/web-standards/w3c/webauthn/"><em>WebAuthN</em></a> (W3C)</li>
|
||
<li><a href="https://docs.oasis-open.org/esat/sqrap/v1.0/csd01/sqrap-v1.0-csd01.html">Secure QR Code</a> (OASIS)</li>
|
||
<li>Blockchain Standards
|
||
<ul>
|
||
<li><a href="https://www.iso.org/committee/6266604.html">ISOTC 307</a> (ISO)</li>
|
||
<li><a href="https://standards.cencenelec.eu/dyn/www/f?p=205:7:0::::FSP_ORG_ID:2702172&amp;cs=148F2B917E4B67BCFD6FE36CE0EA923AC">CEN/CLC/JTC 19</a> (CEN/EENTLIC)</li>
|
||
<li><a href="/blockchain/ethereum/#erc-eip"><em>ERC-EIP</em></a> (Ethereum)</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="code-bases">Code-Bases</h2>
|
||
|
||
<h3 id="open-source-projects">Open Source Projects</h3>
|
||
|
||
<ul>
|
||
<li><a href="/projects/decentralized-identity-foundation/identifiers-and-discovery/#universal-resolver"><em>Universal Resolver</em></a> (DIF)</li>
|
||
<li><a href="/projects/gleif/keri/">KERI</a> (DIF)</li>
|
||
<li><a href="https://github.com/decentralized-identity">Other Tools &amp; Libraries</a> (DIF)</li>
|
||
<li><a href="https://essif-lab.eu/">ESSIF-Lab</a> (ESSIF-Lab)</li>
|
||
<li><a href="/projects/hyperledger/aries/"><em>Aires</em></a> (Hyperledger)</li>
|
||
<li><a href="/projects/hyperledger/indy/"><em>Indy</em></a> (Hyperledger)</li>
|
||
<li><a href="/projects/hyperledger/ursa/">Ursa</a> (Hyperledger)</li>
|
||
<li><a href="https://wiki.hyperledger.org/display/IWG">Other Tools &amp; Libraries</a> (Hyperledger)</li>
|
||
<li><a href="/web-standards/blockcerts/">Blockcerts</a> (Hyland)</li>
|
||
</ul>
|
||
|
||
<h3 id="company-code">Company Code</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://github.com/walt-id">Walt.id</a></li>
|
||
<li><a href="https://github.com/circlefin/verite">Verite</a></li>
|
||
<li><a href="https://github.com/spruceid">SpruceID</a></li>
|
||
</ul>
|
||
|
||
<h2 id="organizations">Organizations</h2>
|
||
|
||
<h3 id="international-standard-development-organizations-sdo">International Standard Development Organizations [SDO]</h3>
|
||
|
||
<ul>
|
||
<li><a href="/_posts/web-standards/2020-11-09-world-wide-web-consortium_w3c.md"><em>W3C</em></a></li>
|
||
<li><a href="https://ietf.org">IETF</a></li>
|
||
<li><a href="https://www.oasis-open.org/">OASIS</a></li>
|
||
<li><a href="https://www.itu.int/en/ITU-T/Pages/default.aspx">ITU-T</a></li>
|
||
<li><a href="https://www.iso.org/home.html">ISO</a>/<a href="https://iec.ch/homepage">IEC</a></li>
|
||
</ul>
|
||
|
||
<h3 id="national-governmentstandard-setting-bodies">National Government/Standard Setting Bodies</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.nist.gov/">NIST</a></li>
|
||
<li><a href="https://www.scc.ca/">The Standards Council of Canada</a></li>
|
||
<li><a href="https://www.bsi.bund.de/EN/Home/home_node.html">BSI</a> - The Federal Office for Information Security, Germany</li>
|
||
</ul>
|
||
|
||
<h3 id="community-organizations">Community Organizations</h3>
|
||
|
||
<ul>
|
||
<li><a href="/_posts/web-standards/2023-05-15-credentials-community-group.md"><em>W3C - CCG</em></a></li>
|
||
<li><a href="/_posts/organizations/2019-03-07-identity-foundation.md"><em>DIF</em></a></li>
|
||
<li><a href="/_posts/organizations/2023-06-05-TOIP.md"><em>ToIP</em></a></li>
|
||
<li><a href="https://adiassociation.org/">ADIA</a></li>
|
||
<li><a href="https://kantarainitiative.org/">Kantara</a></li>
|
||
<li><a href="/organizations/mydata/"><em>MyData</em></a></li>
|
||
<li><a href="/government/canada/diacc/"><em>DIACC</em></a></li>
|
||
<li><a href="/organizations/id2020/"><em>ID2020</em></a></li>
|
||
<li><a href="/organizations/openid/"><em>OpenID Foundation</em></a></li>
|
||
<li><a href="https://internetsafetylabs.org">Internet Safety Labs</a></li>
|
||
<li><a href="/organizations/gleif/"><em>GLEIF</em></a></li>
|
||
<li><a href="/blockchain/hyperledger/"><em>Hyperledger Foundation</em></a></li>
|
||
<li><a href="https://fidoalliance.org/">FIDO Alliance</a></li>
|
||
<li><a href="https://www.oasis-open.org/">OASIS</a></li>
|
||
</ul>
|
||
|
||
<h3 id="ssi-networks">SSI Networks</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.dizme.io/">DizmeID</a></li>
|
||
<li><a href="/organizations/sovrin-foundation/"><em>Sovrin</em></a></li>
|
||
<li><a href="https://bedrock-consortium.github.io">BedRock</a></li>
|
||
<li><a href="/blockchain/ontology/"><em>ONT</em></a></li>
|
||
<li><a href="https://www.velocitynetwork.foundation/">Velocity</a></li>
|
||
<li><a href="/companies/GlobalID/"><em>GlobalID</em></a></li>
|
||
<li><a href="https://dock.io">Dock</a></li>
|
||
<li><a href="https://dlt.mobi/itn/">ITN</a> , Mobi</li>
|
||
</ul>
|
||
|
||
<h2 id="companies">Companies</h2>
|
||
|
||
<ul>
|
||
<li><a href="/companies/microsoft/"><em>Microsoft</em></a> - Azure / Entra</li>
|
||
</ul>
|
||
|
||
<h3 id="eu-ssi-startups">EU SSI Startups</h3>
|
||
|
||
<ul>
|
||
<li><a href="/companies/MyDEX/"><em>MyDex</em></a></li>
|
||
<li><a href="/companies/meeco/"><em>MeeCo</em></a></li>
|
||
<li><a href="%link _posts/companies/2023-03-12-ValidatedID.md%"><em>ValidatedID</em></a></li>
|
||
<li><a href="https://bloqzone.com/">Bloqzone</a></li>
|
||
<li><a href="https://www.procivis.ch/en/home">Procivis</a></li>
|
||
<li><a href="https://gataca.io/">Gataca</a></li>
|
||
</ul>
|
||
|
||
<h3 id="us-ssi-startups">US SSI Startups</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.dock.io/">Dock</a></li>
|
||
<li><a href="https://anonyome.com/">Anonoyome</a></li>
|
||
<li><a href="/companies/GlobalID/"><em>GlobalID</em></a></li>
|
||
<li><a href="/companies/hyland-credentials-learning-machine/"><em>Hyland</em></a></li>
|
||
<li><a href="/companies/MagicLabs/"><em>Magic</em></a></li>
|
||
<li><a href="%link _posts/companies/2023-03-03-IDramp.md%"><em>IDRamp</em></a></li>
|
||
<li><a href="/companies/Indicio/"><em>Indicio</em></a></li>
|
||
<li><a href="https://www.verified.inc/"><em>Verified Inc</em></a> (formerly UNUMID)</li>
|
||
<li><a href="https://animo.id/"><em>Animo</em></a></li>
|
||
<li><a href="/companies/mattr/"><em>Mattr</em></a></li>
|
||
<li><a href="https://www.liquidavatar.com/"><em>Liquid Avatar</em></a></li>
|
||
<li><a href="https://hedera.com/"><em>Hedera</em></a></li>
|
||
<li><a href="https://www.iota.org/solutions/digital-identity"><em>IOTA</em></a></li>
|
||
<li><a href="/companies/trinsic/"><em>Trinsic</em></a></li>
|
||
<li><a href="/companies/transmute/"><em>Transmute</em></a></li>
|
||
<li><a href="%link _posts/companies/2023-03-10-Spruce.md%"><em>Spruce</em></a></li>
|
||
<li><a href="%link _posts/companies/2023-05-14-disco.xyz.md%"><em>Disco.xyz</em></a></li>
|
||
</ul>
|
||
|
||
<h3 id="asia-ssi-startups">Asia SSI Startups</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.affinidi.com/">Affinidi</a></li>
|
||
<li><a href="https://zada.io/">ZADA</a></li>
|
||
<li><a href="https://dhiway.com/">Dhiway</a></li>
|
||
<li><a href="https://www.ayanworks.com/">Ayanworks</a></li>
|
||
<li><a href="https://newlogic.com/">NewLogic</a></li>
|
||
</ul>
|
||
|
||
<h3 id="africa-ssi-startups">Africa SSI Startups</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://flexfintx.com/">FlexID</a></li>
|
||
<li><a href="https://www.diwala.io/">Diwala</a></li>
|
||
</ul>
|
||
|
||
<h3 id="acquisitions">Acquisitions</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.ledgerinsights.com/avast-acquires-second-blockchain-decentralized-identity-provider-securekey/">Avast-Evernym-SecureKey</a></li>
|
||
</ul>
|
||
|
||
<h3 id="analyst-firms">Analyst Firms</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.kuppingercole.com/">KuppingerCole</a></li>
|
||
<li><a href="https://www.forrester.com/bold">Forrester</a></li>
|
||
<li><a href="https://www.gartner.com/en">Gartner</a></li>
|
||
</ul>
|
||
|
||
<h3 id="consulting-firms">Consulting Firms</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.deloitte.com/">Deloitte</a></li>
|
||
<li><a href="https://www.accenture.com/">Accenture</a></li>
|
||
<li><a href="https://www.mckinsey.com/">McKinsey</a></li>
|
||
<li>BCG</li>
|
||
</ul>
|
||
|
||
<h3 id="iam-industry">IAM Industry</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.pingidentity.com/en.html">Ping</a> (TomaBravo rollup)</li>
|
||
<li><a href="https://www.okta.com/">Okta</a></li>
|
||
<li><a href="https://auth0.com/">Auth0</a></li>
|
||
<li><a href="https://seekingalpha.com/article/4560880-forgerock-acquisition-thoma-bravo-continues-roll-up-in-identity-and-access-management-space">ForgeRock</a> (TomaBravo rollup)</li>
|
||
<li><a href="https://www.identos.com/">IDENTOS</a></li>
|
||
<li><a href="https://www.sailpoint.com/">SailPoint</a> (TomaBravo rollup)</li>
|
||
</ul>
|
||
|
||
<h2 id="policiesregulations-by-region">Policies/Regulations (by region)</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://www.fatf-gafi.org/en/home.html">FATF</a></li>
|
||
</ul>
|
||
|
||
<h3 id="europe">Europe</h3>
|
||
|
||
<ul>
|
||
<li><a href="/government/europe/eu/data-governance-act/"><em>Data Governance Act</em></a></li>
|
||
<li><a href="/government/europe/regulation/gdpr/"><em>GDPR</em></a></li>
|
||
<li><a href="/government/europe/eu/eidas/"><em>eIDAS1</em></a></li>
|
||
<li><a href="/government/europe/eu/eidas/#eidas-20"><em>eIDAS2</em></a></li>
|
||
<li><a href="https://www.gov.uk/data-protection"><em>UK Data Protection</em></a></li>
|
||
</ul>
|
||
|
||
<h3 id="asia"><a href="https://www.apacdigitalid.org/en/">Asia</a></h3>
|
||
|
||
<h3 id="usa"><a href="(/government/india/)"><em>USA</em></a></h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa">COPPA</a></li>
|
||
<li><a href="https://www.hhs.gov/foia/privacy/index.html">Privacy Act</a></li>
|
||
<li><a href="https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240SB786">California SB786</a></li>
|
||
</ul>
|
||
|
||
<h3 id="india"><a href="/government/india/"><em>India</em></a></h3>
|
||
|
||
<h3 id="canada"><a href="/government/canada/"><em>Canada</em></a></h3>
|
||
|
||
<ul>
|
||
<li><a href="/government/pctf/"><em>Pan Canadian Trust Framework (PCTF)</em></a></li>
|
||
</ul>
|
||
|
||
<h2 id="government-initiatives">Government Initiatives</h2>
|
||
|
||
<h3 id="us">US</h3>
|
||
|
||
<ul>
|
||
<li><a href="/government/usa/dhs/"><em>SVIP</em></a></li>
|
||
<li><a href="https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf">National Cybersecurity Strategy</a></li>
|
||
</ul>
|
||
|
||
<h3 id="germany">Germany</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://idunion.org/?lang=en">IDUnion</a></li>
|
||
</ul>
|
||
|
||
<h3 id="uk">UK</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://blogs.gov.scot/digital/wp-content/uploads/sites/5/2019/05/Digital-Identity-Scotland-Attribute-Standards-31-May-2019.pdf">Scotland</a></li>
|
||
<li><a href="https://www.gov.uk/government/publications/uks-digital-strategy/uk-digital-strategy">UK Digital Strategy</a></li>
|
||
</ul>
|
||
|
||
<h3 id="eu">EU</h3>
|
||
|
||
<ul>
|
||
<li>eIDAS2
|
||
<ul>
|
||
<li><a href="https://utimaco.com/news/blog-posts/eidas-20-moving-closer-european-digital-identity-wallet-ediw-and-pilot">Large Scale Pilots</a></li>
|
||
<li><a href="/government/europe/eu/eidas/#eu-digital-identity-framework"><em>Architecutre</em> and Reference Framework</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/government/europe/eu/ebsi-essif/"><em>EBSI</em></a></li>
|
||
<li><a href="/history/2020s/early/essif-lab/"><em>ESSIF</em>-Lab</a></li>
|
||
<li><a href="/government/europe/#catalonia"><em>Catalonia</em></a></li>
|
||
<li>Switzerland</li>
|
||
</ul>
|
||
|
||
<h3 id="apac">APAC</h3>
|
||
|
||
<ul>
|
||
<li><a href="/government/new-zealand/"><em>New Zealand</em></a></li>
|
||
<li><a href="/government/australia/"><em>Australia</em></a></li>
|
||
<li><a href="https://www.developer.tech.gov.sg/our-digital-journey/digital-government-exchange/files/DGX%20DIWG%202022%20Report%20v1.5.pdf">Singapore</a></li>
|
||
<li><a href="https://www.w3.org/community/did-kr/">South Korea</a></li>
|
||
</ul>
|
||
|
||
<h3 id="canada-1">Canada</h3>
|
||
|
||
<ul>
|
||
<li><a href="/government/canada/bcgov/"><em>BCGov</em></a></li>
|
||
<li><a href="/government/canada/#alberta"><em>Alberta</em></a></li>
|
||
<li><a href="/government/canada/#ontario"><em>Ontario</em></a></li>
|
||
</ul>
|
||
|
||
<h3 id="latam">LatAm</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.lacchain.net/">LACCHAIN</a></li>
|
||
</ul>
|
||
|
||
<h2 id="real-world-implementation">Real-World Implementation</h2>
|
||
|
||
<ul>
|
||
<li><strong>Government Issued ID</strong>
|
||
<ul>
|
||
<li>Passport <a href="https://www.icao.int/Meetings/TAG-MRTD/TagMrtd22/TAG-MRTD-22_WP24-rev-2.pdf">eMRTD</a>/<a href="https://www.icao.int/Security/FAL/TRIP/PublishingImages/Pages/Publications/Guiding%20core%20principles%20for%20the%20development%20of%20a%20Digital%20Travel%20Credential%20%20%28DTC%29.PDF">DTC</a> (ICAO)</li>
|
||
<li><a href="https://www.slideshare.net/aniltj/us-digital-immigration-credentials-overview">Immigraion</a> (USCIS)</li>
|
||
<li><a href="https://www.aamva.org/topics/mobile-driver-license#?wst=4a3b89462cc2cff2cbe0c7accde57421">mDL</a> (US AAMVA) [not SSI standards conformant]</li>
|
||
<li><a href="https://www.iata.org/en/services/travel-agency-program/idcard/">IDCard</a> (IATA / Switzerland)</li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Trust Registries &amp; Directories</strong>
|
||
<ul>
|
||
<li><a href="https://www.ngi.eu/blog/2022/07/28/verifying-identity-management-credentials-with-train/">TRAIN</a> (ToIP)</li>
|
||
<li><a href="https://www.sparkblue.org/Regi-TRUST">Regi-Trust</a> (UNDP)</li>
|
||
<li><a href="https://www.orgbook.gov.bc.ca/search">OrgBook BC</a> (BCGov)</li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/application/supply-chain/"><em>SupplyChain/Trade</em></a>
|
||
<ul>
|
||
<li><a href="/web-standards/gs1/"><em>GS1</em></a></li>
|
||
<li><a href="/organizations/gleif/"><em>GLEIF</em></a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Banking</strong>
|
||
<ul>
|
||
<li><a href="https://bonifii.com/">Bonifi</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/application/covid-19/"><em>COVID</em></a>
|
||
<ul>
|
||
<li><a href="https://covid19vaccine.health.ny.gov/excelsior-pass-update">NYState</a></li>
|
||
<li><a href="https://vci.org/">VCI</a></li>
|
||
<li><a href="/application/covid-19/lfph_cci_good-health-pass/"><em>CCI</em></a></li>
|
||
<li>DTCC</li>
|
||
<li><a href="https://divoc.digit.org/">DIVOC</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Enterprise</strong></li>
|
||
<li><a href="/application/healthcare/"><em>Healthcare</em></a></li>
|
||
<li><a href="/application/education/"><em>Learning/Career/Education</em></a>
|
||
<ul>
|
||
<li><a href="https://jff.org">Jobs for the Future</a></li>
|
||
<li><a href="https://www.velocitynetwork.foundation/">Velocity Network</a></li>
|
||
<li><a href="https://www.learningeconomy.io/">Learning Economy Foundation</a></li>
|
||
<li><a href="https://tln.asu.edu/">TLN - Trusted Learner Network</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong><a href="/application/kyc/">KYC</a></strong></li>
|
||
<li><strong>Real Estate</strong>
|
||
<ul>
|
||
<li><a href="https://domilabs.io/">Rental</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="/application/travel/"><em>Travel</em></a></li>
|
||
<li><a href="/application/humanitarian/"><em>Humanitarian</em></a></li>
|
||
<li><strong>Energy</strong></li>
|
||
<li><a href="/application/IOT/"><em>IoT</em></a></li>
|
||
<li><a href="/application/guardianship/"><em>Guardianship</em></a></li>
|
||
<li><a href="//development/wallets/#ecosystem"><em>Wallets</em></a></li>
|
||
</ul>
|
||
|
||
<h2 id="types-by-typetopic">Types (by type+topic)</h2>
|
||
|
||
<ul>
|
||
<li><a href="/resources/literature/"><em>Research</em> Papers/Academic Literature</a>
|
||
<ul>
|
||
<li><a href="https://www.turing.ac.uk/research/research-areas/privacy-trust">Turing Institute Research: Privacy &amp; Trust</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Events</strong>
|
||
<ul>
|
||
<li><a href="/workshops/internet-identity-workshop/"><em>IIW</em></a></li>
|
||
<li><a href="/workshops/rebooting-web-of-trust/"><em>RWoT</em></a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="topics">Topics</h2>
|
||
|
||
<ul>
|
||
<li><a href="/development/biometrics/"><em>Biometrics</em></a></li>
|
||
<li><a href="/self-sovereign-identity/privacy/"><em>Privacy</em></a></li>
|
||
<li><a href="/development/ethics-rights-sovereignty/"><em>Human</em> Rights</a></li>
|
||
<li><a href="/development/user-experience/"><em>User</em> Experience</a></li>
|
||
<li><a href="/development/business/"><em>Business</em></a></li>
|
||
<li><a href="/self-sovereign-identity/critique-caution/"><em>Critiques</em></a></li>
|
||
<li><a href="/application/future/"><em>Future</em></a></li>
|
||
</ul>
|
||
|
||
<h2 id="web3-dweb--other-tech-by-focus">Web3, DWeb, &amp; Other Tech (by focus)</h2>
|
||
|
||
<ul>
|
||
<li><a href="/web-3/"><em>Web3</em></a>
|
||
<ul>
|
||
<li><a href="/web-3/id/"><em>Web3 and SSI</em></a></li>
|
||
<li><a href="/web-3/dao/"><em>DAO</em></a></li>
|
||
<li><a href="/development/decentralization/"><em>Decentralization</em></a></li>
|
||
<li><a href="/web-3/metaverse/"><em>Metaverse</em></a></li>
|
||
<li><a href="/web-3/nft/"><em>NFT</em></a></li>
|
||
<li><a href="/web-3/nft/#soulbound-tokens"><em>SBT</em></a></li>
|
||
<li><a href="/web-3/defi/"><em>DeFi</em></a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>Organizations</strong>
|
||
<ul>
|
||
<li><a href="/web-3/ethereum/baseline/"><em>Ethereum</em> Enterprise Alliance*</a></li>
|
||
<li><a href="https://www.fissionlabs.com/">Fission</a></li>
|
||
<li><a href="https://protocol.ai/">Protocol Labs</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><strong>DWeb</strong>
|
||
<ul>
|
||
<li><a href="/decentralized-web/scuttlebot/"><em>Secure</em> Suttlebutt</a></li>
|
||
<li><a href="https://bsky.app/">Bluesky</a></li>
|
||
<li><a href="/projects/tbd/web5/"><em>Web5</em></a></li>
|
||
<li><a href="/decentralized-web/handshake/"><em>Handshake</em></a></li>
|
||
</ul>
|
||
</li>
|
||
<li>Blockchain Ecosystems
|
||
<ul>
|
||
<li><a href="/blockchain/bitcoin/"><em>Bitcoin</em></a></li>
|
||
<li><a href="/blockchain/ethereum/"><em>Ethereum</em></a></li>
|
||
</ul>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="About" /><summary type="html">This page includes a breakdown of the Web Standards, Protocols,Open Source Projects, Organizations, Companies, Regions, Government and Policy surrounding Verifiable Credentials and Self Sovereign Identity.</summary></entry><entry><title type="html">Verifiable Credentials with JSON-LD and BBS+ Signatures</title><link href="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/data-integrity-bbs+/" rel="alternate" type="text/html" title="Verifiable Credentials with JSON-LD and BBS+ Signatures" /><published>2023-09-29T00:00:00+13:00</published><updated>2023-09-29T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/verifiable-credentials/VC-Data-Integrity_BBS+</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/data-integrity-bbs+/"><h2 id="main">Main</h2>
|
||
<ul>
|
||
<li>[Working Draft] <a href="https://www.w3.org/TR/vc-data-integrity/">Verifiable Credential Data Integrity 1.0</a> 2023-09-02 - Securing the Integrity of Verifiable Credential Data
|
||
<blockquote>
|
||
<p>This specification describes mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementors of distributed systems.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="about">About</h2>
|
||
<ul>
|
||
<li><a href="https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf">Verifiable Credentials Flavors Explained</a> 2021 CCI Kaliya ‘Identity Woman’ Young <a href="https://www.slideshare.net/Kaliya/verifiable-credentials-explained-by-cci">Presentation</a>
|
||
<blockquote>
|
||
<p>This approach to VCs is innovative because it brings together different elements from several of the existing approaches to VCs. It is based on the usage of <a href="https://github.com/mattrglobal/jsonld-signatures-bbs">BBS+ JSON-LD Signatures</a>, which is a subclass of <a href="https://w3c-ccg.github.io/ld-proofs/">LD Signatures</a>, in combination with a JSON-LD credential schema. The cryptography behind this mechanism is BBS+ Signatures, which require what’s called a <a href="https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03">pairing-friendly</a> curve. Existing implementations in the VC ecosystem use the elliptic curve <a href="https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-02#section-2.4">BLS12–381</a></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/coinmonks/bbs-json-ld-and-interoperability-of-verifiable-credentials-8bd26b4d3261">BBS+, JSON-LD and Interoperability of Verifiable Credentials</a> 2021-06-20 Coinmonks
|
||
<blockquote>
|
||
<p>In order to request attributes from the credentials JSON-LD frames are used. The credentials and the proofs created by BBS+ signatures are self-describing and do not require a ledger(unlike CL signature based systems like Hyperledger Indy).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Working Draft] <a href="https://www.w3.org/TR/vc-di-bbs/">BBS Cryptosuite v2023 - Securing Verifiable Credentials with Selective Disclosure using BBS Signatures</a> 2023-05-24 W3C
|
||
<blockquote>
|
||
<p>This specification defines a set of cryptographic suites for the purpose of creating, verifying and deriving proofs for BBS+ Signatures in conformance with the Data Integrity [VC-DATA-INTEGRITY] specification.</p>
|
||
|
||
<p>In general the suites uses the RDF Dataset Normalization Algorithm [RDF-DATASET-NORMALIZATION] to transform an input document into its canonical form. It then uses the statement digest algorithm to digest each statement to be signed individually, finally the digested statements are signed using the defined signature algorithm.</p>
|
||
|
||
<p>BBS+ signatures [CFRG-BBS-SIGNATURE] are compatible with any pairing friendly elliptic curve, however the cryptographic suites defined in this document elect to only allow the usage of the BLS12-381 for interoperability purposes.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Literature] <a href="https://eprint.iacr.org/2023/275.pdf">Revisiting BBS Signatures</a> 2023, Stefano Tessaro and Chenzhi Zhu
|
||
<blockquote>
|
||
<p>BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’06), and is currently the object of a standardization effort which has led to a recent RFC draft. BBS+ signatures are suitable for use within anonymous credential and DAA systems, as their algebraic structure enables efficient proofs of knowledge of message-signature pairs that support partial disclosure.</p>
|
||
|
||
<p>BBS+ signatures consist of one group element and two scalars. As our first contribution, we prove that a variant of BBS+ producing shorter signatures, consisting only of one group element and one scalar, is also secure. The resulting scheme is essentially the original BBS proposal, which was lacking a proof of security. Here we show it satisfies, under the q-SDH assumption, the same provable security guarantees as BBS+. We also provide a complementary tight analysis in the algebraic group model, which heuristically justifies instantiations with potentially shorter signatures.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[JWT; BBS+; Data Integrity] <a href="https://ssr2022.com/slides/FormalisingLinkedDataBasedVerifiableCredentials.pdf">Formalising Linked-Data based Verifiable Credentials for Selective Disclosure</a> 2022 Dan Yamamoto, Yuji Suga, Kazue Sako IEEE
|
||
<blockquote>
|
||
<p><img src="https://i.imgur.com/aoCMkpo.png" alt="" /></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://gataca.io/blog/ssi-essentials-which-selective-disclosure-protocol-will-succeed/">SSI Essentials: Zero Knowledge Proof (ZKP) and Selective Disclosure, till death do us part?</a> 2022-01-23 Gataca
|
||
<blockquote>
|
||
<p>Selective disclosure via BBS+ signatures […]</p>
|
||
|
||
<p>Like monoclaim credentials allow users to share specific claims from a VC, BBS+ Signatures is a multi-message digital signature scheme (named after its creators Boneh, Boyen, and Shacham) that gives users the possibility of sharing VCs with only specific attributes revealed. How does it work?</p>
|
||
|
||
<p>BBS+ signatures allow a VC holder to derive proofs from the original signature:</p>
|
||
<ul>
|
||
<li>Deriving a proof: When a holder takes the signed VC and hides one, several, or none of the containing claims, creating a new signature (a derived proof) using the Issuer’s public key. This derived proof can prove that the holder knows all of the original claims contained in the VC but chooses only to reveal the required ones.</li>
|
||
<li>Verifying a proof: The verifier validates the derived proof using the Issuer’s public key. This process enables the verifier to confirm the validity of the proof, proving that the subset of claims was part of an original message signed by the Issuer.</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.evernym.com/blog/bbs-verifiable-credentials/">Why the Verifiable Credentials Community Should Converge on BBS+</a> 2021-03-24 Evernym
|
||
<blockquote>
|
||
<p>BBS+ LD-Proofs use JSON-LD schemas, so credentials that use them can have a rich, hierarchical set of attributes. Instead of the heavy-handed mechanism for the encoding and canonicalization of attributes values that we’d imagined for Rich Schemas, they use RDF canonicalization and a hash function. Rather than expanding the credential definition, they discarded it, taking advantage of some properties of BBS+ keys which allow for deterministic expansion.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="development">Development</h2>
|
||
<ul>
|
||
<li>[Code] <a href="https://www.npmjs.com/package/@mattrglobal/jsonld-signatures-bbs">jsonld-signatures-bbs</a> 2022-12-18 Mattr Global, NPMJS
|
||
<blockquote>
|
||
<p>The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.</p>
|
||
|
||
<p>Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/mattrglobal/bbs-signatures">bbs-signatures</a> 2022-12-21 Mattr Global
|
||
<blockquote>
|
||
<p>BBS+ Signatures are a digital signature algorithm originally born from the work on Short group signatures by Boneh, Boyen, and Shachum which was later improved on in Constant-Size Dynamic k-TAA as BBS+ and touched on again in section 4.3 in Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited .</p>
|
||
|
||
<p>BBS+ signatures require a pairing-friendly curve, this library includes support for BLS12-381.</p>
|
||
|
||
<p>BBS+ Signatures allow for multi-message signing whilst producing a single output signature. With a BBS signature, a proof of knowledge based proof can be produced where only some of the originally signed messages are revealed at the discretion of the prover.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/mattrglobal/jsonld-signatures-bbs">jsonld-signatures-bbs</a> Mattr Global
|
||
<blockquote>
|
||
<p>The following repository contains a linked data proof implementation for creating BBS+ Signatures using BLS12-381 key pairs.</p>
|
||
|
||
<p>Due to the properties of a BBS+ Signatures, zero knowledge proof can be derived from the signature, where-by the party generating the proof can elect to selectively disclose statements from the originally signed payload.</p>
|
||
|
||
<p>This library is runnable in browser and Node.js through the WASM based crypto implementation provided by bbs-signatures. Note bbs-signatures also has an optional dependency on node-bbs-signatures which can be used when running in Node.JS environments to obtain better performance. For environments that do not feature WASM support such as react native, bbs-signatures includes an automatic roll back to an asm.js version but note however the performance difference between asm.js and WASM is significant, for those inclined there are runnable benchmarks in bbs-signatures.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/zkp-ld/jsonld-signatures-bbs">jsonld-signatures-bbs</a> 2023-02-23 ZKP-LD
|
||
<blockquote>
|
||
<p>Experimental: do not use in production</p>
|
||
<ul>
|
||
<li>Based on MATTR’s jsonld-signatures-bbs</li>
|
||
<li>Supports termwise selective disclosure, proof of termwise equality, and credential aggregation</li>
|
||
<li>dependencies upgraded</li>
|
||
<li>WASM only; Neon is currently not supported</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/zkp-ld/bbs-signatures">bbs-signatures</a> ZKP-LD
|
||
<blockquote>
|
||
<p>Experimental: do not use in production</p>
|
||
<ul>
|
||
<li>Based on MATTR’s bbs-signatures</li>
|
||
<li>Supports termwise selective disclosure, proof of termwise equality, and credential aggregation</li>
|
||
<li>WASM only; Neon is currently not supported</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://damienbod.com/2021/12/13/implement-compound-proof-bbs-verifiable-credentials-using-asp-net-core-and-mattr/">Implement Compound Proof BBS+ verifiable credentials using ASP.NET Core and MATTR</a> 2021-12-13 damienbod
|
||
<blockquote>
|
||
<p>This article shows how Zero Knowledge Proofs BBS+ verifiable credentials can be used to verify credential subject data from two separate verifiable credentials implemented in ASP.NET Core and MATTR. The ZKP BBS+ verifiable credentials are issued and stored on a digital wallet using a Self-Issued Identity Provider (SIOP) and OpenID Connect. A compound proof presentation template is created to verify the user data in a single verify.</p>
|
||
|
||
<p>Code: https://github.com/swiss-ssi-group/MattrAspNetCoreCompoundProofBBS</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="blum-blum-shub">Blum Blum Shub</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://asecuritysite.com/encryption/blum">Blum Blum Shub</a> A Security Site
|
||
<blockquote>
|
||
<p>Blum Blum Shub (BBS) is used as a pseudo-random number generator (it is pseudo as it is not a truly random number, and where its randomisation depends on a random seed). It was created by Lenore Blum, Manuel Blum and Michael Shub in 1968. Blum Blum Shub uses the form of xn+1=x2n(modM), and where x0 is a random seed. The value of M is equal to pq, and where p and q are prime numbers. These values of p and q are both congruent to 3 mod 4 (p=q=3(mod4)). The security of the method involves the difficulty in factorizing M. It is slow, but is the strongest proven random number generator. For each step, we extract some of the information from xn+1, and which is typically the least significant bit. It would not be used within a cipher application, but could be used in key generation.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://shub.ccny.cuny.edu/articles/1986-A_simple_unpredictable_pseudo-random_number_generator.pdf">A SIMPLE UNPREDICTABLE PSEUDO-RANDOM NUMBER GENERATOR</a> 1986 L. BLUM?, M. BLUM AND M. SHUB SIAM
|
||
<blockquote>
|
||
<p>What do we want from a pseudo-random sequence generator? Ideally, we would like a pseudo-random sequence generator to quickly produce, from short seeds, long sequences (of bits) that appear in every way to be generated by successive flips of a fair coin.</p>
|
||
|
||
<p>Certainly, the idea of a (fast) deterministic mechanism producing such non-deterministic behavior seems contradictory: by observing its outcome over time, we could in principle eventually detect the determinism and simulate such a generator.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Python] <a href="https://www.gkbrk.com/wiki/blum-blum-shub/">Blum Blum Shub PRNG algorithm</a> GKBRK
|
||
<blockquote>
|
||
<p>The algorithm is very short and simple. Starting from the seed, the next state can be computed by passing the current state through the following formula.</p>
|
||
|
||
<p><code class="language-plaintext highlighter-rouge">f(x) = x2 mod M</code></p>
|
||
|
||
<p>In this formula, M is the product of p and q, two large primes.</p>
|
||
|
||
<p>The complexity in this algorithm is hidden in the parameters; the seed and the modulus M. In order to have a long cycle length and fulfill its security promises, Blum Blum Shub has a few constraints on its parameters.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>In contrast, some more complex PRNG algorithms can work with pretty much any randomized seed.</p></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="W3C" /><category term="Verifiable Credentials" /><category term="JSON-LD" /><category term="Data Integrity" /><category term="BBS" /><summary type="html">BBS signatures were implicitly proposed by Boneh, Boyen, and Shacham (CRYPTO ’04) as part of their group signature scheme, and explicitly cast as stand-alone signatures by Camenisch and Lysyanskaya (CRYPTO ’04). A provably secure version, called BBS+, was then devised by Au, Susilo, and Mu (SCN ’06)</summary></entry><entry><title type="html">Verifiable Credentials with JOSE (JWT) / COSE (CBOR)</title><link href="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/jose-jwt+cose-cbor/" rel="alternate" type="text/html" title="Verifiable Credentials with JOSE (JWT) / COSE (CBOR)" /><published>2023-09-08T00:00:00+13:00</published><updated>2023-09-09T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/verifiable-credentials/VC_JOSE-COSE</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/jose-jwt+cose-cbor/"><h2 id="main">Main</h2>
|
||
<ul>
|
||
<li>[Working Draft] <a href="https://www.w3.org/TR/vc-jose-cose/">Securing Verifiable Credentials using JOSE and COSE</a> 2023-09-08 Orie Steele, Michael Jones, Michael Prorock
|
||
<blockquote>
|
||
<p>This specification defines how to secure credentials and presentations conforming to the <a href="https://www.w3.org/TR/vc-jose-cose/#bib-vc-data-model">VC-DATA-MODEL</a>, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (<a href="https://datatracker.ietf.org/wg/jose/about/">COSE</a>) <a href="https://www.w3.org/TR/vc-jose-cose/#bib-rfc9052">RFC9052</a>. This enables the Verifiable Credential data model [VC-DATA-MODEL] to be implemented with standards for signing and encryption that are widely adopted.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Editors Draft] <a href="https://w3c.github.io/vc-data-model/">Verifiable Credentials Data Model v2.0</a> 2023-09-09
|
||
<blockquote>
|
||
<p>Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key holder), are an essential part of processing a verifiable credential. At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms:</p>
|
||
<ul>
|
||
<li>Securing Verifiable Credentials using JOSE and COSE [<a href="https://w3c.github.io/vc-data-model/#bib-vc-jose-cose">VC-JOSE-COSE</a>].</li>
|
||
<li>Securing Verifiable Credentials using Data Integrity Proofs [<a href="https://w3c.github.io/vc-data-model/#bib-vc-jose-cose">VC-DATA-INTEGRITY</a>].</li>
|
||
<li>Camenisch-Lysyanskaya Zero-Knowledge Proofs [<a href="https://w3c.github.io/vc-data-model/#bib-cl-signatures">CL-SIGNATURES</a>].</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://identitywoman.net/misinformation-stops-here-w3c-vc-2-0-supports-json/">Misinformation Stops Here: W3C VC 2.0 Supports JSON</a> 2023-07-21 Kaliya Young
|
||
<blockquote>
|
||
<p>There is one “extra” field that JSON-LD requires/needs which is @context and if you didn’t want to use it and simply wanted to ignore it and just do JSON you could. The VC would be entirely compliant and thus both data expression formats could live in the same specification. JSON-LD credentials that did have an @context that were being read by tooling that just did JSON could still read the credentials – it did nothing to interfere. This seems like a pretty good “let’s figure out how to live with each other” solution.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="verifiable-credentials-with-json-web-token-jose">Verifiable Credentials with JSON Web Token (JOSE)</h2>
|
||
<ul>
|
||
<li><a href="https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-00.html">Fully-Specified Algorithms for JOSE and COSE</a> 2023-08-29 Mike Jones, Orie Steel; IETF
|
||
<blockquote>
|
||
<p>This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being “fully specified”. Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being “polymorphic”. This specification creates fully-specified algorithm identifiers for all registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.ietf.org/id/draft-terbu-sd-jwt-vc-02.html">SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC)</a> 2023-05-26 IETF
|
||
<blockquote>
|
||
<p>This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format [<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-04">I-D.ietf-oauth-selective-disclosure-jwt</a>].</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://self-issued.info/?p=2316">Native JWT Representation for Verifiable Credentials</a> 2023-02-10 Mike Jones
|
||
<blockquote>
|
||
<p>For the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://techcommunity.microsoft.com/t5/security-compliance-and-identity/decentralized-identity-verifiable-credentials-deep-dive/ba-p/3690641">Verifiable Credentials Deep Dive</a> 2022-12-09 Pamela Dingle, Microsoft
|
||
<blockquote>
|
||
<p>A JWT-VC has three parts, and the payload contains what I would call envelope information: the data needed to know who the credential is is bound to, who made the credential, when it was made and how it can be identified. Additionally, there is a JSON object called “vc”. Claims information is embedded inside the vc object. A JWT-VC uses an external proof, meaning in this case that signature data is not embedded inline with the credential, the signature is detached from the credential.
|
||
<img src="https://i.imgur.com/ZBlDL7f.png" alt="" /></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf">Verifiable Credentials Flavors Explained</a> 2021 CCI Kaliya ‘Identity Woman’ Young
|
||
<blockquote>
|
||
<p>JWT takes a different approach to determining the meaning of claim terms in credentials. There is an <a href="https://www.iana.org/assignments/jwt/jwt.xhtml">IANA registry for JWT claims</a> as a first place to look for JWT claim definitions. If the claim name isn’t in the IANA register, then the claim can be given a “give it a public name (i.e., a URI), [or] a local name (i.e., any string)”. The meaning of the terms is decided between the issuers and verifiers.</p>
|
||
|
||
<p>In the VC Implementation Guidelines, there is a long list of the different characterizations of methods: JSON with JWT’s support vs JSON-LD with LD Signatures, <a href="https://www.w3.org/TR/vc-imp-guide/#benefits-of-jwts">Benefits of JWT</a>, <a href="https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs">Benefits of JSON-LD and LD-Proofs</a>.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/mattr-global/jwt-vs-linked-data-proofs-comparing-vc-assertion-formats-a2a4e6671d57">JWT vs Linked Data Proofs: comparing Verifiable Credentials</a> 2020-05-7 Nader Helmy, Mattr
|
||
<blockquote>
|
||
<p>JWTs have the benefit of already being widely used in today’s identity technologies, most notably in the framework used by OAuth 2.0 and OpenID Connect. Because of this, there are a number of existing software libraries and tools that developers can use immediately to begin building out their implementations. In addition, due to the fact that JWT-based credentials rely on a shared assertion format with existing identity technologies, it may be an easier mental model for newcomers to adopt when starting to experiment with VCs.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="vc-jwt-selective-disclosure">VC-JWT Selective Disclosure</h3>
|
||
<ul>
|
||
<li>[Standards Track] <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/">SD-JWT-based Verifiable Credentials (SD-JWT VC)</a> 2023-08-16 Oliver Terbu, Daniel Fett IETF
|
||
<blockquote>
|
||
<p>JSON Web Tokens (JWTs) [RFC7519] can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.</p>
|
||
|
||
<p>Selective Disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).</p>
|
||
|
||
<p>SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures. However, SD-JWT itself does not define the claims that must be used within the payload or their semantics.</p>
|
||
|
||
<p>This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload. Those Verifiable Credentials are called SD-JWT VCs.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://api-pilot.ebsi.eu/docs/specs/guidelines/selective-disclosure-sd-jwt">Selective Disclosure with SD-JWT</a> 2023
|
||
<blockquote>
|
||
<p>The purpose of this guideline is to document how to use SD-JWT with both versions V1.1 and V2.0 of the W3C Verifiable Credentials Data Model (VCDM). The document also covers application of these models in either JSON or JSON-LD format, and methods for protecting them using JWS signatures (compact or JSON serialised).</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="vc-jwt-presentation">VC-JWT Presentation</h3>
|
||
<ul>
|
||
<li><a href="https://identity.foundation/jwt-vc-presentation-profile/">JWT VC Presentation Profile</a> 2023-08-07 DIF
|
||
<blockquote>
|
||
<p>The JWT VC Presentation Profile defines a set of requirements against existing specifications to enable the interoperable presentation of Verifiable Credentials (VCs) between Wallets and Verifiers.</p>
|
||
|
||
<p>This document is not a specification, but a profile. It outlines existing specifications required for implementations to interoperate among each other. It also clarifies mandatory to implement features for the optionalities mentioned in the referenced specifications.</p>
|
||
|
||
<p>The profile uses OpenID for Verifiable Presentations (OpenID4VP ID1) as the base protocol for the request and verification of W3C JWT VCs as W3C Verifiable Presentations (VC Data Model v1.1).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[MDL, JWT-VC, LD-Proofs] <a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0-14.html">OpenID for Verifiable Presentations</a> 2022-12-30 OpenID
|
||
<blockquote>
|
||
<p>This specification defines mechanisms to</p>
|
||
<ul>
|
||
<li>request presentation of Verifiable Credentials in arbitrary formats.</li>
|
||
<li>provide a verifier with one or more Verifiable Presentations in a secure fashion.</li>
|
||
<li>customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].</li>
|
||
<li>combine the credential presentation with user authentication through [SIOPv2].</li>
|
||
<li>combine the credential presentation with the issuance of OAuth access tokens.</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/workday-engineering/lets-actually-share-our-verifiable-credentials-7ab1b4c73079">Let’s (actually) Share Our Verifiable Credentials - Introducing the JWT VC Presentation Profile</a> 2022-07-25 Jen Schreiber, Workday Technology
|
||
<blockquote>
|
||
<p>In order to tackle the problem of how we actually share credentials, Workday teamed up with Microsoft, Ping Identity, and MATTR to develop a <a href="https://identity.foundation/jwt-vc-presentation-profile">specification profile</a> that outlines a list of standards and, once adopted by providers, would enable seamless verification of VCs. Development of the profile continues within the Decentralized Identity Foundation (DIF).</p>
|
||
|
||
<p>In this blog post, we will give an overview of why specification profiles are required, what this profile involves, and what it means for the adoption of VCs.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="vc-jwt-development">VC-JWT Development</h3>
|
||
<ul>
|
||
<li>[GitHub, NPM] <a href="https://github.com/decentralized-identity/did-jwt-vc">did-jwt-vc</a> 2023-09-04 DIF
|
||
<blockquote>
|
||
<p>Create and verify W3C Verifiable Credentials and Presentations in JWT format</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Web Tool] <a href="https://jwt.vc/">Transmute JSON Web Tokens into Verifiable Credentials</a>
|
||
<blockquote>
|
||
<p>Encoded PASTE A TOKEN HERE</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Web Tool] <a href="https://vcinteroptesting.azurewebsites.net/">JWT VC Interop Profile</a> Microsoft
|
||
<blockquote>
|
||
<p>Verifiable Credential Issuance and Verifier Sample</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Web Tool] <a href="https://api-pilot.ebsi.eu/docs/tools/vc-validator">VC validator</a> EBSI
|
||
<blockquote>
|
||
<p>Validate a Verifiable Credential (VC) or a Verifiable Presentation (VP) using the <a href="https://api-pilot.ebsi.eu/docs/libraries/verifiable-credential">@cef-ebsi/verifiable-credential</a> and <a href="https://api-pilot.ebsi.eu/docs/libraries/verifiable-presentation">@cef-ebsi/verifiable-presentation</a> libraries.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Spec v3] <a href="https://www.imsglobal.org/spec/ob/v3p0#jwt-proof">Open Badges Specification - JSON Web Token Proof Format</a> 2023-09-08 Open Badges, IMS Global
|
||
<blockquote>
|
||
<p>This proof format relies on the well established JWT (JSON Web Token) [RFC7519] and JWS (JSON Web Signature) [RFC7515] specifications. A JSON Web Token Proof is a JWT signed and encoded as a Compact JWS string. The proof format is described in detail in Section 6.3.1 “JSON Web Token” of Verifiable Credentials Data Model v1.1. That description allows several options which may inhibit interoperability. This specification limits the options while maintaining compatibility with [VC-DATA-MODEL] to help ensure interoperability.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/kushaldas/sd_jwt">sd_jwt</a> 2022-06-12 Kushaldas
|
||
<blockquote>
|
||
<p>This is an implementation of the SD-JWT draft, revision 2.<br />
|
||
Do not use it in production yet.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[GitHub] <a href="https://github.com/uport-project/kotlin-did-jwt">kotlin-did-jwt</a> 2020-03-21 uPort Project
|
||
<blockquote>
|
||
<p>The kotlin-did-JWT library allows you to sign and verify JSON Web Tokens (JWT) using ES256K, and ES256K-R algorithms.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="json-web-proof">JSON Web Proof</h2>
|
||
<ul>
|
||
<li>[tracker] <a href="https://datatracker.ietf.org/doc/bofreq-miller-json-web-proofs/">JSON Web Proofs / JSON Object Signing and Encryption (JOSE)</a>2022-06-16 J. Miller, D. Waite, Ping Identity. M. Jones Microsoft. IETF
|
||
<blockquote>
|
||
<p>The JOSE RFCs and JWT, have been widely adopted for identity use cases, including for the widely-deployed OpenID Connect protocol and STIR. Concurrent to the growth of adoption of these standards has been an increasing societal focus on privacy. Common privacy themes in identity solutions that intersect with JWT are user consent and minimal disclosure.</p>
|
||
|
||
<p>In recent years, newer solutions have been evolving such as Verifiable Credentials that formalize the entities of Issuer, Holder, and Verifier. A Verifiable Credential lifecycle has three accompanying phases: issuance, storage, and presentation. The JOSE and JWT standards have also been adopted by Verifiable Credentials (for the JWT-VC representation), but JWS and JWT have limitations that make privacy protection challenging.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://hackmd.io/@quartzjer/JSON_Web_Proof">JSON Web Proof (JWP)</a> 2021-06-29 QuartzJer
|
||
<blockquote>
|
||
<p>A JSON Web Proof (JWP) is very similar to a JWS, with the addition that it can contain multiple individual payloads instead of a singular one. New JWP-supporting algorithms are then able to separate and act on the individual payloads contained within.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://w3c-ccg.github.io/Merkle-Disclosure-2021/jwp/">JSON Web Proof for Binary Merkle Trees</a> 2021 O. Steele, Transmute. M. Prorock, mesur.io. Credentials Community Group
|
||
<blockquote>
|
||
<p>The purpose of this specification is to define a generic encoding of merkle audit paths that is suitable for combining with [RFC7515] to construct selective disclosure proofs, that are not bound to the needs of certificate transparency, and that are suitable for more generic applications such as W3C Verifiable Credentials and W3C Decentralized Identifiers.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="verifiable-credentials-with-concise-binary-object-representation-cose">Verifiable Credentials with Concise Binary Object Representation (COSE)</h2>
|
||
|
||
<ul>
|
||
<li>[Unofficial Draft] <a href="https://transmute-industries.github.io/vc-cose/">Verifiable Credentials with CBOR Object Signatures</a> 2023-01-18 Transmute
|
||
<blockquote>
|
||
<p>This specification introduces a (Content Type) Header Parameter that is used to define the content type for Verifiable Credentials that utilize CBOR Object Signing to provide signing and verification in a Verifiable Credential.</p>
|
||
|
||
<p>This approach, of utilizing to a (Content Type) Header Parameter to specify a discrete set of mappings and expected behaviors in translation between formats or representations of data is used commonly in other groups to secure arbitrary content using COSE and other document and data encoding formats. This approach is extensible to other data encodings and may be extended to provide a mechanism for use of CBOR encodings for Verifiable Credentials.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="cbor-explainer">CBOR Explainer</h3>
|
||
<ul>
|
||
<li><a href="https://www.blockchaincommons.com/introduction/Why-CBOR/">Why CBOR?</a> 2022-12-07 Blockchain Commons
|
||
<blockquote>
|
||
<p>we have decided to use the IETF CBOR (Concise Binary Object Representation) standard in our specifications, including Gordian Envelope.</p>
|
||
|
||
<p>We chose CBOR as our serialization format choice for several key reasons</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Working Group] <a href="https://datatracker.ietf.org/wg/cbor/about/">Concise Binary Object Representation Maintenance and Extensions (cbor)</a> 2023-06-07
|
||
<blockquote>
|
||
<p>Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[W3C Editor’s Draft] <a href="https://digitalbazaar.github.io/cbor-ld-spec/">CBOR-LD 1.0 - A CBOR-based Serialization for Linked Data</a> 2022-09-06 Digital Bazaar,
|
||
<blockquote>
|
||
<p>CBOR is a compact binary data serialization and messaging format. This specification defines CBOR-LD 1.0, a CBOR-based format to serialize Linked Data. The encoding is designed to leverage the existing JSON-LD ecosystem, which is deployed on hundreds of millions of systems today, to provide a compact serialization format for those seeking efficient encoding schemes for Linked Data. By utilizing semantic compression schemes, compression ratios in excess of 60% better than generalized compression schemes are possible. This format is primarily intended to be a way to use Linked Data in storage and bandwidth constrained programming environments, to build interoperable semantic wire-level protocols, and to efficiently store Linked Data in CBOR-based storage engines.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[RFC 9052] <a href="https://www.rfc-editor.org/rfc/rfc9052">CBOR Object Signing and Encryption (COSE): Structures and Process</a> 2022-08
|
||
<blockquote>
|
||
<p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[RFC 9053] <a href="https://www.rfc-editor.org/rfc/rfc9053">CBOR Object Signing and Encryption (COSE): Initial Algorithms</a>
|
||
<blockquote>
|
||
<p>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://learn.mattr.global/docs/vii-platform/compact-credentials/">Compact Credentials</a> Mattr
|
||
<blockquote>
|
||
<p>CBOR is a binary data format derived from JSON that allows it to utilizes data types like numbers, strings &amp; arrays, however, due to being binary, it offers a much more compact message size. Often when CBOR is being discussed or documented, we can represent the data model using JSON to simplify the way the data can be viewed and modelled.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="vc-cbor-development">VC-CBOR Development</h3>
|
||
|
||
<ul>
|
||
<li>[“mDL”,”eID”] <a href="https://walt.id/blog/p/mdl-eid-and-beyond">The Developers’ Dilemma (why mdoc credentials)</a> 2023-08-11 WaltID
|
||
<blockquote>
|
||
<p>Though, as it is with many new technologies. Before they can reach the masses, they share a common trait: building with them is challenging and time-consuming, which is based on the lack of developer tools making usage easy and implementation quick.</p>
|
||
|
||
<p>Which is why we build the <a href="https://github.com/walt-id/waltid-mdoc">mdoc lib</a>, as an addition to our open-source identity stack. Proving our commitment to deliver on the latest developments in the industry. Offering tools that let you build compliant solutions across identity ecosystems using different identity flavors with ease, whether that be on- or off-chain identity like Tokens/NFTs, W3C Verifiable Credentials or now mdoc credentials. mdoc is a binary highly storage efficient credential format leveraging CBOR, standardized through ISO/IEC 18013-5:2021 mDL specification.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.npmjs.com/package/@mattrglobal/vc-cwt-verifier">@mattrglobal/vc-cwt-verifier</a> NPMJS
|
||
<ul>
|
||
<li>Verify a credential</li>
|
||
<li>Verify a credential with a list of trusted issuers</li>
|
||
<li>Verify a credential skipping expiry and not before checks</li>
|
||
<li>Provide custom cache for issuer resolution</li>
|
||
</ul>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="W3C" /><category term="Verifiable Credentials" /><category term="JWT" /><category term="IANA" /><category term="JOSE" /><category term="COSE" /><summary type="html">Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key holder), are an essential part of processing a verifiable credential.</summary></entry><entry><title type="html">Verifiable Credentials with JSON-LD and Linked Data Proofs</title><link href="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs/" rel="alternate" type="text/html" title="Verifiable Credentials with JSON-LD and Linked Data Proofs" /><published>2023-09-08T00:00:00+13:00</published><updated>2023-09-29T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/verifiable-credentials/VC-Data-Integrity_LD-Proofs</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/data-integrity_ld-proofs/"><h2 id="main">Main</h2>
|
||
<ul>
|
||
<li>[Working Draft] <a href="https://www.w3.org/TR/vc-data-integrity/">Verifiable Credential Data Integrity 1.0</a> 2023-09-02 - Securing the Integrity of Verifiable Credential Data
|
||
<blockquote>
|
||
<p>This specification describes mechanisms for ensuring the authenticity and integrity of Verifiable Credentials and similar types of constrained digital documents using cryptography, especially through the use of digital signatures and related mathematical proofs. Cryptographic proofs enable functionality that is useful to implementors of distributed systems.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Editors Draft] <a href="https://w3c.github.io/vc-data-model/#securing-verifiable-credentials">Verifiable Credentials Data Model v2.0</a> 2023-09-09
|
||
<blockquote>
|
||
<p>This specification recognizes two classes of securing mechanisms: those that use external proofs and those that use embedded proofs. An external proof is one that wraps an expression of this data model, such as via a JSON Web Token, which is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model, such as a Data Integrity Proof, which is elaborated on in Verifiable Credential Data Integrity [<a href="https://www.w3.org/TR/vc-data-integrity/">VC-DATA-INTEGRITY</a>].</p>
|
||
|
||
<p>It should be noted that these two classes of securing mechanisms are not mutually exclusive.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Final Community Group Report] <a href="https://w3c-ccg.github.io/lds-jws2020/">JSON Web Signature 2020</a> 2022-07-21
|
||
<blockquote>
|
||
<p>This specification describes a JSON Web Signature Suite created in 2020 for the Linked Data Proof specification. The Signature Suite utilizes Detached JWS signatures to provide support for a subset of the digital signature algorithms registered with IANA.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://learn.mattr.global/docs/concepts/verifiable-data">Verifiable data</a> 2020-12-12 Mattr
|
||
<blockquote>
|
||
<p>Verifiable credentials make use of JSON-LD to extend the data model to support dynamic data vocabularies and schemas. This allows us to not only use existing JSON-LD schemas, but to utilize the mechanism defined by JSON-LD to create and share new schemas as well. To a large extent this is what JSON-LD was designed for; the adoption and reuse of common data vocabularies.</p>
|
||
|
||
<p>This type of verifiable credential is best characterised as a kind of Linked Data Proof. It allows issuers to make statements that can be shared without loss of trust because their authorship can be verified by a third party.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="about">About</h2>
|
||
<ul>
|
||
<li><a href="https://www.linkedin.com/pulse/linked-data-proofs-new-pathway-verifiable-credentials-gokul-alex">Linked Data Proofs - A new pathway for verifiable credentials</a> 2023-05-13 Gokul Alex
|
||
<blockquote>
|
||
<p>It is portable because it provides a standard vocabulary. JSON-LD configuration files are human readable unlike the JWT. Data schema emerge as important paradigms in this model. VCs based on Linked Data Proofs use Linked Data Signatures for security. They are more granular as they are attribute based rather than credential based.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://indicio.tech/five-things-you-need-to-know-about-json-ld-credentials-in-hyperledger-aries-cloudagent-python/">Five Things You Need to Know About JSON-LD Credentials in Hyperledger Aries Cloudagent Python</a> 2022-12-07 Tim Spring, Indicio
|
||
<blockquote>
|
||
<p>Starting with the name, JSON-LD stands for JavaScript Object Notation with Linked Data. JSON-LD is a method of encoding linked data using JSON. The term “JSON-LD Credential” alone is somewhat ambiguous but the way it is colloquially used, it means a W3C Verifiable Credential Data Model compliant credential signed using Linked Data Proofs. These are more precisely referred to as Linked Data Proof Verifiable Credentials (LDP-VCs).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://grotto-networking.com/blog/posts/jsonldProofs.html">Verifying Verifiable Credentials</a> 2022-11-11 Grotto Networking
|
||
<blockquote>
|
||
<p>A number of specifications and emerging specifications explain and specify how VCs can be “secured”. Here we will look at the “digital signing” of VCs and draw upon the following specifications:</p>
|
||
<ul>
|
||
<li>Verifiable Credential Data Integrity 1.0 Securing the Integrity of Verifiable Credential Data Latest as of October 2022.</li>
|
||
<li>JSON-LD Website</li>
|
||
<li>JSON-LD 1.1 A JSON-based Serialization for Linked Data, W3C Recommendation 16 July 2020.</li>
|
||
<li>EdDSA Cryptosuite v2020 Draft Community Group Report 31 October 2022</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
<li>[notes] <a href="https://hackmd.io/@animo/HJn4Mioku">Verifiable Credentials &amp; Linked Data Proofs</a> 2021-04-01
|
||
<blockquote>
|
||
<p>Linked Data Proofs provide a mechanism to for ensuring the authenticity and integrity of Linked Data documents using mathematical proofs.</p>
|
||
</blockquote>
|
||
<ul>
|
||
<li><a href="https://hackmd.io/inzaVCAtSdWQxzmw8doNGg">Notes on Linked Data Proofs</a> 2021-01-24
|
||
<blockquote>
|
||
<p>Linked Data Proofs can be used to:</p>
|
||
<ul>
|
||
<li>Make statements without the loss of trust (e.g. VCs or social media posts)</li>
|
||
<li>Authenticate an entity is identified by a certain identifier (e.g. DIDs)</li>
|
||
<li>Delegate authorization for actions to remote environments (e.g. ZCAP-LD)</li>
|
||
<li>Agree to contracts (where agreement can be verified by other parties)</li>
|
||
<li>Integrity protection (e.g. making document tamper-evident)</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf">Verifiable Credentials Flavors Explained</a> 2021 CCI Kaliya ‘Identity Woman’ Young <a href="https://www.slideshare.net/Kaliya/verifiable-credentials-explained-by-cci">Presentation</a>
|
||
<blockquote>
|
||
<p>In the VC Implementation Guidelines, there is a long list of the different characterizations of methods: JSON with JWT’s support vs JSON-LD with LD Signatures, <a href="https://www.w3.org/TR/vc-imp-guide/#benefits-of-jwts">Benefits of JWT</a>, <a href="https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs">Benefits of JSON-LD and LD-Proofs</a>.</p>
|
||
|
||
<p>To summarize the most salient points:</p>
|
||
|
||
<p>JSON is an older standard, officially recognized as a standard in 2013. JSON-LD 1.0 was formally standardized in 2014. The version and standard was updated to JSON-LD 1.1 and ratified in 2020.</p>
|
||
|
||
<p>That being said, one can use JSON libraries to process JSON-LD objects/documents, and conversely, <a href="https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld">interpret JSON documents as JSON-LD</a> by providing a context.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/mattr-global/jwt-vs-linked-data-proofs-comparing-vc-assertion-formats-a2a4e6671d57">JWT vs Linked Data Proofs: comparing Verifiable Credentials</a> 2020-05-7 Nader Helmy, Mattr
|
||
<blockquote>
|
||
<p>Linked Data Signatures provide a simple security protocol which is native to JSON-LD. They are built to compactly represent proof chains and allow a VC to be easily protected on a more granular basis; per-attribute, instead of per-credential. These features support a much more robust security model which has broader implications downstream from VCs, especially in terms of size and efficiency.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="development">Development</h2>
|
||
|
||
<ul>
|
||
<li>[MDL, JWT-VC, LD-Proofs] <a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html#name-ldp-vcs">OpenID for Verifiable Presentations</a> 2022-12-30 OpenID
|
||
<blockquote>
|
||
<p>This specification defines mechanisms to</p>
|
||
<ul>
|
||
<li>request presentation of Verifiable Credentials in arbitrary formats.</li>
|
||
<li>provide a verifier with one or more Verifiable Presentations in a secure fashion.</li>
|
||
<li>customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].</li>
|
||
<li>combine the credential presentation with user authentication through [SIOPv2].</li>
|
||
<li>combine the credential presentation with the issuance of OAuth access tokens.</li>
|
||
</ul>
|
||
</blockquote>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="W3C" /><category term="Verifiable Credentials" /><category term="JSON-LD" /><category term="Data Integrity" /><summary type="html">Starting with the name, JSON-LD stands for JavaScript Object Notation with Linked Data. JSON-LD is a method of encoding linked data using JSON. The term “JSON-LD Credential” alone is somewhat ambiguous but the way it is colloquially used, it means a W3C Verifiable Credential Data Model compliant credential signed using Linked Data Proofs. These are more precisely referred to as ~~Linked Data Proof~~ [Data Integrity Proofs] Verifiable Credentials (LDP-VCs).</summary></entry><entry><title type="html">Verifiable Credentials (ZKP-CL) Anoncreds</title><link href="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/zkp-cl_anoncreds/" rel="alternate" type="text/html" title="Verifiable Credentials (ZKP-CL) Anoncreds" /><published>2023-09-08T00:00:00+13:00</published><updated>2023-09-29T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/verifiable-credentials/VC-ZKP-CL</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/zkp-cl_anoncreds/"><h2 id="main">Main</h2>
|
||
<p><a href="https://www.hyperledger.org/use/anoncreds">Website</a> - <a href="https://github.com/hyperledger/anoncreds-spec">Specification</a> - <a href="https://github.com/hyperledger/anoncreds-spec-v2">Specification V2</a></p>
|
||
|
||
<blockquote>
|
||
<p>Hyperledger AnonCreds – short for “Anonymous Credentials”- is the most commonly used Verifiable Credential (VC) format in the world. Ledger agnostic and with a formal open specification, AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.</p>
|
||
</blockquote>
|
||
|
||
<ul>
|
||
<li><a href="https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/">Hyperledger launches new digital identity project, AnonCreds</a> 2022-11-15
|
||
<blockquote>
|
||
<p>The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf">Verifiable Credentials Flavors Explained</a> 2021 CCI Kaliya ‘Identity Woman’ Young
|
||
<blockquote>
|
||
<p>ZKP-CL: This credential format was created specifically to leverage the <a href="https://link.springer.com/chapter/10.1007/3-540-36413-7_20">CL Signatures</a>. JSON-JWT and JSON-LD Signatures each have their own way of representing the meaning of the attributes within a VC. JSON-JWT references an IANA registry and assumes a “closed world” authority model based on that authoritative registry. JSON-LD Signatures use an @context field to reference existing RDF mapping to known dictionaries and assumes an open world model where new terms and definitions can easily be introduced</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Literature] <a href="https://cs.brown.edu/people/alysyans/papers/camlys02b.pdf">A Signature Scheme with Efficient Protocols</a> 2001 Jan Camenisch IBM Zurich, Anna Lysyanskaya Brown
|
||
<blockquote>
|
||
<p>Digital signature schemes are a fundamental cryptographic primitive, of use both in its own right, and as a building block in cryptographic protocol design. In this paper, we propose a practical and provably secure signature scheme and show protocols (1) for issuing a signature on a committed value (so the signer has no information about the signed value), and (2) for proving knowledge of a signature on a committed value. This signature scheme and corresponding protocols are a building block for the design of anonymity-enhancing cryptographic systems, such as electronic cash, group signatures, and anonymous credential systems. The security of our signature scheme and protocols relies on the Strong RSA assumption. These results are a generalization of the anonymous credential system of Camenisch and Lysyanskaya</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="working-group">Working Group</h2>
|
||
<ul>
|
||
<li><a href="https://wiki.hyperledger.org/display/ANONCREDS/AnonCreds+Specification+Working+Group">AnonCreds Specification Working Group</a> 2022-11-02
|
||
<blockquote>
|
||
<p>The AnonCreds Specification Working Group operates under the Community Specification License v1.0 to create the AnonCreds Specification. Current work is focused on Version 1.0 of the specification that covers the current CL-Signatures-based implementation of AnonCreds agnostic to the underlying ledger.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li>[Video] <a href="https://www.youtube.com/watch?v=sUcstipdEm8">Hyperledger AnonCreds Specification Working Group</a> 2023-06-19 Hyperledger Foundation
|
||
<blockquote>
|
||
<p>The big thing I want to talk about was a couple of things on revocation approaches and and go over possibilities. There, there’s a few things happening that I wanted to share. […] as I mentioned in our credits announcements, the 0.1.0 rust implementation was officially released</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="development">Development</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://www.youtube.com/watch?v=1RrJky42dvg">Hyperledger AnonCreds Workshop: Using ZKP Verifiable Credentials Everywhere</a> 2023-05-31 Hyperledger Foundation
|
||
<blockquote>
|
||
<p>AnonCreds was accepted as an Incubated project at Hyperledger in late 2022. This is the first workshop developed by this community and it is intended for anyone interested in using Zero Knowledge Proofs (ZKPs) in a wide variety of contexts.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://github.com/hyperledger/anoncreds-rs">anoncreds-rs</a> 2023-06-02 Hyperledger
|
||
<blockquote>
|
||
<p>Rust library and reference implementation of the <a href="https://hyperledger.github.io/anoncreds-spec/">Anoncreds V1.0</a> specification.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="background">Background</h2>
|
||
<ul>
|
||
<li><a href="https://hackmd.io/S6e2MeSWTICnV9lD9OukKg">Wrapping Indy Credentials (AnonCreds) in W3C VCs</a> 2021-04-12 Finema
|
||
<blockquote>
|
||
<p>AnonCreds are typically bound to a holder by using a link secret and not by issuing a credential to a public DID. In order to add such a credential (or a subset of attributes) to the public profile, we suggest the following mechanism which expresses the intent: I self-attest that I have this credential with the specific attribute values, if you require a proof you can ask me using the Aries present proof protocol.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/finema/anonymous-credential-part-2-selective-disclosure-and-cl-signature-b904a93a1565">Anonymous Credential Part 2: Selective Disclosure and CL Signature</a> 2021-02-04 Finema
|
||
<blockquote>
|
||
<p>selective disclosure and an anonymous credential (Anoncred) relies on an efficient signature scheme that supports multiple messages with a single signature. One such signature scheme is known as CL signature that is named after its Jan Camenisch and Anna Lysyanskaya […] CL signature popularized Anoncreds, and it also served as a cryptographic building block in Identity Mixer (Idemix) and Hyperledger Indy projects.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/finema/anonymous-credential-part-1-brief-overview-and-history-c6679034c914">Anonymous Credential Part 1: Brief Overview and History</a> 2020-10-01
|
||
<blockquote>
|
||
<p>An anonymous credential (Anoncred), which is also known as an attribute-based credential (ABC), is a concept for a digital credential that provides a credential holder maximal privacy and an ability to selectively disclose their personal information.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.goodaudience.com/cl-signatures-for-anonymous-credentials-93980f720d99">CL Signatures for Anonymous Credentials</a> 2019-01-14 Will Abramson
|
||
<blockquote>
|
||
<p>A CL Signature is a signature scheme developed by Jan Camenisch and Anna Lysyanskaya. This scheme has some properties that make it ideal for use in an anonymous credential system and is, in fact, the scheme that Sovrin, and I am sure others, currently use. In this post, I will try to synthesise my current understanding of this scheme, including a look at how Sovrin uses it in practice.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/AttributeBasedCredentials_and_VariableLengthDataGraphs.md">Attribute Based Credentials and Variable Length Data Graphs</a> 2018-02-28
|
||
<blockquote>
|
||
<p>In an effort to allow JSON-LD data structures to leverage attribute based credentials and zero knowledge signature schemes, this paper outlines differences, requirements and possible options for representing JSON-LD data in attribute based credential schemes such as the one in use by the Sovrin network, implemented in the Hyperledger Indy project.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="critique">Critique</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://identitywoman.net/being-real-about-hyperledger-indy-aries-anoncreds/">Being “Real” about Hyperledger Indy &amp; Aries / Anoncreds</a> 2022-09-10 IdentityWoman
|
||
<blockquote>
|
||
<p>This article surfaces a synthesis of challenges / concerns about Hyperledger Indy &amp; Aries / Anoncreds, the most marketed Self-Sovereign Identity technical stack. It is aimed to provide both business and technical decision makers a better understanding of the real technical issues and related business risks of Hyperledger Indy &amp; Aries / Anoncreds, which have not been shared and discussed openly or publicly as the author believes need to be.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="response">Response</h3>
|
||
|
||
<ul>
|
||
<li><a href="https://www.ledgerinsights.com/hyperledger-digital-identity-anoncreds-verifiable-credentials-privacy/">Hyperledger launches new digital identity project, AnonCreds</a> 2022-11-15
|
||
<blockquote>
|
||
<p>The technology itself is not new, as it was originally part of Hyperledger Indy, the digital identity ledger project. However, it has now been separated from Indy so that it can be used for verifiable credentials on ledgers such as Hyperledger Fabric or Ethereum-based Hyperledger Besu, or others.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://kyledenhartog.com/response-to-anoncreds-criticism/">A response to Identity Woman’s recent blog post about Anoncreds</a> 2022-09-08 Kyle Den Hartog
|
||
<blockquote>
|
||
<p>It’s only when I started to take a step back that I realized that the architecture of Indy being a private, permissioned ledger leaves it heading in the same direction as many large corporations now extinct browser and intranet projects for many of the same reasons.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://trinsic.id/moving-toward-identity-technology-ready-for-mass-adoption/">Moving Toward Identity Technology Ready for Mass Adoption</a> 2022-09-09 Trinsic
|
||
<blockquote>
|
||
<p>when we realized our customers were facing critical limitations caused by the underlying tech stack, we began developing an updated version of our platform that would reduce our dependency on these technologies and enable a better platform for our customers.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://daniel-hardman.medium.com/response-to-kaliyas-being-real-post-13fddb9410f0">Response to Kaliya’s “Being Real” Post</a></li>
|
||
</ul>
|
||
|
||
<p><strong>Link Secrets and Privacy-Trust Paper</strong></p>
|
||
<ul>
|
||
<li>Significant section of critique discusses link secrets</li>
|
||
<li>Repeats old claim they are insecure</li>
|
||
<li>Cites 2019 paper by Arnold and Longley for support</li>
|
||
<li>Assertion made that the paper has inaccuracies and misrepresentations</li>
|
||
<li>Rebuttal sent to W3C CCG with supporting documentation</li>
|
||
<li>Encourages reading both sources before deciding on credential security</li>
|
||
</ul>
|
||
|
||
<p><strong>Misunderstanding About Credential Formats (AnonCreds vs. VC Spec)</strong></p>
|
||
<ul>
|
||
<li>Differences in how “credential” is defined between AnonCreds and VC spec</li>
|
||
<li>AnonCreds’ internal “credentials” are not designed for sharing or verification</li>
|
||
<li>Verifiable AnonCreds “proofs” should be evaluated as verifiable credentials</li>
|
||
<li>Interoperability work focuses on proofs, not credential formats per se</li>
|
||
<li>Mapping between AnonCreds proofs and VC data model already exists</li>
|
||
<li>Lack of willingness to alter UX and messaging may hinder interoperability</li>
|
||
</ul>
|
||
|
||
<h2 id="prior-work">Prior Work</h2>
|
||
<ul>
|
||
<li><a href="https://forum.sovrin.org/t/how-idemex-is-implemented-in-sovrin-indy/">How is IDEMix Implemented?</a>
|
||
<blockquote>
|
||
<p>Identity Mixer is not directly (re)implemented by Sovrin, but its cryptographic foundations are very similar, and Sovrin’s implementation includes most of its extended features (predicates, multi-credential, revocation, advanced issuance…). One of the researchers who helped to create Identity Mixer is on Sovrin’s Technical Governance Board and has offered insight to keep the implementations aligned on goals and methods.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://idemix.wordpress.com/">IDEMIX Blog</a></li>
|
||
<li><a href="https://abc4trust.eu/">ABC4Trust—Attribute-based Credentials for Trust</a></li>
|
||
<li><a href="https://github.com/p2abcengine/p2abcengine/wiki/Concepts-and-features">Concepts and Features of Privacy-Preserving Attribute-Based Credentials</a></li>
|
||
<li><a href="http://dl.ifip.org/db/conf/idman/idman2013/CamenischDLNPP13.pdf">Concepts and Languages for Privacy-Preserving Attribute-Based Authentication</a></li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="W3C" /><category term="Verifiable Credentials" /><category term="Hyperledger Foundation" /><category term="IBM" /><category term="IDEMIX" /><category term="Anoncreds" /><category term="Sovrin Foundation" /><category term="Evernym" /><category term="ZKP-CL" /><summary type="html">This credential format was created specifically to leverage the CL Signatures. JSON-JWT and JSON-LD Signatures each have their own way of representing the meaning of the attributes within a VC. JSON-JWT references an IANA registry and assumes a “closed world” authority model based on that authoritative registry. JSON-LD Signatures use an @context field to reference existing RDF mapping to known dictionaries and assumes an open world model where new terms and definitions can easily be introduced</summary></entry><entry><title type="html">Verifiable Credentials - Working Groups, Standards and Development</title><link href="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/standards-and-development/" rel="alternate" type="text/html" title="Verifiable Credentials - Working Groups, Standards and Development" /><published>2023-08-29T00:00:00+13:00</published><updated>2023-08-29T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/verifiable-credentials/VCs-Standards-and-Development</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/verifiable-credentials/standards-and-development/"></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="W3C" /><category term="Verifiable Credentials" /><category term="Credentials Community Group" /><category term="VC-WG" /><category term="JSON-LD" /><category term="OAuth" /><category term="FIDO" /><category term="Claims and Credentials WG" /><summary type="html">Verifiable credentials (VCs) are the electronic equivalent of the physical credentials that we all possess today, such as: plastic cards, passports, driving licenses, qualifications and awards, etc. The data model for verifiable credentials is a World Wide Web Consortium Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web" published 19 November 2019.</summary></entry><entry><title type="html">DID Methods - Various</title><link href="https://decentralized-id.com/web-standards/w3c/decentralized-identifier/did-methods/" rel="alternate" type="text/html" title="DID Methods - Various" /><published>2023-08-18T00:00:00+13:00</published><updated>2023-08-18T00:00:00+13:00</updated><id>https://decentralized-id.com/web-standards/w3c/decentralized-identifier/DID-Methods</id><content type="html" xml:base="https://decentralized-id.com/web-standards/w3c/decentralized-identifier/did-methods/"></content><author><name>DIDecentral</name></author><category term="Verifiable Credentials and Decentralized Identifiers" /><category term="51nodes" /><category term="ABT Network" /><category term="Aergo" /><category term="Alastria" /><category term="ArcBlock" /><category term="Ardor" /><category term="Baidu" /><category term="BCGov" /><category term="Besu" /><category term="BIF" /><category term="BiiLabs" /><category term="Binance" /><category term="Bitcoin" /><category term="BlockchainCommons" /><category term="Blockcore" /><category term="Blocko" /><category term="Blockstack" /><category term="BOTLabs" /><category term="bryk" /><category term="BSC" /><category term="Teleinfo CAICT" /><category term="Celo" /><category term="Ceramic Network" /><category term="Chainyard" /><category term="Cloudchain" /><category term="Commercio" /><category term="Consensys" /><category term="Consent" /><category term="Corda" /><category term="Cosmos" /><category term="Credentials Community Group" /><category term="cryptonics" /><category term="DID:AERGO" /><category term="DID:ALA" /><category term="DID:AVVCYBER" /><category term="DID:BBA" /><category term="DID:BID" /><category term="DID:BNB" /><category term="DID:BRYK" /><category term="DID:BTCR" /><category term="DID:CCP" /><category term="DID:CELO" /><category term="DID:COM" /><category term="DID:CORDA" /><category term="DID:DID" /><category term="DID:DOCK" /><category term="DID:DOGE" /><category term="DID:ECHO" /><category term="DID:ELASTOS" /><category term="DID:ELEM" /><category term="DID:EMTRUST" /><category term="DID:EOS" /><category term="DID:ERC725" /><category term="DID:ETHO" /><category term="DID:ETHR" /><category term="DID:EVAN" /><category term="DID:FACTOM" /><category term="DID:GATC" /><category term="DID:GIT" /><category term="DID:GITHUB" /><category term="DID:GRG" /><category term="DID:HEDERA" /><category term="DID:HOLO" /><category term="DID:ICON" /><category term="DID:INDY" /><category term="DID:IO" /><category term="DID:ION" /><category term="DID:IPID" /><category term="DID:IS" /><category term="DID:IWT" /><category term="DID:JLINC" /><category term="DID:JNCTN" /><category term="DID:JOLO" /><category term="DID:JWK" /><category term="DID:KEY" /><category term="DID:KILT" /><category term="DID:KLAY" /><category term="DID:LIFE" /><category term="DID:META" /><category term="DID:MOAC" /><category term="DID:MORPHEUS" /><category term="DID:NEAR" /><category term="DID:NFT" /><category term="DID:OBJECT" /><category term="DID:OCKAM" /><category term="DID:OMN" /><category term="DID:ONION" /><category term="DID:ONT" /><category term="DID:OP" /><category term="DID:ORB" /><category term="DID:PANACEA" /><category term="DID:PEER" /><category term="DID:PISTIS" /><category term="DID:PKH" /><category term="DID:PTN" /><category term="DID:SAN" /><category term="DID:SCHEMA" /><category term="DID:SELFKEY" /><category term="DID:SIGNOR" /><category term="DID:SIRIUS" /><category term="DID:SOV" /><category term="DID:STACK" /><category term="DID:TAG" /><category term="DID:TANGLE" /><category term="DID:TRUSTBLOC" /><category term="DID:TRX" /><category term="DID:TTM" /><category term="DID:TWIT" /><category term="DID:TYRON" /><category term="DID:TYS" /><category term="DID:TZ" /><category term="DID:UNDID" /><category term="DID:UNISOT" /><category term="DID:UNS" /><category term="DID:V1" /><category term="DID:VAA" /><category term="DID:VAULTIE" /><category term="DID:VID" /><category term="DID:VVO" /><category term="DID:WEB" /><category term="DID:WLK" /><category term="DID:WORK" /><category term="Decentralized Identifiers" /><category term="Digital Bazaar" /><category term="Dock" /><category term="Echo" /><category term="Elastos" /><category term="Element" /><category term="Email" /><category term="EOS" /><category term="ERC725" /><category term="Ethereum" /><category term="Evan Network" /><category term="Evernym" /><category term="Fabric" /><category term="Factom" /><category term="Gatica" /><category term="Github" /><category term="GRGBanking" /><category term="GrgChain" /><category term="Halialabs" /><category term="Hashgraph" /><category term="Holochain" /><category term="Hydra" /><category term="Hyland Credentials" /><category term="hyperledger foundation" /><category term="IBM" /><category term="ICONLOOP" /><category term="IIW" /><category term="Indy" /><category term="InfoWallet" /><category term="ION" /><category term="IOP" /><category term="IOTA" /><category term="IoTeX" /><category term="IPFS" /><category term="JLinc" /><category term="Jnctn" /><category term="Jolocom" /><category term="JWK" /><category term="KILT" /><category term="Klaytn" /><category term="lifeID" /><category term="MediBloc" /><category term="Metadium" /><category term="Microsoft" /><category term="MOAC" /><category term="NEAR" /><category term="Ocean Protocol" /><category term="Ockam" /><category term="OmniOne" /><category term="Ontology" /><category term="Panacea" /><category term="ProximaX" /><category term="Quorum" /><category term="Raonsecure" /><category term="RChain" /><category term="RWoT" /><category term="SecureKey" /><category term="SelfKey Identity" /><category term="SelfKey" /><category term="Sovrin Foundation" /><category term="Sovrin" /><category term="SpaceElephant" /><category term="Sphereon" /><category term="SpruceID" /><category term="Swisscom" /><category term="TIFAC-CORE" /><category term="TMChain" /><category term="Token.TM" /><category term="TOR" /><category term="TranSendX" /><category term="Transmute" /><category term="TRON" /><category term="Twitter" /><category term="UNISOT" /><category term="UNS" /><category term="uPort" /><category term="Vaultie" /><category term="VeramoLabs" /><category term="Veres One" /><category term="Vivvo" /><category term="VP" /><category term="W3C" /><category term="Weelink" /><category term="Workday" /><category term="YLZ Inc" /><category term="Zilliqa" /><summary type="html">DID methods are the magic ingredient that gives DIDs their flexibility. Before creating any specific DID, you first choose a DID method, which determines how you perform the create, read, update, and deactivate operations on a DID of that method. Once created, each DID includes the name of its method in the identifier itself, so that when you use the DID, others know how to retrieve the associated DID Document that contains the cryptographic material for secure interactions.</summary></entry><entry><title type="html">We Are Open Cooperative</title><link href="https://decentralized-id.com/organizations/we-are-open/" rel="alternate" type="text/html" title="We Are Open Cooperative" /><published>2023-08-13T00:00:00+13:00</published><updated>2023-08-13T00:00:00+13:00</updated><id>https://decentralized-id.com/organizations/we-are-open</id><content type="html" xml:base="https://decentralized-id.com/organizations/we-are-open/"><p><a href="https://weareopen.coop/">Website</a> - <a href="https://blog.weareopen.coop/">Blog</a> - <a href="https://twitter.com/WeAreOpenCoop">Twitter</a> - <a href="https://www.linkedin.com/company/we-are-open-coop/">LinkedIn</a> - <a href="https://mastodon.social/@weareopencoop">Mastadon</a></p>
|
||
|
||
<h2 id="main">Main</h2>
|
||
<ul>
|
||
<li><a href="https://blog.weareopen.coop/open-workplace-recognition-using-verifiable-credentials-fc0134fad7ec">Open Workplace Recognition using Verifiable Credentials</a> 2022-09-30 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>Yesterday, <a href="https://w3c-ccg.github.io/vc-ed-use-cases/">the draft</a> Verifiable Credentials for Education, Employment, and Achievement Use Cases report was published […] The next version of the Open Badges specification (v3.0) will be compatible with Verifiable Credentials (VCs).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/creating-a-culture-of-recognition-39ffdb6cf943">Creating a culture of recognition</a> 2022-09-08 We are Open
|
||
<blockquote>
|
||
<p>Open Recognition is the awareness and appreciation of talents, skills and aspirations in ways that go beyond credentialing. This includes recognising the rights of individuals, communities, and territories to apply their own labels and definitions. Their frameworks may be emergent and/or implicit.”</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/keep-badges-weird-helping-people-understand-the-badges-landscape-79cc8cf7281">Keep Badges Weird: helping people understand the badges landscape</a> 2022-07-25 Doug Belshaw, We Are Open Co-op
|
||
<blockquote>
|
||
<p>Open Recognition is the awareness and appreciation of talents, skills and aspirations in ways that go beyond credentialing. This includes recognising the rights of individuals, communities, and territories to apply their own labels and definitions. Their frameworks may be emergent and/or implicit.” (<a href="https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629">What is Open Recognition, anyway?</a></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/how-badges-can-change-the-world-65395581f90c">How badges can change the world: Part 2: Why we need to transition</a> 2022-06-15 We are Open
|
||
<blockquote>
|
||
<p>In <a href="https://blog.weareopen.coop/how-badges-can-change-the-world-73529560caa3">Part 1: The Two Loops Model for Open Recognition advocacy</a>, we talked about how as one system begins to deteriorate, an alternative begins to emerge. We know the alternative system, one that integrates credentials with other forms of recognition, is better for everyone. Without that integration, cold-hard credentialing supports outdated power dynamics.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/how-badges-can-change-the-world-73529560caa3">How badges can change the world</a> 2022-06-07 WeareOpen
|
||
<blockquote>
|
||
<p><a href="https://www.youtube.com/watch?v=ZcyHKKc2LVg">This model</a> […] shows how systems have a lifespan and what happens as that lifespan peaks.</p>
|
||
|
||
<p>As one system begins to deteriorate, a new system begins to emerge. This got us thinking about how this model applies to the world of <a href="https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629">Open Recognition</a>.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/open-recognition-is-for-every-type-of-learning-ffd137a6fe17">Open Recognition is for every type of learning</a> 2022-06-01 We are Open Coop - From cold hard credentialing to warm fuzzy recognition
|
||
<blockquote>
|
||
<p>We need all to embrace all kinds of learning and develop ways of recognising it in others. We need to develop methods that allow us to embrace our whole self, reinforce positive behaviours in our communities, encourage lifelong learning, and which contribute to the good of society.
|
||
<img src="https://i.imgur.com/ZUWXvdY.png" alt="" /></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629">What is Open Recognition, anyway?</a> 2022-05-18 We are Open Going
|
||
<blockquote>
|
||
<p>beyond credentialing and the formal/informal divide<br />
|
||
Badges as credentials includes approaches that are well understood and largely replace or augment existing certification practices. Badges for recognition, however, include approaches that remain somewhat confusing to many people.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/wtf-are-stealth-badges-41130a75a1a9">WTF are ‘Stealth Badges’?: The case of the O.G. Badger</a> 2022-01-26 We are Open Coop
|
||
<blockquote>
|
||
<p>This information means that this particular badge, which is manually issued, can be given out in fair and equitable ways. It also means that someone else who engaged with the Open Badges community before 2017 could lay claim to it.</p>
|
||
|
||
<p>Stealth badges at scale require an automated system that issues badges depending on particular criteria. This is why they are very common in games-based environments. For example, I unlock some most weeks playing new and existing games on my PlayStation and Google Stadia.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://kayaelle.medium.com/in-the-w3c-vc-edu-call-on-june7-2021-we-discussed-open-badges-asserted-as-w3c-verifiable-90391cb9a7b7">Open Badges as Verifiable Credentials</a> 2021-06-11 Kerri Lemoie
|
||
<blockquote>
|
||
<p>In the <a href="https://w3c-ccg.github.io/vc-ed/">W3C VC-EDU</a> call on June 7, 2021 we discussed <a href="https://openbadges.org/">Open Badges</a> asserted as <a href="https://www.w3.org/TR/vc-data-model/">W3C Verifiable Credentials</a> (VCs). This call began the public discussion of Open Badges as Native VCs (potentially as Open Badges 3.0) to inform the IMS Open Badges Working Group. Why are we discussing this? Why does it matter? How will it work?</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://app.participate.com/communities/keep-badges-weird/62003f3f-a7ba-4f6a-990a-64d6f893016d/announcements/0bc15852-0f91-48c8-a7ca-478b246b553c">Discover Open Badges 3.0!</a> 2021 Keep Badges Weird
|
||
<blockquote>
|
||
<ol>
|
||
<li>Check out the (accepted) <a href="https://github.com/IMSGlobal/openbadges-specification/files/6977048/Proposal-Open-Badges-3.0-update-08-11-2021.pdf">Open Badges 3.0 proposal</a></li>
|
||
<li><a href="https://www.youtube.com/watch?v=QDGPwR1F3FY&amp;t=1357s">Watch a video</a> from the ePIC conference giving an overview of what Open Badges 3.0 will enable (or view the <a href="https://docs.google.com/presentation/d/1NEJoQaI9b6KC1EFDDhR3MGybGVoa0R3bQh0xuKtUKkY">slide deck</a></li>
|
||
<li>Discuss what this means for you, your organisation, or your community in <a href="https://app.participate.com/discussions/open-badges-3-0/68917656-db8f-4932-88fd-153fdb54e285">this thread</a></li>
|
||
</ol>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="organization">Organization</h2>
|
||
<ul>
|
||
<li><a href="https://blog.weareopen.coop/catalysing-the-kbw-community-fa89db943418">Catalysing the KBW community</a> 2022-03-15 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>This post shows how being intentional about community building can help people feel welcome, safe, and able to contribute. It explores three ways in which <a href="https://weareopen.coop/">WAO</a> has collaborated with <a href="https://participate.com/">Participate</a> to do this</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/keep-badges-weird-is-about-breaking-boundaries-42afb0415826">Keep Badges Weird is about breaking boundaries: How the KBW community is convening systems</a> 2022-07-30 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>KBW helps people understand the badge landscape. The community is there to provide solidarity for badge champions and newbies. We do not assume prior knowledge of Open Badges or Verifiable Credentials. We recognise and celebrate those who can share their experience. Anyone interested in badges or integrating <a href="https://blog.weareopen.coop/what-is-open-recognition-anyway-9f38ec1f8629">Open Recognition</a> are welcome to join.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/wao-wraps-up-for-the-holidays-c85bff4c910c">WAO wraps up for the holidays</a> 2021-12-17 We Are Open Cooperative
|
||
<blockquote>
|
||
<p>In May, we did some <a href="https://weareopen.coop/near/">workshopping with the crypto platform NEAR</a>, which was the first time we accepted cryptocurrency as part of our fee. In May, We Are Open Cooperative also <a href="https://blog.weareopen.coop/wao-turns-five-30747f4df0f9">turned 5 years old</a>. We celebrated this momentous occasion by launching our <a href="https://weareopen.coop/">new website</a> and adding more stuff to our <a href="https://learnwith.weareopen.coop/">free learning resource hub</a>.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/keep-badges-weird-e26a1b055ff5">Keep Badges Weird… at the Badge Summit</a> 2021-10-25 We are Open
|
||
<blockquote>
|
||
<p>We have a new suite of badges to encourage participation, create value for others, and reflect on that experience. Participants will be able to both earn AND award badges, so they’ll have a chance to prove that they’ve understood the theory surrounding CoPs and badges as well as put those theories into practice.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="community-development">Community Development</h2>
|
||
<ul>
|
||
<li><a href="https://blog.weareopen.coop/how-to-unf-ck-your-organisation-b73851dbeba5">How to Unf*ck Your Organisation: Organisational strategy and architecture for n00bs</a> 2022-10-06 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>We’ve put together an <a href="https://learnwith.weareopen.coop/courses/org-strategy/">email-based course</a> to help forward-thinking people in senior roles who might need a bit of help and orientation. We’ve broken things down into actionable steps based on the resources found at our Learn with WAO site, giving you enough direction and inspiration to get started transforming your organisation for the better!</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/steps-to-success-when-building-a-community-of-practice-15bd7ed9ac5c">Steps to Success when building a Community of Practice: Convening systems for maturity and development</a> 2022-10-05 Doug Belshaw, WeAreOpenCoop
|
||
<blockquote>
|
||
<p>This post outlines different types of work that needs to take place when planning, sustaining, and developing a Community of Practice. It is informed by work that <a href="https://weareopen.coop/">WAO</a> have carried out with <a href="https://participate.com/">Participate</a> around the [Keep Badges Weird]-(https://badges.community/) community over the last 10 months.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/quick-wins-to-improve-your-open-source-communitys-architecture-of-participation-9d0e6c8d60fe">Quick wins to improve your Open Source community’s Architecture of Participation</a> 2022-07-13 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>Sociocracy is a system of governance that seeks to create psychologically safe environments and productive organizations. It draws on the use of consent, rather than majority voting, in discussion and decision-making by people who have a shared goal or work process.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/emergent-community-building-a35f9431d8a">Emergent community building</a> 2022-02-15 WeAreOpenCoop
|
||
<blockquote>
|
||
<p>Last week, we ran the first Keep Badges Weird community call, and it was even more energising than we expected it to be. We were so pleased to see so many people interested in the current and future status of badges and open recognition. We were elated to begin to have a deep conversation about counteracting the top-down focus of institutions and large organisations using badges for corporate stuff. There’s an outstanding question, for us, around how this community explores and thinks about the theoretical underpinnings of a Community of Practice (CoP), but one thing is for sure, Keep Badges Weird is a CoP.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="thoughtful">Thoughtful</h2>
|
||
<ul>
|
||
<li><a href="https://blog.weareopen.coop/audience-ikigai-be0cebe4cea">Audience Ikigai - An attempt to simplify complexity in content</a> 2022-03-09 Laura Hilliger, We Are Open Co-op<br />
|
||
<em>could be useful for thinking about credential adoption profiles</em>
|
||
<blockquote>
|
||
<p>The complexity surrounding any global audience can’t be understated, really. I mean, we’re talking about millions of people. GPI communications have to take into account that many are coming to Greenpeace for the first time, while others know the organization well. The audience is diverse. From young to old, every color and creed, a massive spectrum of people who are interested in the mission to “ensure the ability of the earth to nurture life in all its diversity.”</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://blog.weareopen.coop/good-things-happen-slowly-bad-things-happen-fast-2fd894cbd4df">Good things happen slowly, bad things happen fast</a> 2021-11-30 We Are Open Co-op
|
||
<blockquote>
|
||
<p>Some organisations were experimenting with digital badges before 2011, but these were siloed and easy to right-click and copy. The ‘technology trigger’, the innovation with Open Badges, was to invent and make available an open metadata standard.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="ecosystem">Ecosystem</h2>
|
||
<ul>
|
||
<li><a href="https://blog.weareopen.coop/reflecting-on-the-evolving-badges-and-credentials-ecosystem-6efac4d673d3">Reflecting on the Evolving Badges and Credentials Ecosystem</a> 2021-11-25 We are Open
|
||
<blockquote>
|
||
<p>Recently, the WAO team took the opportunity to update the badge platforms page on Badge Wiki, a knowledgebase for the Open Badge community. As the ecosystem continues to evolve we’re seeing some early platforms fall by the wayside and new platforms emerge.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://badge.wiki/wiki/Badge_platforms">Badge Platforms</a> Badge Wiki
|
||
<blockquote>
|
||
<p>A list of all platforms accredited by1EdTech (the artist formerly known as IMS Global Learning Consortium) can be found <a href="https://site.imsglobal.org/certifications?refinementList%5Bstandards_lvlx%5D%5B0%5D=Open%20Badges">here</a>. This page does not currently list LMS systems that also issue badges.</p>
|
||
<ol>
|
||
<li>Accredible</li>
|
||
<li>Badgecraft</li>
|
||
<li>BadgeCollect</li>
|
||
<li>Badge List</li>
|
||
<li>BadgeFactor</li>
|
||
<li>BadgeOS</li>
|
||
<li>Badgetree™</li>
|
||
<li>BCdiploma</li>
|
||
<li>Bestr</li>
|
||
<li>CanCred.ca</li>
|
||
<li>Canvas Credentials</li>
|
||
<li>Credly</li>
|
||
<li>ForAllRubrics</li>
|
||
<li>HPass</li>
|
||
<li>Hyland Credentials</li>
|
||
<li>Milestone</li>
|
||
<li>NOCTI and Nocti Business Solutions (NBS)</li>
|
||
<li>Open Badge Factory</li>
|
||
<li>Openbadges.me</li>
|
||
<li>Participate</li>
|
||
<li>RedCritter</li>
|
||
<li>Sertifier</li>
|
||
<li>VerifyEd</li>
|
||
</ol>
|
||
</blockquote>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Community Orgs" /><category term="We are Open" /><category term="Open Badges" /><category term="Open Recognition" /><category term="Accredible" /><category term="Badgecraft" /><category term="Open Recognition" /><category term="Keep Badges Weird" /><category term="BadgeCollect" /><category term="Badge List" /><category term="BadgeFactor" /><category term="BadgeOS" /><category term="Badgetree™" /><category term="BCdiploma" /><category term="Bestr" /><category term="CanCred.ca" /><category term="Canvas Credentials" /><category term="Credly" /><category term="ForAllRubrics" /><category term="HPass" /><category term="Hyland Credentials" /><category term="Milestone" /><category term="NOCTI" /><category term="Open Badge Factory" /><category term="Openbadges.me" /><category term="Participate" /><category term="RedCritter" /><category term="Sertifier" /><category term="VerifyEd" /><summary type="html">We’re a collective of independent thinkers and makers helping charities, ethical companies, government departments and educational institutions with sensemaking and digital transformation.</summary></entry><entry><title type="html">OpenID Foundation</title><link href="https://decentralized-id.com/organizations/openid/" rel="alternate" type="text/html" title="OpenID Foundation" /><published>2023-08-12T00:00:00+13:00</published><updated>2023-08-12T00:00:00+13:00</updated><id>https://decentralized-id.com/organizations/openid</id><content type="html" xml:base="https://decentralized-id.com/organizations/openid/"><h2 id="main">Main</h2>
|
||
|
||
<ul>
|
||
<li><a href="https://openid.net/final-version-of-open-banking-and-open-data-ready-to-cross-borders-whitepaper-published/">OpenID Foundation Publishes “Open Banking and Open Data: Ready to Cross Borders?”</a> 2023-02-06 OpenID
|
||
<blockquote>
|
||
<p>More than 50 open data, digital identity and API security technologists globally contributed to this whitepaper to answer the following questions:</p>
|
||
<ol>
|
||
<li>What are the differences and similarities between different open data ecosystems?</li>
|
||
<li>Is global interoperability between different ecosystems possible?</li>
|
||
<li>Who will be driving this movement and what are the use cases motivating them? How will users benefit?</li>
|
||
<li>How could cross-border use cases work and what “good might look like”? What are the architecture and governance requirements?</li>
|
||
<li>What can you do if you believe this is the right direction for Open Banking and Open Data?</li>
|
||
</ol>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.openid.net/openid-foundation-publishes-the-global-open-health-movement-empowering-people-and-saving-lives-by-unlocking-data-whitepaper/">OpenID Foundation Publishes “The Global Open Health Movement: Empowering People and Saving Lives by Unlocking Data” Whitepaper</a> 2022-07-22 OpenID
|
||
<blockquote>
|
||
<p>The whitepaper offers an overview of the global health sector privacy and security landscape and introduces similar work from outside the health domain with health experts. One key hypothesis we will test is that existing Open Banking and other Open Data standards, like FAPI, could help the health community deliver on their Open Health goals more quickly.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="http://openid.net/wordpress-content/uploads/2022/05/OIDF-Whitepaper_OpenID-for-Verifiable-Credentials_FINAL_2022-05-12.pdf">OpenID for Verifiable Credentials</a> 2022-05-12 OpenID
|
||
<blockquote>
|
||
<p>The goal of this whitepaper is to inform and educate the readers about the work on the OpenID for Verifiable Credentials (OpenID4VC) specifications family. It addresses use-cases referred to as Self-Sovereign Identity, Decentralized Identity, or User-Centric Identity.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2022/03/18/openid-foundation-publishes-whitepaper-on-open-banking/">OpenID Foundation Publishes Whitepaper on Open Banking</a> 2022-03-18 OpenID
|
||
<blockquote>
|
||
<p>The OpenID Foundation is pleased to share its new whitepaper, “<a href="https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf">Open Banking, Open Data and Financial-Grade APIs</a>”. The paper documents the international movement towards Open Banking, Open Finance, and secure, consent driven access to all user data. It describes the OpenID Foundation and in particular the Financial-Grade API (FAPI) Working Group’s experience with Open Banking ecosystems internationally.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2021/04/10/the-7-laws-of-identity-standards/">The 7 Laws of Identity Standards</a> 2021-04-10 OpenID
|
||
<blockquote>
|
||
<ol>
|
||
<li>A identity standard’s adoption is driven by its value of the reliability, repeatability and security of its implementations.</li>
|
||
<li>A standard’s value can be measured by the number of instances of certified technical conformance extant in the market.</li>
|
||
<li>Certified technical conformance is necessary but insufficient for global adoption.</li>
|
||
<li>Adoption at scale requires widespread awareness, ongoing technical improvement and a open and authoritative reference source.</li>
|
||
<li>When Libraries/Directories/ Registries act as authoritative sources they amplify awareness, extend adoption and promote certification.</li>
|
||
<li>Certified technical conformance importantly complements legal compliance and together optimize interoperability.</li>
|
||
<li>Interoperability enhances security, contains costs and drives profitability.</li>
|
||
</ol>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="organization">Organization</h2>
|
||
<ul>
|
||
<li><a href="http://openid.net/wordpress-content/uploads/2022/05/OIDF_Workshop-at-EIC_FINAL_2022-05-11.pptx">How OpenID Standards are Enabling Secure &amp; Interoperable Digital Identity Ecosystems</a> 2022-05-11 OpenID
|
||
<blockquote>
|
||
<p><img src="https://i.imgur.com/XvzvZMM.png" alt="" /></p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2021/12/10/okta-joins-the-openid-foundation-board-to-further-advance-open-identity-standards/">Okta Joins the OpenID Foundation Board to Further Advance Open Identity Standards</a> 2021-12-10 OpenID
|
||
<blockquote>
|
||
<p>“OpenID Connect is one of the most adopted identity standards, providing essential functionality to core solutions across the industry,” said Vittorio Bertocci, Principal Architect, Auth0.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2021/12/07/the-openid-foundation-welcomes-visa-to-the-board-of-directors/">The OpenID Foundation Welcomes Visa to the Board of Directors</a> 2021-12-07 OpenID
|
||
<blockquote>
|
||
<p>Visa’s leadership in global payments and identity services as well as their longstanding commitment to standards will be of great value as we tailor our strategy to this moment.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://self-issued.info/?p=2170">Passing the Torch at the OpenID Foundation</a> 2021-04-28 Mike Jones
|
||
<blockquote>
|
||
<p>Today marks an important milestone in the life of the OpenID Foundation and the worldwide digital identity community. Following <a href="https://openid.net/2021/02/19/resolution-thanking-don-thibeau-for-his-service/">Don Thibeau’s decade of exemplary service to the OpenID Foundation as its Executive Director</a>, today we <a href="https://openid.net/2021/04/28/welcoming-gail-hodges-as-our-new-executive-director/">welcomed Gail Hodges as our new Executive Director</a>.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2021/02/09/2021-openid-foundation-board-update/">2021 OpenID Foundation Board Update</a> 2021-02-09 OpenID
|
||
<blockquote>
|
||
<p>Nat Sakimura and John Bradley were re-elected to new two-year terms as community member representatives. Nat and John’s well-known technical expertise and global thought leadership ensures continuity across working groups and as the Foundation transitions to new leadership in 2021.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="standards-development">Standards Development</h2>
|
||
<ul>
|
||
<li><a href="https://self-issued.info/?p=2198">Proof-of-possession (pop) AMR method added to OpenID Enhanced Authentication Profile spec</a> 2021-10-13 Mike Jones
|
||
<blockquote>
|
||
<p>I’ve defined an Authentication Method Reference (AMR) value called “pop” to indicate that Proof-of-possession of a key was performed. Unlike the existing “hwk” (hardware key) and “swk” (software key) methods […] Among other use cases, this AMR method is applicable whenever a <a href="https://www.w3.org/TR/2021/REC-webauthn-2-20210408/">WebAuthn</a> or <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html">FIDO</a> authenticator are used.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h3 id="shared-signals-working-group"><a href="https://openid.net/wg/sharedsignals/">Shared Signals Working Group</a></h3>
|
||
<blockquote>
|
||
<p>The Shared Signals working group is providing data sharing schemas, privacy recommendations and protocols to share security event information to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers and enable users and providers to coordinate to securely restore accounts following a compromise.</p>
|
||
<ul>
|
||
<li><a href="https://openid.net/specs/openid-risc-profile-specification-1_0.html">OpenID RISC Profile Specification 1.0 - draft 02</a> 2022-04-05 OpenID
|
||
This document defines the Risk Incident Sharing and Coordination (RISC) Event Types based on the Shared Signals and Events (SSE) Framework. Event Types are introduced and defined in Security Event Token (SET).</li>
|
||
<li><a href="https://openid.net/2021/08/24/shared-signals-an-open-standard-for-webhooks/">Shared Signals: An Open Standard for Webhooks</a> 2021-08-24 OpenID
|
||
The OpenID Foundation formed the “<a href="https://openid.net/wg/sse/">Shared Signals and Events</a>” (SSE) Working Group as a combination of the previous OpenID RISC working group and an informal industry group that was focused on standardizing <a href="https://cloud.google.com/blog/products/identity-security/re-thinking-federated-identity-with-the-continuous-access-evaluation-protocol">Google’s CAEP proposal</a>. These represented two distinct applications of the same underlying mechanism of managing asynchronous streams of events. Therefore the <a href="https://openid.net/specs/openid-sse-framework-1_0-01.html">SSE Framework</a> is now proposed to be a standard for managing such streams of events for any application, not just CAEP and RISC. In effect, it is a standard for generalized Webhooks.</li>
|
||
<li><a href="https://iiw.idcommons.net/13A/_Security_Event_Tokens,_Subject_Identifiers,_and_SSE/CAEP/RISC_Java_implementation">Security Event Tokens, Subject Identifiers, and SSE/CAEP/RISC Java implementation</a> 2021-05-06 Matt Domsch
|
||
Matt presented an overview of the OpenID Foundation Shared Signals and Events Working Group, and his implementation of the object model in an open source Java library at <a href="https://github.com/sailpoint-oss/openid-sse-model/">https://github.com/sailpoint-oss/openid-sse-model/</a></li>
|
||
<li><a href="https://domsch.com/IIW32/IIW32-openid-sse-model.pdf">OpenID SSE Model - Security Event Tokens, Subject Identifiers, and SSE/CAEP/RISC Java implementation</a> 2021-04-21 Domsch</li>
|
||
<li>Security Event Tokens – RFC 8417\n$5 Matt Domsch, VP &amp; Engineering Fellow</li>
|
||
<li>Subject Identifiers – Internet Draft RFC</li>
|
||
<li>Shared Signals &amp; Events – OpenID Foundation WG</li>
|
||
<li>Includes RISC, CAEP, and Oauth event profiles</li>
|
||
</ul>
|
||
</blockquote>
|
||
|
||
<h2 id="gain">GAIN</h2>
|
||
<ul>
|
||
<li><a href="https://openid.net/2022/06/03/how-gain-happens-slowly-then-all-at-once/">How GAIN Happens, Slowly Then All at Once</a> 2022-06-03 OpenID
|
||
<blockquote>
|
||
<p>GAIN is marked by a cross sector, crowd sourced, open, global due diligence. GAIN’s self organized participants are actively seeking evidence that disconfirms the GAIN hypothesis.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.kuppingercole.com/watch/eic2022-panel-gain-future-internet">Protocols, Standards, Alliances: How to Re-GAIN the Future Internet from the Big Platforms</a> 2022-05-13 Kuppinger Cole
|
||
<blockquote>
|
||
<p>just like trade unions helped the working class during the industrial revolution to fight for their rights. In this panel session, we will discuss about the enablers of such a different approach and the requirements to actually be successfull.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2022/03/02/introducing-the-global-assured-identity-network-gain-proof-of-concept-community-group/">Introducing the Global Assured Identity Network (GAIN) Proof of Concept Community Group</a> 2022-03-02 OpenID
|
||
<blockquote>
|
||
<p>The OpenID Foundation is pleased to announce the launch of the Global Assured Identity Network (GAIN) Proof of Concept Community Group, which aims to test the technical hypotheses underlying the <a href="https://gainforum.org/GAINWhitePaper.pdf">“GAIN Digital Trust”</a> white paper.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2021/09/20/global-assured-identity-network-white-paper/">Global Assured Identity Network White Paper</a> 2021-09-20 OpenID
|
||
<blockquote>
|
||
<p>The Global Assured Identity Network White Paper was the centerpiece of the OpenID Foundation’s Chairman Nat Sakimura’s keynote at the European Identity Conference just a few days ago. His presentation can be found at https://nat.sakimura.org/2021/09/14/announcing-gain/. Nat describes GAIN as an overlay network on top of the Internet with all its participants identity proofed. One key benefit of the approach proposed in the white paper is that the standards required to enable this network already exist: OpenID Connect and eKYC/IDA.</p>
|
||
|
||
<p>The White Paper was a “no logo, pro bono, open source” collaboration of over 150 co-authors including many members of the OpenID Foundation. It’s well on its way to achieving its goal of generating a community wide discussion on the business, technical and legal requirements for pragmatic international interoperability.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.youtube.com/watch?v=QG_gkZkpJwQ">EIC Speaker Spotlight: Nat Sakimura</a> 2021-08-24 Introducing Gain • OpenID Foundation
|
||
<blockquote>
|
||
<p>if you look at the the cost structure of the financial industry a lot of cost Is towards anti-money laundering and related activities and that actually is identity problem […] we should try to solve the use case with a user centricity in mind</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="kim-cameron-award">Kim Cameron Award</h2>
|
||
<ul>
|
||
<li><a href="https://openid.net/2022/07/05/rachelle-sellung-2022-kim-cameron-award/">Kim Cameron Award Winner Reflects on EIC</a> 2022-07-05 Rachelle Sellung
|
||
<blockquote>
|
||
<p>In a matter of a few days, I heard many inspiring presentations, had many interesting conversations, and met many wonderful people in this field at the Conference. It has already led to multiple conversations of working together regarding future stakeholder research that will hopefully be useful and support the identity community.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2022/04/29/2022-openid-foundation-kim-cameron-award-recipients-announced/">2022 OpenID Foundation Kim Cameron Award Recipients Announced</a> 2022-04-29 OpenID<br />
|
||
<em>This was the first IIW without Kim Cameron. This was a very fitting announcement.</em>
|
||
<blockquote>
|
||
<p>The OpenID Foundation is pleased to announce the first cohort of awardees for inaugural launch of the Kim Cameron Award Program. We first must thank the many well-qualified applicants who presented compelling interest in user-centric identity.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://openid.net/2022/04/08/announcing-the-2022-openid-foundation-kim-cameron-scholarship/">Announcing the 2022 OpenID Foundation Kim Cameron Scholarship</a> 2022-04-08 OpenID
|
||
<blockquote>
|
||
<p>Scholarship recipients will be studying, researching, interning or working in a field relevant to one or more <a href="https://openid.net/wg/">OpenID Foundation working groups</a> and consistent with Foundation’s Mission. The scholarship recipients will also be invited to participate in Foundation breakout meetings at the European Identity Conference and Identiverse which will provide exposure to both the Foundation’s business as well as leading technologists.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Standards Development Orgs" /><category term="OpenID" /><category term="Open Banking" /><category term="SSE" /><category term="GAIN" /><category term="Standards Development Org" /><summary type="html">Founded in 2007, the OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. We are global vibrant community where identity peers and thought leaders convene to craft the identity ecosystems of tomorrow.</summary></entry><entry><title type="html">Linux Foundation Public Health (LFPH) and the Cardea Project</title><link href="https://decentralized-id.com/organizations/Linux-Foundation-Public-Health_Cardea/" rel="alternate" type="text/html" title="Linux Foundation Public Health (LFPH) and the Cardea Project" /><published>2023-08-12T00:00:00+13:00</published><updated>2023-08-12T00:00:00+13:00</updated><id>https://decentralized-id.com/organizations/lfph</id><content type="html" xml:base="https://decentralized-id.com/organizations/Linux-Foundation-Public-Health_Cardea/"><h2 id="main">Main</h2>
|
||
|
||
<p><a href="https://www.lfph.io/">Website</a> - <a href="https://lfpublichealth.slack.com/">Slack</a> - <a href="https://twitter.com/LFPubHealth">Twitter</a> - <a href="https://www.lfph.io/blog/">Blog</a> - <a href="https://www.youtube.com/channel/UCirEps_wTjsD_oJM_WZJGuA">Youtube</a></p>
|
||
|
||
<ul>
|
||
<li><a href="https://www.lfph.io/2022/08/29/lfph-tackles-the-next-frontier-in-open-source-health-technology-the-rise-of-digital-twins/">LFPH tackles the next frontier in Open Source Health Technology: The rise of Digital Twins</a> 2022-08-29 Jim St. Clair, LFPH
|
||
<blockquote>
|
||
<p>Among the many challenges in our global healthcare delivery landscape, digital health plays an increasingly important role on almost a daily basis, from personal medical devices, to wearables, to new clinical technology and data exchanges. Beyond direct patient care, digital health also applies to diagnostics, drug effectiveness, and treatment delivery. These use cases are being driven by rapid growth in data modeling, artificial intelligence (AI)/machine learning (ML), and data visualization. Given the rapid digitalization of healthcare delivery, emerging digital twin technology is considered the next system that will advance further efforts in medical discoveries and improve clinical and public health outcomes.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/2022/07/29/public-private-partnerships-in-health-the-journey-ahead-for-open-source/">Public-private partnerships in health: The journey ahead for open source</a> Linux Foundation Public Health 2022-07-29
|
||
<blockquote>
|
||
<p>Large-scale healthcare and public-health challenges such as mental health, communicable diseases, diabetes—and even reforming Medicaid—will only be accomplished by consistently bringing all stakeholders to the table, determining how to sustainably support projects, and providing transparent value to patients, populations and public sector agencies. LFPH has pursued a shared vision around leveraging open source to improve our communities, carrying forward the same resolve as the diverse groups that originally came together to create COVID-19 solutions. The open-source journey in public health is only beginning.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/2022/04/19/lfph-completes-the-proof-of-concept-of-its-gccn-trust-registry-network/">LFPH completes the Proof-of-Concept of its GCCN Trust Registry Network</a> 2022-04-19 Lucy Yang, LFPH
|
||
<blockquote>
|
||
<p>Building on the open source TRAIN Trust Management Infrastructure funded by the European Self-Sovereign Identity Framework (ESSIF) Lab, the GCCN Trust Registry Network allows different COVID certificate ecosystems, which can be a political and economic union (e.g. the EU), a nation state (e.g. India), a jurisdiction (e.g. the State of California), an industry organization (e.g. ICAO) or a company (e.g. a COVID test administrator), to join and find each other on a multi-stakeholder network, and validate each other’s COVID certificate policies.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/">The Flavors of Verifiable Credentials</a> 2021-02-11 Linux Foundation Public Health Blog <a href="(https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf)">pdf</a>
|
||
<blockquote>
|
||
<p>The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/2020/07/20/join-with-us-at-linux-foundation-public-health/">Join with us at Linux Foundation Public Health</a> 2020-07-20 Dan Kohn, LFPH
|
||
<blockquote>
|
||
<p>The mission of Linux Foundation Public Health is to use open source software to help public health authorities (PHAs) around the world combat COVID-19 and future epidemics. We’re starting with two exposure notification apps but we expect to host dozens of projects to support all phases of a PHA’s testing, tracing, and isolation activities. We are building a global community of technology and consulting companies, public health authorities, epidemiologists and other public health specialists, privacy and security experts, and individual developers.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul>
|
||
|
||
<h2 id="cardea">Cardea</h2>
|
||
|
||
<p><a href="https://github.com/hyperledger-labs?q=cardea">Github</a> - <a href="https://github.com/hyperledger-labs/cardea">Mailing List</a> - <a href="https://twitter.com/cardeaproject">Twitter</a></p>
|
||
|
||
<ul>
|
||
<li><a href="https://www.lfph.io/2022/09/29/open-source-cardea-project-expands-into-employee-and-student-health-verification/">Open Source Cardea Project Expands into Employee and Student Health Verification</a> 2022-11-29 Trevor Butterworth, LFPH
|
||
<blockquote>
|
||
<p>Many different occupations, along with colleges and universities, have health certification requirements, such as proof of immunization and TB tests. Cardea provides an easy way to render these proofs as privacy-preserving and tamper-proof digital credentials that allow for consent-based sharing of specific data and for that data to expire (which is necessary where annual testing is required).</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://indicio.tech/the-verifiable-credential-solution-to-health-data-sharing/">Verifiable Credential Solution to Health Data Sharing</a> 2022-06-30 Indicio
|
||
<blockquote>
|
||
<p>In proving that tamper-proof health data could be issued to travelers by their health providers and be verified by airlines and other countries without having to check back in with the health provider, Cardea has laid the foundation for something much bigger than Covid testing. Verifiable credential technology provides a way for all kinds of health data to be shared in a privacy-preserving and security-enhanced way.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.lfph.io/2022/03/31/member-profile-series-looking-back-on-cardeas-second-successful-interop-a-thon-indicio%ef%bf%bc/">Member Profile Series: Looking Back on Cardea’s Successful Second Interop-a-thon [Indicio]</a> 2022-05-31 Trevor Butterworth, LFPH
|
||
<blockquote>
|
||
<p>The Cardea project at LFPH is a complete open-source reference implementation for sharing verifiable digital health credentials, with a focus on COVID testing. Built by Indicio for SITA, the world’s largest technology provider to the air transport sector, and successfully trialed in Aruba, Cardea has developed into an open-source community of companies collaborating to extend the codebase features and applications. Central to these goals is interoperability.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://www.youtube.com/watch?v=adFFsPRVcBA&amp;list=PL3LvHy3eIPslC7YhQGXKPN4LvS3ekqfqE&amp;index=2">Cardea Feb 2 2022 Meeting Review and LFPH presentation</a> 2022-02-02
|
||
<blockquote>
|
||
<p>This is our first meeting of february, very exciting, and it is also our first meeting of the Cardea Working Group that is dedicated to sort of high level reintroduction of our project today</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://idramp.com/idramp-joins-linux-foundation-public-health-cardea-project-steering-committee/">IdRamp Joins Linux Foundation Public Health Cardea Project Steering Committee</a> 2021-06-11 IDRamp
|
||
<blockquote>
|
||
<p>The Cardea and GCCN projects are both excellent examples of breakthrough innovations that can take shape when companies and projects come together to solve real-world problems, using open source tools available to everyone</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://medium.com/global-id/globalid-joins-the-linux-foundations-cardea-project-22f298032240">GlobaliD joins the Linux Foundation’s Cardea Project</a> 2021-06-08 Global ID
|
||
<blockquote>
|
||
<p>Cardea is a complete ecosystem for the exchange of privacy-preserving digital credentials, open sourced as a project in Linux Foundation Public Health. Launched by Indicio.Tech, Cardea provides an easily verifiable, trustworthy, unalterable proof of health tests or vaccination that can be shared in a privacy-preserving way. Cardea easily integrates with existing health systems to ensure trusted data sources for credentials and uses decentralized identity technology to enable better control of data for individuals. Cardea recently announced its first reference implementation in partnership with SITA for the island of Aruba.</p>
|
||
</blockquote>
|
||
</li>
|
||
<li><a href="https://docs.google.com/document/d/1Vl9IKRg6ygHD1njc8GfnjsQglDOVglBKbuXHSuqQ7T4/edit?usp=sharing">Indicio Submission to LFPH</a> 2021-03 Indicio
|
||
<blockquote>
|
||
<p>Indicio’s Cardea ecosystem easily integrates with existing applications, allowing people, businesses, healthcare systems, and governments to work together to safely reopen physical locations such as offices, restaurants, venues, schools, and travel, while complying with global health and data privacy laws. The ecosystem frees businesses, organizations, and governments from having to store and manage people’s private medical information. Instead, decentralized identity enables the individual to independently acquire and control their data and securely share or selectively disclose it at their discretion with full consent.</p>
|
||
</blockquote>
|
||
</li>
|
||
</ul></content><author><name>DIDecentral</name></author><category term="Community Orgs" /><category term="Linux Foundation" /><category term="LFPH" /><category term="Healthcare" /><category term="Covid 19" /><category term="Public Health Advisory Council" /><category term="Cardea" /><category term="TRAIN" /><category term="ESSIF" /><category term="GCCN" /><category term="Hyperledger Labs" /><summary type="html">There is no question that the community’s contributions during the height of the pandemic provided enormous benefit – possibly even life-saving. LFPH has represented a unique opportunity for the tech community to start collaborating around an urgent global health need, and we look forward to the opportunity to generate similar momentum in the future to address global challenges in health IT.</summary></entry></feed> |