mirror of
https://github.com/Decentralized-ID/decentralized-id.github.io.git
synced 2024-12-26 23:59:36 -05:00
141 lines
37 KiB
Plaintext
141 lines
37 KiB
Plaintext
---
|
||
published: false
|
||
---
|
||
W3C did-core Decentralized Identifiers (DIDs) V1.0 https://www.w3.org/TR/did-core/ core
|
||
W3C did-spec-registries DID Specification Registries https://w3c.github.io/did-spec-registries core
|
||
W3C security-vocab The Security Vocabulary https://w3c-ccg.github.io/security-vocab core
|
||
W3C Ed25519-signature-2018 Ed25519 Signature 2018 https://w3c-ccg.github.io/lds-ed25519-2018 core
|
||
W3C EcdsaSecp256k1-signature-2019 Ecdsa Secp256k1 Signature 2019 https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019 core
|
||
W3C RSA-signaturesuite-2018 RSA Signature Suite 2018 https://w3c-ccg.github.io/lds-rsa2018 core
|
||
W3C did-resolution Decentralized Identifier Resolution https://w3c-ccg.github.io/did-resolution core
|
||
W3C did-method-key The did:key Method https://w3c-ccg.github.io/did-method-key non-core
|
||
W3C DIF did-method-peer Peer DID Method Specification https://identity.foundation/peer-did-method-spec non-core
|
||
W3C Sovrin did-method-sovrin Sovrin DID Method Specification https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html non-core
|
||
W3C did-method-web did:web Method Specification https://w3c-ccg.github.io/did-method-web non-core
|
||
W3C JSON-LD A JSON-based Serialization for Linked Data https://www.w3.org/TR/json-ld11 non-core
|
||
W3C XSD-Part2-Datatypes XML XSD<53> Part 2: Datatypes https://www.w3.org/TR/xmlschema11-2/ non-core
|
||
W3C vc-data-model Verifiable Credentials Data Model https://www.w3.org/TR/vc-data-model core
|
||
W3C vc-use-cases Verifiable Credentials Use Cases https://www.w3.org/TR/vc-use-cases core
|
||
W3C vc-imp-guide Verifiable Credentials Implementation Guidelines 1.0 https://w3c.github.io/vc-imp-guide core
|
||
W3C vc-extension-registry Verifiable Credentials Extension Registry https://w3c-ccg.github.io/vc-extension-registry core
|
||
W3C vc-status-rl-2020 Revocation List 2020 https://w3c-ccg.github.io/vc-status-rl-2020/ core
|
||
W3C vc-json-schemas Verifiable CRedentials JSON Schema Spec https://w3c-ccg.github.io/vc-json-schemas core
|
||
W3C vp-request-spec Verifiable Presentation Request Specification https://w3c-ccg.github.io/vp-request-spec core
|
||
W3C CHAPI Credential Handler API https://w3c-ccg.github.io/credential-handler-api core
|
||
W3C credential-management Credential Management Level 1 https://www.w3.org/TR/credential-management-1 non-core
|
||
W3C secure-contexts Secure Contexts https://www.w3.org/TR/secure-contexts non-core
|
||
W3C service-workers-1 Service Workers 1 https://www.w3.org/TR/service-workers-1 non-core
|
||
W3C ldp-bbs2020 BBS+ Signatures 2020 https://w3c-ccg.github.io/ldp-bbs2020 core
|
||
W3C ld-proofs Linked Data Proofs https://w3c-ccg.github.io/ld-proofs core
|
||
W3C ld-cryptosuite-registry Linked Data Cryptographic Suite Registry https://w3c-ccg.github.io/ld-cryptosuite-registry core
|
||
https://kantarainitiative.org/confluence/collector/pages.action?key=WA&src=sidebar-pages https://kantarainitiative.org/confluence/collector/pages.action?key=WA&src=sidebar-pages
|
||
https://dpvcg.github.io/dpv/#Representative https://dpvcg.github.io/dpv/#Representative
|
||
Primer Data Privacy Vocabulary (DPV) https://w3c.github.io/dpv/primer/#core-taxonomy
|
||
DIF well-known-did Well Known DID Configuration https://identity.foundation/.well-known/resources/did-configuration core
|
||
DIF presentation-exchange Presentation Exchange https://identity.foundation/presentation-exchange core
|
||
DIF didcomm-messaging DidComm Messaging https://identity.foundation/didcomm-messaging/spec core
|
||
DIF did-comm-messaging-guide DIDComm Messaging Implementer's Guide https://identity.foundation/didcomm-messaging/guide core
|
||
DIF EcdsaSecp256k1-recoverysignature-2020 EcdsaSecp256k1RecoverySignature2020 https://identity.foundation/EcdsaSecp256k1RecoverySignature2020 core
|
||
IETF multibase Multibase Data Format https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03 non-core
|
||
IETF JWK JSON Web Key https://tools.ietf.org/html/rfc7517 non-core
|
||
IETF Timestamps Date and Time on the Internet: Timestamps https://tools.ietf.org/html/rfc3339 non-core
|
||
IETF JWT JSON Web Token https://tools.ietf.org/html/rfc7519 non-core
|
||
IETF JWS JSON Web Signtaures https://tools.ietf.org/html/rfc7515 non-core
|
||
IETF hashlinks Cryptograohic Hyperlinks https://tools.ietf.org/html/draft-sporny-hashlink-06 non-core
|
||
IETF Token Binding Token Binding Protocol https://tools.ietf.org/html/rfc8471 non-core
|
||
IETF ZLIB ZLIB Compressed Data Format Spec v3.3 https://tools.ietf.org/html/rfc1950 non-core
|
||
IETF Base 64 Base16, Base32, Base 64 Data Encodings https://tools.ietf.org/html/rfc4648 non-core
|
||
IETF JWM JSON Web Message https://tools.ietf.org/id/draft-looker-jwm-01.html non-core
|
||
IETF JWA JSON Web Algorithms https://tools.ietf.org/html/rfc7518 non-core
|
||
IETF JWS-unencoded-payload JSON Web Signature (JWS) Unencoded Payload Option https://tools.ietf.org/html/rfc7797 non-core
|
||
IETF jwk-thumbprint JSON Web Key (JWK) Thumbprint https://tools.ietf.org/html/rfc7638 non-core
|
||
Web Interface Definition Language This standard defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. This standard defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. Web IDL is an IDL variant with a number of features that allow the behavior of common script objects in the web platform to be specified more readily. How interfaces described with Web IDL correspond to constructs within ECMAScript execution environments is also detailed here.
|
||
Concretely, Web IDL provides a syntax for specifying the surface APIs of web platform objects, as well as ECMAScript bindings that detail how those APIs manifest as ECMAScript constructs. This ensures common tasks, such as installing global properties, processing numeric inputs, or exposing iteration behavior, remain uniform across web platform specifications: such specifications describe their interfaces using Web IDL, and then use prose to specify API-specific details. https://webidl.spec.whatwg.org/ non-core
|
||
DIF BBS+ Signature Scheme BBS is a digital signature scheme categorized as a form of short group signature that supports several unique properties. Notably, the scheme supports signing multiple messages whilst producing a single output digital signature. Through this capability, the possessor of a signature is able to generate proofs that selectively disclose subsets of the originally signed set of messages, whilst preserving the verifiable authenticity and integrity of the messages. Furthermore, these proofs are said to be zero-knowledge in nature as they do not reveal the underlying signature; instead, what they reveal is a proof of knowledge of the undisclosed signature. https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html core MATTR CFRG
|
||
CCG RDF Dataset Normalization RDF [RDF11-CONCEPTS] describes a graph-based data model for making claims about the world and provides the foundation for reasoning upon that graph of information. At times, it becomes necessary to compare the differences between sets of graphs, digitally sign them, or generate short identifiers for graphs via hashing algorithms. This document outlines an algorithm for normalizing RDF datasets such that these operations can be performed. https://www.w3.org/TR/rdf-canon/ non-core
|
||
ITU-T SG17 - Kantara initiative and ITU-T SG 17 https://www.itu.int/en/ITU-T/studygroups/2017-2020/17/Pages/default.aspx
|
||
TrustFramework DIACC https://diacc.ca/trust-framework/
|
||
NIST TrustFramework 800-63-3 https://pages.nist.gov/800-63-3/
|
||
NGI TrustRegistry TRAIN https://www.ngi.eu/funded_solution/essi_ioc_38/
|
||
# Assorted
|
||
OMG ISSUES RFI FOR DISPOSABLE SELF-SOVEREIGN IDENTITY STANDARD https://www.omg.org/news/releases/pr2021/01-21-21.htm This RFI aims to gain a better understanding of the self-sovereign identity space. In particular, the Blockchain PSIG is exploring the potential for standards setting in the area of contextually constrained or ‘disposable’ self-sovereign identity arrangements, building on top of existing W3C standards for self-sovereign identity [DID] and verifiable credentials [VC]. The aim of this RFI is to determine whether new standards for this specific aspect of self-sovereign identity are necessary, desirable and timely, and are not already being developed elsewhere. (The RFI) The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium, founded in 1989. OMG standards are driven by vendors, end-users, academic institutions and government agencies. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. OMG
|
||
DIF Agent Frameworks & Infrastructure (“Layer 2”) https://identity.foundation/faq/#agent-frameworks-infrastructure-layer-2 Agents
|
||
IDCommons Mobile Agent Development FAQ https://iiw.idcommons.net/1L/_Mobile_Agent_Development_FAQ - What’s the best place to start creating your own mobile agent?<br>- How do you get updates once you ship your first version?<br>- Do I actually have to support a fork for every mobile agent I create?<br>- Do I need to use a Mediator? Horacio Nunez Agents
|
||
Schema.org Schema.org is ten! http://blog.schema.org/2021/06/schemaorg-is-ten.html Schema.org was founded on the idea of making it easier and simpler for the ordinary, everyday sites that make up the web to use machine-readable data, and for that data to enable an ecosystem of applications used by millions of people. While it's hard to predict exactly what the next decade will bring, if we can all keep these founding concerns in mind as we improve, refine and curate our growing collection of schemas, we'll be doing our part to continue improving the web. Schema.org
|
||
Phil Windley JSON is Robot Barf https://www.windley.com/archives/2021/09/json_is_robot_barf.shtml Windley JSON has its place. But I think we're overusing it in places where a good notation would serve us better. JSON
|
||
Blockcerts Blockcerts V3 release https://community.blockcerts.org/t/blockcerts-v3-release/3022 The main change is the alignment with the [W3C Verifiable Credentials specification 3](https://www.w3.org/TR/vc-data-model/). Regarding the standard itself metadata and display are entering the default standard. metadata comes in replacement of metadataJson and remains a stringified JSON that will allow consumers to register specific data which are too unique for issuances to be defined in the context.<br> <br>display brings in [a little bit of novelty 2](https://github.com/blockchain-certificates/cert-schema/blob/master/cert_schema/3.0/displaySchema.json#L6) images or pdfs, in addition to the more classic HTML. Blockcerts
|
||
Julien Fraichot Blockcerts v3 release, a Verifiable Credentials implementation https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0051.html I am excited to share with you today the release of [Blockcerts](https://www.blockcerts.org/) V3. As you may already know the earlier versions of Blockcerts were architected by Kim H. Duffy through Learning Machine and leveraged the Open Badge standard.<br> <br>We have followed through with the initial [ideas established at RWOT 9 in Prague in December 2019, to align Blockcerts with the Verifiable Credential specification](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.md). Julien Fraichot Blockcerts
|
||
XSL Labs: Your Data Belongs to You https://www.xsl-labs.io/whitepaper/white_paper_en.pdf The SDI technology constitutes a very important example of decentralized counter-power to the web giants. The SDI maintains to keep the practicality of a unique identifier while guaranteeing the security of the data and the user's sovereignty over it XSL SDI
|
||
Better and more secure methods for API authentication https://iiw.idcommons.net/1D/_Better_and_more_secure_methods_for_API_authentication Michael Lodder https://docs.google.com/p>resentation/d/1UO25DzVmq25ya2S4_tV5UKTSP6NtBggln9vP1TEXSzE/edit Goal of the Oberon protocol when building an API:<br><br>* Super effective: no separate session token to required for accessing the API; very fast to issue and verify tokens; 128 bytes required per message<br>* Privacy preserving<br>* No new crypto, uses BLS signature keys and Pointecheval saunders Construction Oberon protocol
|
||
Trusted Timestamping Part 3: Family of Standards https://medium.com/finema/trusted-timestamping-part-3-family-of-standards-f0c89a5e97ab Nunnaphat Songmanee Finema Timestamping
|
||
Trusted Timestamping Part 1: Scenarios https://medium.com/finema/trusted-timestamping-part-1-scenarios-9bf4a7cc2364 Timestamping
|
||
Trusted Timestamping Part 2: Process and Safeguards https://medium.com/finema/trusted-timestamping-part-2-process-and-safeguards-f75286a0c370 Timestamping
|
||
Nat has a presentation https://nat.sakimura.org/2021/09/14/announcing-gain/
|
||
https://www.linkedin.com/groups/12559000/ GAIN
|
||
JSON Web Proofs BoF at IETF 114 in Philadelphia https://self-issued.info/?p=2286
|
||
Chair Slides https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-json-web-proofs-chair-drafts-00 Karen O’Donoghue, John Bradley JWP
|
||
The need: Standards for selective disclosure and zero-knowledge proofs https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-the-need-standards-for-selective-disclosure-and-zero-knowledge-proofs-00 Mike Jones JWP
|
||
What Would JOSE Do? Why re-form the JOSE working group to meet the need? https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-the-need-standards-for-selective-disclosure-and-zero-knowledge-proofs-00 Mike Jones JWP
|
||
A Look Under the Covers: The JSON Web Proofs specifications https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-json-web-proofs-initial-drafts-00 Jeremie Miller JWP
|
||
ONDC: An Open Network for Ecommerce https://www.windley.com/archives/2022/08/ondc_an_open_network_for_ecommerce.shtml Phil Windley ONDC
|
||
Open Network for Digital Commerce https://en.wikipedia.org/wiki/Open_Network_for_Digital_Commerce is a non-profit established by the Indian government to develop open ecommerce. The goal is to end platform monopolies in ecommerce using an open protocol called [Beckn](https://developers.becknprotocol.io/). I'd never heard of Beckn before. From the reaction on the VRM mailing list, not many there had either. ONDC
|
||
C2PA Specifications https://c2pa.org/specifications/specifications/1.0/index.html native support for VC’s for use in identification C2PA
|
||
# Authorization
|
||
FedId CG at W3C and GNAP https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0065.html I asked them whether they considered GNAP via slack.\n\n > https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900 They are chartered here: [https://fedidcg.github.io/](https://fedidcg.github.io/)\n\nTo look at AuthN that breaks when browser primitives are removed.\n\nThey are currently focused on OIDC, SAML, WS-Fed.\n\nThe reason I asked them was in relation to the questions we have discussed regarding "What can GNAP replace".\n\nClearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity... Orie Steele Authorization GNAP
|
||
Grant Negotiation and Authorization Protocol (GNAP) https://oauth.net/gnap/ Authorization GNAP
|
||
A GNAP Editors' Use of GitHub Issues https://aaronparecki.com/2020/11/25/4/gnap-github-issues The editors met yesterday to discuss the issues that were pulled out of the previous draft text and document a process for how to resolve these and future issues. We would like to explain how we plan on using labels on GitHub issues to keep track of discussions and keep things moving. Authorization GNAP
|
||
A Genesis of the GNAP working group with Dick Hardt of SignIn.org https://auth0.com/blog/identity-unlocked-explained-episode-6/ The decision was made to create a new group apart from OAuth, and Dick clarifies that the GNAP working group does not feel constrained by existing technology; GNAP does not need to be backward-compatible, but Dick still hopes that the transition to GNAP will be smooth for those who use it. Auth0 Podcast *Identity Unlocked* Vittorio Bertocci Authorization GNAP
|
||
Filling in the GNAP https://medium.com/@justinsecurity/filling-in-the-gnap-a032453eaf8c Justin Richer identity protocol writer and implementer extraordinaire has a very excellent post explaining the new GNAP and all the things that lead to it, including OAuth, OpenID, TxAuth, OAuth3, and OAuth.XYZ. This protocol is a big deal and will be important. It’s just beginning the journey through IETF (Internet Engineering Task Force) the main standards body of the internet. Authorization GNAP
|
||
Self-Sovereign Communities of Self-Sovereign Agents https://iiw.idcommons.net/10H/_Self-Sovereign_Communities_of_Self-Sovereign_Agents Minimal Demo: [https://adriang.xyz/](https://adriang.xyz/) Use Card Number 4242 4242 4242 4242 04/22 123 (don’t use a real email address because it will be stored in Stripe.) Adrian Gropper The first phase of the foundation demos GNAP control over a trivial health record consisting of just a biometric health card. * [Demo sequence diagram](https://github.com/HIEofOne/Trustee-Community/wiki) Authorization GNAP
|
||
OAuth2.0 and VCs https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0152.html I would like to share with you a paper we have written and it will be presented at [IEEE ICCCN 2021](http://www.icccn.org/). You can find the paper here [https://arxiv.org/abs/2104.11515](https://arxiv.org/abs/2104.11515) We tried to couple OAuth 2.0 flows with JWT/JWS and VCs in order to implement capabilities-based access control. Our goal was to show gains with minimal changes. Some things that might be of interest:\n > \n > - We used Proof-of-Possession Key Semantics for JSON Web Tokens (RFC 7800) instead of credentialSubject `id`\n > - We used OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP),([https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/)) for proving VC ownership\n > - We discuss how Revocation list 2020 has better privacy properties compared to RFC 7662 (which can be used for examining the status of an access token) Nikos Fotiou Authorization OAuth
|
||
101 Session: OAuth2 https://iiw.idcommons.net/2B/_101_Session:_OAuth2 Aaron Parecki Authorization OAuth
|
||
OAuth 2.0 Simplified https://aaronparecki.com/oauth-2-simplified/ In 2017, I published a longer version of this guide as a book, available on [oauth.com](https://oauth.com/) as well as [a print version](https://oauth2simplified.com). The book guides you through building an OAuth server, and covers many details that are not part of the spec. I published this book in conjunction with [Okta](https://developer.okta.com/). is a guide to OAuth 2.0 focused on writing clients that gives a clear overview of the spec at an introductory level. Authorization OAuth
|
||
https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi Authorization OAuth
|
||
How OAuth Works https://www.youtube.com/watch?v=g_aVPdwBTfw&list=PLRyLn6THA5wN05b3qJ6N0OpL3YbritKI- Authorization OAuth
|
||
12 videos Authorization OAuth
|
||
TMI BFF: OAuth Token Mediating and session Information Backend For Frontend https://iiw.idcommons.net/23B/_TMI_BFF:_OAuth_Token_Mediating_and_session_Information_Backend_For_Frontend OAuth, Javascript, Backend Infrastructure\n >\n >When there is an alternative, it is more secure to keep tokens out of the browser.\n >\n >Specifically talking about clients which are divided between a front end or javascript app, and backend supporting systems specifically for that/those apps\n >\n >Questions on whether this would also apply equivalently to native apps, which may have different capabilities and infrastructure requirements. It likely does work, but\n >\n >OAuth in the browser can be complicated and ASs don’t necessarily provide sufficient security features, support web interaction\n >\n >Bespoke workarounds acquiring tokens on the backend and passing to the frontend. Implementers may have security issues and not understand how to map best current practices\n >\n >TMI BFF\n >\n >1. Backend gets and stores tokens, javascript frontend gets a cookie\n >2. Request to backend for access (scopes, potentially resource)\n >3. Backend returns the token, requests new token with appropriate scope, etc.\n >\n >* [...]\n >\n >What is the scope - acquiring a token for direct API access, not necessarily prescriptive for BFF architectures which put all API interactions through BFF. (DW) raised issue that simply converting OAuth calls in a remote party to local API calls protected by a cookie disables some security protections provided by OAuth tokens (XSRF), so some sort of BFF best practices may be needed to prevent footguns. Vittorio Bertocci & Brian Campbell (but mostly Vittorio) Authorization OAuth
|
||
Public Review Period for Two Proposed SSE Implementer’s Drafts https://openid.net/2021/06/07/public-review-period-for-two-proposed-sse-implementers-drafts/ openid oauth Authorization OAuth
|
||
Matt Flynn: Information Security | Identity & Access Mgmt. http://360tek.blogspot.com/2021/06/bell-labs-colonial-pipeline-and-multi.html Authorization OAuth
|
||
Introducing: The OAuth 2 Game https://auth0.com/blog/introducing-the-oauth-2-game/ It features two dice, one for grants and another for application types. Throw the dice and consult the instructions to discover whether the combination of grant and application type you obtained happens to be a good one! Play a few times, and before you know it, you’ll be familiar with the most common combinations! Authorization OAuth
|
||
The Nuts and Bolts of OAuth 2.0 https://aaronparecki.com/2020/12/22/14/oauth > 3.5 hours of video content, quizzes, as well as interactive exercises with a guided learning tool to get you quickly up to speed on OAuth, OpenID Connect, PKCE, best practices, and tips for protecting APIs with OAuth. Aaron Parecki Authorization OAuth
|
||
VC HTTP Authorization Conversation https://lists.w3.org/Archives/Public/public-credentials/2021Jun/0009.html Authorization OAuth
|
||
Adrian Gropper The diversity of our community is a plus. To begin a conversation on VC access controls, I suggest this short intro to the differences between OAuth 2.0 and GNAP: OAuth
|
||
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-compared-to-oauth-20 https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-compared-to-oauth-20 My goal is to arrive at a shared understanding of what would be minimum needed to support both OAuth2 and GNAP for securing access to a VC. Authorization OAuth
|
||
Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html - You *could* implement zcap-ld on top of VCs…\n - However, you're actually squishing together what should be a separation of concerns in a way that will become *unhygienic*. Like a lack of proper biological hygiene, the result is sickness in our computing systems.\n - The observation of "these things seem so similar though!" is true, but you can already make that claim even if you're just looking at the linked data proofs layer. VCs and zcap-ld diverge from there for two very separate purposes: what is said, and what is done. Authorization
|
||
CCG Call about ZCaps and OCaps https://w3c-ccg.github.io/meetings/2021-01-13/audio.ogg This week’s CCG teleconference had a great discussion about object capabilities\n\n> Alan Karp: I've been doing capabilities since I reinvented them in 1996 and I want to make sure we get it right, because when newbies start to use them there are plenty of mistakes that can be made\n> \n> [...]\n> A capability or an OCAP is an unforgeable, transferable, permission to use the thing it designates ... it combines designation with authorization https://w3c-ccg.github.io/meetings/2021-01-13/ Authorization
|
||
Building capability-based data security for Ceramic https://blog.ceramic.network/capability-based-data-security-on-ceramic/ The 3Box Labs team recently published [a new standard for creating capability containers](https://github.com/ChainAgnostic/CAIPs/pull/74) for accessing decentralized data to the [Chain Agnostic Standards Alliance](https://github.com/ChainAgnostic/CASA). Capability containers are an approach for managing advanced data security and permissions, commonly referred to as “Object Capabilities” or “OCAPs.” Authorization
|
||
The impact of self-sovereign identity on the cybersecurity world https://blog.avast.com/impact-of-self-sovereign-identity-on-cybersecurity Authorization
|
||
The Challenging New World of Privacy & Security https://youtu.be/JmlvOKg_dS4?t=780) Atlanta Innovation Forum (Enterprise Authorization
|
||
featuring folks from MSFT, GSM, and Michael Becker. The video looks at the range of risks present in managing identity assets. Its focus is coming from the enterprise-level perspective.
|
||
a few thoughts about zcaps https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0036.html I was reading zcaps draft, as well as related work, mostly macaroons ([https://research.google/pubs/pub41892/](https://research.google/pubs/pub41892/).\n \n Something that I found confusing about capability documents is that they do not make clear the actions they concern. For example from this[https://w3c-ccg.github.io/zcap-ld/#example-1](https://w3c-ccg.github.io/zcap-ld/#example-1) it is not clear that this is a capability for "driving a car". Nikos Fotiou Authorization
|
||
https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0037.html We are still trying to figure out how to explain these things to people.Capabilities-based systems are not a new concept; they're decades old at this point. The challenge has always been in communicating why they're useful and have a place in modern security systems.\n\nThe Encrypted Data Vault work uses zcaps, and it's there that we're trying hard to explain to developers how to use it: Authorization
|
||
https://identity.foundation/confidential-storage/#introduction https://identity.foundation/confidential-storage/#introduction Authorization
|
||
The "Verifiable" Economy [was RE: a few thoughts about zcaps] https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0047.html After ruminating on ZCAPs, VCs, DIDs, and DID Documents over Easter dinner, it occurred to me that we're on the verge of creating a model for a "verifiable" economy... Michael Herman (Trusted Digital Web Authorization
|
||
Capability Authorization-enabled Decentralized Object Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about zcaps]] https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0062.html I see all of this converging into a Capability Authorization-enabled Decentralized Object Model. “More news at 11…” Michael Herman (Trusted Digital Web Authorization
|
||
The ezcap library https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0038.html Now might be a good time to announce some open source tooling a few of us have been working on related to zcaps that is being created to simplify the developer experience when developing with zcaps. - Manu Sporny Authorization
|
||
ezcap (pronounced "Easy Cap") https://github.com/digitalbazaar/ezcap An easy to use, opinionated Authorization Capabilities (zcap) client library for the browser and Node.js. Authorization
|
||
ucan-wg https://github.com/ucan-wg Authorization
|
||
Lightweight Credentials for Offers with UCAN https://blog.fission.codes/lightweight-credentials-ucan/ these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as [part of the Decentralized Identity Foundation](https://blog.fission.codes/fission-demo-day-may-2021/), too. Authorization
|
||
# Complementary
|
||
aries-rfcs/0646-bbs-credentials#drawbacks https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials#drawbacks
|
||
Zero-Knowledge Proofs Do Not Solve the Privacy-Trust Problem of Attribute-Based Credentials: What if Alice Is Evil? https://ieeexplore.ieee.org/document/9031545 IEEE
|
||
User Controlled Authorization Network https://github.com/ucan-wg/spec/ and how it contrasts with decentralized approaches\n - APAC/ASEAN Community Call now a colloaborative initative between DIF and ToIP, launched Thursday 26th May 2022, kicking off with an IIW34 recap. ([Recording](https://us02web.zoom.us/rec/share/5FW6hVoZc1kVJiFL4NNCRZg7625h-1UsC1xCY8Mb7cLXQpO2yDW566woLoA5IZA.MUVPrrNr_k3PXxDl)\n A couple weeks ago Amber Case came and spoke about “[Calm Technology](https://www.youtube.com/watch?v=Ngyfa4_NuPI)” at the TOIP Human Experience Working Group ([HXWG](https://wiki.trustoverip.org/display/HOME/Human+Experience+Working+Group) Authorization
|
||
What’s next for BBS+ LD-Proofs? https://iiw.idcommons.net/13B/_What%27s_next_for_BBS+_LD-Proofs%3F Brent Zundel Complimentary BBS
|
||
BBS+ Signatures 2020 https://w3c-ccg.github.io/ldp-bbs2020/ - What’s next for BBS+ LD-Proofs?\n > - Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest\n > - Implementation of BBS+ in Ursa, Core of higher level implementations\n > - Features\n > - Selective Disclosure\n > - Signature blinding\n > - Blinded messages (private holder binding)\n > - BBS+ LD Proofs uses this BBS+ scheme, MATTR provided spec\n > - Combine privacy features with semantic world\n > - Draft spec: [https://github.com/w3c-ccg/ldp-bbs2020/](https://github.com/w3c-ccg/ldp-bbs2020/)\n > - What needs to be refined?\n > - Private holder binding ([https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37)\n > - Do not bind to link secret, bind to keypair. Make keypair per credential\n > - How to participate?\n > - Read the draft BBS+ LD-Proofs spec\n > - Hardware security binding?\n > - Not possible with BLS yet?\n > - Is post-quantum secure?\n > - No. Pairing-based signatures are not post-quantum secure\n > \n > Next steps:\n > \n > - PRs for Issues 10 and 37 plus editorial pass to wrap up ldp-bbs2020\n > - Brent will do PR for 37 [https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37),\n > - Timo will do PR for 10 [https://github.com/w3c-ccg/ldp-bbs2020/issues/10](https://github.com/w3c-ccg/ldp-bbs2020/issues/10).\n > - Invite everyone to suggest editorial changes\n > - Create WG at DIF for Crypto - first work item BBS+\n > - Tobias will work with Rouven to get that started, [https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md](https://github.com/decentralized-identity/org/blob/master/working-group-lifecycle.md)\n > - Brent and Tobias will work together to draft a charter\n > \n > Future steps:\n > \n > - Possible working group, or addition to DIF C&C WG for work on ldp-bbs2021 Complimentary BBS
|
||
The Power of a Secret https://trbouma.medium.com/the-power-of-a-secret-c9fa6a404ea3 What had been discovered by Whitfield Diffie and Martin Hellman (and also Jame Ellis), is changing the world as we know it. It’s been only 43 years. Yes, that seems like an ice-age ago, but in the grand scheme of history, it is only a wink. Complimentary BBS
|
||
Beyond JWS: BBS as a new algorithm with advanced capabilities utilizing JWP https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-beyond-jws-bbs-00 Tobias Looker Complimentary BBS
|
||
SelfSovereignIdentity_memes https://twitter.com/SSI_by_memes/status/1578045600833994755 Currently, everyone waiting for [#AIP2](https://twitter.com/hashtag/AIP2), which enables [#BBS](https://twitter.com/hashtag/BBS)+ [#Signature](https://twitter.com/hashtag/Signature) in #SSI. Companies already implemented in their products, such as [@trinsic_id](https://twitter.com/trinsic_id) and [@mattrglobal](https://twitter.com/mattrglobal). But ZKP [#predicates](https://twitter.com/hashtag/predicates) are not supported by BBS+, so no ZKP age verification possible. Back to [#AnonCreds](https://twitter.com/hashtag/AnonCreds)? Complimentary BBS
|
||
Anonymous Credential Part 3: BBS+ Signature https://medium.com/finema/anonymous-credential-part-3-bbs-signature-26797721ca74 Compared to the CL signature, the BBS+ signature has much shorter keys and signatures for a comparable level of security. As a result, the BBS+ signature enables fast implementation for anonymous credentials. It can be used in combination with signature proof of knowledge to hide some of credential attributes/messages in a zero-knowledge fashion.\n\n > The BBS+ signature will also soon be available in [Finema](https://finema.co/)’s Identity Wallet! We are excited to see how this technology will make an impact to the society in the coming years. Complimentary BBS
|
||
aries-rfcs/0646-bbs-credentials#drawbacks https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials#drawbacks Complimentary BBS
|
||
What BBS+ Means For Verifiable Credentials https://www.youtube.com/watch?v=dXlRIrrb9f4 In a recent Evernym blog post, [we discussed why BBS+ LD-Proofs](https://www.evernym.com/blog/bbs-verifiable-credentials/) are the privacy-preserving VC format that everyone should implement. In this webinar….\n > - A brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge\n > - How BBS+ Signatures are the breakthrough that combine the best of the JSON-LD and ZKP formats, while still allowing for selective disclosure and non-trackability\n > - The path forward: What remains to be done to fully converge on the BBS+ format Evernym Complimentary BBS
|
||
BBS+ Credential Exchange in Hyperledger Aries https://iiw.idcommons.net/11E/_BBS+_Credential_Exchange_in_Hyperledger_Aries https://iiw.animo.id Complimentary BBS
|
||
Advanced DIDComm Messaging https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md in order for DIDComm to provide a potential replacement for commonly used chat protocols like WhatsApp (Extensible Messaging and Presence Protocol (XMPP)), Telegram (MTProto), or Signal (Signal Protocol), it needs to support modern chat features we use everyday By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1 Complimentary BBS
|
||
BBS+ Signatures 2020 https://w3c-ccg.github.io/ldp-bbs2020/ > - What’s next for BBS+ LD-Proofs?\n > - Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest Complimentary BBS
|
||
Regarding CBOR-LD Web Transports https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0100.html I pushed up this small demo showing how to transport JSON-LD as CBOR-LD over QR Code and Web NFC. Orie Steele (Saturday, 10 April) Complimentary CBOR
|
||
transmute-industries/cbor-ld-web-transports https://github.com/transmute-industries/cbor-ld-web-transports Complimentary CBOR
|
||
CBOR-LD stabilization (was: Re: Regarding CBOR-LD Web Transports) https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0127.html Digital Bazaar has a few updates to share with the community.\n > \n > 1. With a huge thank you to Dave Longley, a new version of the CBOR-LD library, with generalized and stable algorithms, and that works in the browser and node.js, has been released:\n > \n > [https://github.com/digitalbazaar/cborld](https://github.com/digitalbazaar/cborld)\n > \n > 2. We have split out the CBOR-LD command line interface into a separate project:\n > Manu Sporny (Wednesday, 21 April)\n > [https://github.com/digitalbazaar/cborld-cli/tree/initial](https://github.com/digitalbazaar/cborld-cli/tree/initial)\n > \n > 1. DB has released a CBOR-LD to QR Code image library for encoding and decoding Verifiable Presentations:\n > \n > [https://github.com/digitalbazaar/vpqr](https://github.com/digitalbazaar/vpqr)\n > \n > 1. After some consultation with Mattr and Transmute, we've settled on a base32 alphanumeric QR Code encoding that is 10% more space efficient than base64url byte mode. This is important because this format is compatible with hundreds of QR Code readers on the market. Every QR Code reader that we've tested has worked with this new format. Complimentary CBOR
|
||
Mike Jones shares that CBOR is officially a specification at IETF https://self-issued.info/?p=2136 The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it). https://www.rfc-editor.org/rfc/rfc8943 Complimentary CBOR
|
||
DHS SVIP PlugFest 2021 – Paper & Digital Vaccination Credentials https://youtu.be/fEBNGj377Vc Complimentary CBOR
|
||
Second demo video using a different potential flow: [https://www.youtube.com/watch?v=fEBNGj377Vc](https://www.youtube.com/watch?v=fEBNGj377Vc)\n\nPaper VC’s are hard to bring to parity with “digital VC’s”. The biggest issue is binding subject to holder and verifying that. There were also callouts on how do you prevent replication.\n \n Traditionally, QR codes with the entire VC can be put onto a piece of paper. We proposed compression on those QR codes using CBOR-LD that reduces size of codes by 50%.\n \n Alternative ways include adding VC’s into NFC chips and adding the NFC identifier as a claim to the VC preventing duplication. There is a cost overhead to this compared to paper but is a cost potentially worth occurring. Complimentary CBOR
|
||
Concise Binary Object Representation https://cbor.io/ Complimentary CBOR
|