sort

2024-10-01 05:05:54 +00:00 · 2023-05-23 19:44:47 +05:30 · 2023-05-23 19:44:47 +05:30 · 88d37dbca3
commit 88d37dbca3
parent 065f8e5bcf
14 changed files with 0 additions and 1171 deletions
--- a/identosphere-dump/open-standards/authorization/README.md
+++ b/identosphere-dump/open-standards/authorization/README.md
@ -1,81 +0,0 @@
 # Authorization Protocols
 * [VC HTTP Authorization Conversation](https://lists.w3.org/Archives/Public/public-credentials/2021Jun/0009.html) Adrian Gropper June 2
 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:
 * [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.
 ## oCap
 - [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…
    - 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.
    - 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.
 * [CCG Call about ZCaps and OCaps](https://w3c-ccg.github.io/meetings/2021-01-13/audio.ogg) ([minutes](https://w3c-ccg.github.io/meetings/2021-01-13/))
 This week’s CCG teleconference had a great discussion about object capabilities
 > 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
 > 
 > [...]
 > A capability or an OCAP is an unforgeable, transferable, permission to use the thing it designates ... it combines designation with 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.”
 - [The impact of self-sovereign identity on the cybersecurity world](https://blog.avast.com/impact-of-self-sovereign-identity-on-cybersecurity)
 * [The Challenging New World of Privacy & Security](https://youtu.be/JmlvOKg_dS4?t=780) Atlanta Innovation Forum (Enterprise)
 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) Nikos Fotiou
 I was reading zcaps draft, as well as related work, mostly macaroons ([https://research.google/pubs/pub41892/](https://research.google/pubs/pub41892/).
 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](https://w3c-ccg.github.io/zcap-ld/#example-1) it is not clear that this is a capability for "driving a car".
 * [Manu Responds:](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.
 The Encrypted Data Vault work uses zcaps, and it's there that we're trying
 hard to explain to developers how to use it:
 * [https://identity.foundation/confidential-storage/#introduction](https://identity.foundation/confidential-storage/#introduction)
 * [The "Verifiable" Economy [was RE: a few thoughts about zcaps]](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0047.html) Michael Herman (Trusted Digital Web) (Monday, 5 April)
 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...
 ![https://www.notion.soimages/image3.png](https://www.notion.soimages/image3.png)
 * [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) Michael Herman (Trusted Digital Web) (Wednesday, 7 April)
 I see all of this converging into a Capability Authorization-enabled Decentralized Object Model.  “More news at 11…”
 ![https://www.notion.soimages/image1.png](https://www.notion.soimages/image1.png)
 Updates on Kepler including implementing support for [CACAO-ZCAPs](https://github.com/spruceid/cacao-zcap), improved the `put` function to make it easier to store objects of different types, and added support for listing objects by prefix: [kepler-sdk#40](https://github.com/spruceid/kepler-sdk/pull/40) [kepler#115](https://github.com/spruceid/kepler/pull/115).
 * [The ezcap library](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0038.html) - Manu Sporny
  > 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.
 * [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.
 ## UCAN
 [ucan-wg](https://github.com/ucan-wg)
 * [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.
 - [User Controlled Authorization Network](https://github.com/ucan-wg/spec/) model and how it contrasts with decentralized approaches
 - 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)
 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)
--- a/identosphere-dump/open-standards/authorization/gnap.md
+++ b/identosphere-dump/open-standards/authorization/gnap.md
@ -1,31 +0,0 @@
 # GNAP
 * [FedId CG at W3C and GNAP](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0065.html)  Orie Steele (Friday, 7 January)
 I asked them whether they considered GNAP via slack.
 * [https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900](https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900)
 They are chartered here: [](https://fedidcg.github.io/)[https://fedidcg.github.io/](https://fedidcg.github.io/)
 To look at AuthN that breaks when browser primitives are removed.
 They are currently focused on OIDC, SAML, WS-Fed.
 The reason I asked them was in relation to the questions we have discussed regarding "What can GNAP replace".
 Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity...
 ### Grant Negotiation and Authorization Protocol (GNAP)
 * [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. 
 * [Genesis of the GNAP working group with Dick Hardt of SignIn.org](https://auth0.com/blog/identity-unlocked-explained-episode-6/). Auth0 Podcast *Identity Unlocked* Vittorio Bertocci
  > 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. 
 * [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.
 * [Self-Sovereign Communities of Self-Sovereign Agents](https://iiw.idcommons.net/10H/_Self-Sovereign_Communities_of_Self-Sovereign_Agents) by Adrian Gropper
  > 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.)
  * [Demo sequence diagram](https://github.com/HIEofOne/Trustee-Community/wiki)
  > The first phase of the foundation demos GNAP control over a trivial health record consisting of just a biometric health card.
--- a/identosphere-dump/open-standards/authorization/oauth.md
+++ b/identosphere-dump/open-standards/authorization/oauth.md
@ -1,53 +0,0 @@
 * [OAuth2.0 and VCs](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0152.html) Nikos Fotiou
  > 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:
  > 
  > - We used Proof-of-Possession Key Semantics for JSON Web Tokens (RFC 7800) instead of credentialSubject `id`
  > - 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
  > - 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)
 * [101 Session: OAuth2](https://iiw.idcommons.net/2B/_101_Session:_OAuth2) by Aaron Parecki
 * [OAuth 2.0 Simplified](https://aaronparecki.com/oauth-2-simplified/) is a guide to OAuth 2.0 focused on writing clients that gives a clear overview of the spec at an introductory level.
  > 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/).
 * [https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi](https://speakerdeck.com/aaronpk/oauth-101-internet-identity-workshop-xxxi)
 * [How OAuth Works](https://www.youtube.com/watch?v=g_aVPdwBTfw&list=PLRyLn6THA5wN05b3qJ6N0OpL3YbritKI-) 12 videos
 * [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) by Vittorio Bertocci & Brian Campbell (but mostly Vittorio)
 OAuth, Javascript, Backend Infrastructure
 When there is an alternative, it is more secure to keep tokens out of the browser.
 Specifically talking about clients which are divided between a front end or javascript app, and backend supporting systems specifically for that/those apps
 Questions on whether this would also apply equivalently to native apps, which may have different capabilities and infrastructure requirements. It likely does work, but
 OAuth in the browser can be complicated and ASs don’t necessarily provide sufficient security features, support web interaction
 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
 TMI BFF
 1. Backend gets and stores tokens, javascript frontend gets a cookie
 2. Request to backend for access (scopes, potentially resource)
 3. Backend returns the token, requests new token with appropriate scope, etc.
 * [...]
 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.
 * OpenID: [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/)
 * [Matt Flynn: Information Security | Identity & Access Mgmt.](http://360tek.blogspot.com/2021/06/bell-labs-colonial-pipeline-and-multi.html)
 * [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!
 * [The Nuts and Bolts of OAuth 2.0](https://aaronparecki.com/2020/12/22/14/oauth)
 Aaron Parecki - Mr. OAuth has a new course out on Udemy
 > 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.
--- a/identosphere-dump/open-standards/complementary/README.md
+++ b/identosphere-dump/open-standards/complementary/README.md
@ -1,9 +0,0 @@
 # Complementary to VC / DID standards
 ## Contents
 - JSON-LD ✓
 - JSON
 - KERI ✓
 - Cryptography
  - BBS ✓
--- a/identosphere-dump/open-standards/complementary/bbs.md
+++ b/identosphere-dump/open-standards/complementary/bbs.md
@ -1,67 +0,0 @@
 # BBS
 * [What’s next for BBS+ LD-Proofs?](https://iiw.idcommons.net/13B/_What%27s_next_for_BBS+_LD-Proofs%3F) by Brent Zundel
 * [BBS+ Signatures 2020](https://w3c-ccg.github.io/ldp-bbs2020/)
 - What’s next for BBS+ LD-Proofs?
 - Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest
 - Implementation of BBS+ in Ursa, Core of higher level implementations
 - Features
 - Selective Disclosure
 - Signature blinding
 - Blinded messages (private holder binding)
 - BBS+ LD Proofs uses this BBS+ scheme, MATTR provided spec
 - Combine privacy features with semantic world
 - Draft spec: [https://github.com/w3c-ccg/ldp-bbs2020/](https://github.com/w3c-ccg/ldp-bbs2020/)
 - What needs to be refined?
 - Private holder binding ([https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37)
 - Do not bind to link secret, bind to keypair. Make keypair per credential
 - How to participate?
 - Read the draft BBS+ LD-Proofs spec
 - Hardware security binding?
 - Not possible with BLS yet?
 - Is post-quantum secure?
 - No. Pairing-based signatures are not post-quantum secure
 Next steps:
 - PRs for Issues 10 and 37 plus editorial pass to wrap up ldp-bbs2020
 - Brent will do PR for 37 [https://github.com/w3c-ccg/ldp-bbs2020/issues/37](https://github.com/w3c-ccg/ldp-bbs2020/issues/37),
 - Timo will do PR for 10 [https://github.com/w3c-ccg/ldp-bbs2020/issues/10](https://github.com/w3c-ccg/ldp-bbs2020/issues/10).
 - Invite everyone to suggest editorial changes
 - Create WG at DIF for Crypto - first work item BBS+
 - 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)
 - Brent and Tobias will work together to draft a charter
 Future steps:
 - Possible working group, or addition to DIF C&C WG for work on ldp-bbs2021
 * [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.
 - [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](https://twitter.com/tplooker)
 * [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)?
 - [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.
 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.
 - [aries-rfcs/0646-bbs-credentials#drawbacks](https://github.com/hyperledger/aries-rfcs/tree/main/features/0646-bbs-credentials#drawbacks)
 * [What BBS+ Means For Verifiable Credentials](https://www.youtube.com/watch?v=dXlRIrrb9f4) Evernym
  > 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….
  > - A brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge
  > - 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
  > - The path forward: What remains to be done to fully converge on the BBS+ format
 * [BBS+ Credential Exchange in Hyperledger Aries](https://iiw.idcommons.net/11E/_BBS+_Credential_Exchange_in_Hyperledger_Aries) [[presentation](https://iiw.animo.id)]
 * [Advanced DIDComm Messaging](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md) By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1
  > 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
 * [BBS+ Signatures 2020](https://w3c-ccg.github.io/ldp-bbs2020/)
 - What’s next for BBS+ LD-Proofs?
 - Implementation in Aries ([https://iiw.animo.id/](https://iiw.animo.id/), Used in SVIP Plugfest
--- a/identosphere-dump/open-standards/complementary/cbor.md
+++ b/identosphere-dump/open-standards/complementary/cbor.md
@ -1,31 +0,0 @@
 # Concise Binary Object Representation (IETF)
 * [Regarding CBOR-LD Web Transports](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0100.html)  Orie Steele (Saturday, 10 April)
  > I pushed up this small demo showing how to transport JSON-LD as CBOR-LD over QR Code and Web NFC.
 * [transmute-industries/cbor-ld-web-transports](https://github.com/transmute-industries/cbor-ld-web-transports) github
 * [CBOR-LD stabilization (was: Re: Regarding CBOR-LD Web Transports)](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0127.html)  Manu Sporny (Wednesday, 21 April)
  > Digital Bazaar has a few updates to share with the community.
  > 
  > 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:
  > 
  > [https://github.com/digitalbazaar/cborld](https://github.com/digitalbazaar/cborld)
  > 
  > 2. We have split out the CBOR-LD command line interface into a separate project:
  > 
  > [https://github.com/digitalbazaar/cborld-cli/tree/initial](https://github.com/digitalbazaar/cborld-cli/tree/initial)
  > 
  > 1. DB has released a CBOR-LD to QR Code image library for encoding and decoding Verifiable Presentations:
  > 
  > [https://github.com/digitalbazaar/vpqr](https://github.com/digitalbazaar/vpqr)
  > 
  > 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.
 * [Mike Jones shares](https://self-issued.info/?p=2136) that CBOR (Concise Binary Object Representation)  is officially a [specification at IETF](https://www.rfc-editor.org/rfc/rfc8943) - woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it).
  > 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.
 * [https://youtu.be/fEBNGj377Vc](https://youtu.be/fEBNGj377Vc)
 Second demo video using a different potential flow: [https://www.youtube.com/watch?v=fEBNGj377Vc](https://www.youtube.com/watch?v=fEBNGj377Vc)
 Paper 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.
 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%.
 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.
--- a/identosphere-dump/open-standards/complementary/json-ld.md
+++ b/identosphere-dump/open-standards/complementary/json-ld.md
@ -1,8 +0,0 @@
 # JSON-LD
 * [JSON-LD Playground](https://json-ld.org/playground/)
  > Play around with JSON-LD markup by typing out some JSON below and seeing what gets generated from it at the bottom of the page. Pick any of the examples below to get started.
  > 
  > NOTE: The playground uses [jsonld.js](https://github.com/digitalbazaar/jsonld.js) which [conforms](https://github.com/digitalbazaar/jsonld.js#conformance) to JSON-LD 1.1 [syntax](https://www.w3.org/TR/json-ld11/) ([errata](https://w3c.github.io/json-ld-syntax/errata/)), [API](https://www.w3.org/TR/json-ld11-api/) ([errata](https://w3c.github.io/json-ld-api/errata/)), and [framing](https://www.w3.org/TR/json-ld11-framing/) ([errata](https://w3c.github.io/json-ld-framing/errata/)). Also see the classic [JSON-LD 1.0 playground](https://json-ld.org/playground/1.0/) and the [RDF Distiller](http://rdf.greggkellogg.net/distiller).
 * [Mental Models of JSON-LD and what a "Document Loader" really does](https://www.youtube.com/watch?v=-yUbMDft5O0)  Orie Steel
  > and terms like "dereferencing" that trip up even highly experienced senior developers that show up late to the Linked-Data party and its open-world model (complete with its own security model based on different availability assumptions).
--- a/identosphere-dump/open-standards/data-exchange.md
+++ b/identosphere-dump/open-standards/data-exchange.md
@ -1,11 +0,0 @@
 ---
 published: false
 ---
 # Hubs
 * [Dynamic Data Sharing Hub: A target component for criteria searches on distributed structured data](https://iiw.idcommons.net/10L/_Dynamic_Data_Economy:_Digital_Identity,_Authentic_Data_Flows,_Data_Mesh_and_other_dragons) by Paul Knowles
 * [Dynamic Data Sharing Hub - DDSH - Patient Recruitment Use Case](https://drive.google.com/file/d/1TSfpysHy-UN9GnAiNPB81ZgGQaFCFcjo/view?usp=sharing)
 * [Identity Hub data storage and relay: unlocking the 99.99% of decentralized identity use cases](https://iiw.idcommons.net/index.php?title=14A/_Identity_Hub_data_storage_and_relay:_unlocking_the_99.99%25_of_decentralized_identity_use_cases&action=edit&redlink=1) by Daniel Buchner
--- a/identosphere-dump/open-standards/exchange-protocol/didcomm.md
+++ b/identosphere-dump/open-standards/exchange-protocol/didcomm.md
@ -1,117 +0,0 @@
 ---
 published: false
 ---
 * [announcement: DIDComm user group](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0168.html)  Hardman, Daniel (Thursday, 20 January)
 Now that the [DIDComm v2 spec](https://identity.foundation/didcomm-messaging/spec/) is nearing completion, and there are [robust libraries in multiple programming languages](https://github.com/decentralized-identity/didcomm-messaging#implementations), we are starting a user group to share learnings as we put DIDComm into production. We will organize community resources, produce a handbook, foster application-level protocol creation, maintain the [didcomm.org website](https://didcomm.org) and [repo](https://github.com/decentralized-identity/didcomm.org), and recommend best practices.
 * [slides for DIDComm discussion on Tuesday's CCG call](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0032.html)  Daniel Hardman (Tuesday, 5 April)
 application/pdf attachment: [DIDComm_v2_Primer.pdf](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/att-0032/DIDComm_v2_Primer.pdf)
 # DIDComm
 * [DIDComm has its own site](https://didcomm.org/)
  > DIDComm lets people and software use [DIDs](https://www.w3.org/TR/did-core/) to communicate securely and privately over many channels: the web, email, mobile push notifications, QR codes, Bluetooth, message queues, sneakernet, and more.
 - [DIDComm](https://identity.foundation/working-groups/did-comm.html) Identity Foundation
 - [#wg-didcomm on DIF Slack](https://difdn.slack.com)
 - [decentralized-identity/didcomm-messaging](https://github.com/decentralized-identity/didcomm-messaging) GitHub
 - WG Calls Mondays at noon US/Pacific ([Agenda](https://github.com/decentralized-identity/didcomm)
 ## Specifications
 - [DIDComm Messaging v2.x Editor’s Draft](https://identity.foundation/didcomm-messaging/docs/spec/) Identity Foundation
 - [DIDComm v2 spec](https://identity.foundation/didcomm-messaging/spec)
 ## Explainer
 * [Why the Internet Needs DIDComm](https://iiw.idcommons.net/2D/_Why_the_Internet_Needs_DIDComm) by Sam Curren [presentation](https://docs.google.com/presentation/d/16HTPyZV_-BtM6EifQpxjivRHKYUeVtOAReUD1eGUA9M/edit?usp=sharing)
  > - Enables Verifiable Communication
  > - Intelligence at the edge (like email)
  > - Protocol Based (like email)
  > - Supports HTTP(s) (like APIs) and others as a transport
  > - Bluetooth enables Edge to Edge transport
  > - Mobile / Offline Friendly (like email)
  > - Supports rotating from one DID to another
  > - Security independent of transport
  > - Protocol development becomes easier and more robust (unlike email)
 * [Decentralized Semantics 101](https://iiw.idcommons.net/2E/_Decentralized_Semantics_101) by Paul Knowles [Presentation](https://drive.google.com/file/d/1Og1LVND8RrHbZ8mBobBehRzN46YI4SXt/view?usp=sharing)
  > A digital network must contain authenticable data entry and immutable data
  > 
  > capture elements in order to maintain balance and integrity.
  > 
  > Within the context of a decentralized network, these fundamentals enable a self-regulating system where ...
  > 
  > (1) data inputs can be trusted as having come from an assured source under the control of a governing entity; and
  > 
  > (2) semantic items ensure that the meaning and use of inputted data remains unaltered for all interacting actors.
 * [DIDComm and the Self-Sovereign Internet](https://iiw.idcommons.net/21A/_DIDComm_and_the_Self-Sovereign_Internet) by Phil Windley [presentation](https://docs.google.com/presentation/d/1h0qi2qyGwM30DHpRAXW_Y0bBneo9xMEFZh1rIAeRa-E/edit?usp=sharing)
  > DID-based relationships are the foundation of self-sovereign identity (SSI). The exchange of DIDs to form a connection with another party gives both parties a relationship that is self-certifying and mutually authenticated. Further, the connection forms a secure messaging channel called DID Communication or DIDComm. DIDComm messaging is more important than most understand, providing a secure, interoperable, and flexible general messaging overlay for the entire internet.
 * [DIDComm and the Self-Sovereign Internet - Phillip J. Windley, Ph.D., Brigham Young University](https://www.windley.com/archives/2020/11/didcomm_and_the_self-sovereign_internet.shtml)
  > DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification.
 * [Why we need DIDComm](https://identitywoman.net/why-we-need-didcomm/) IdentityWoman
  > This is the text of an email I got today from a company that I had a contract with last year [...] I was reminded quite strongly why we need DIDComm as a protocol to enable the secure transport of all sorts of things not just signed VCs but intermediate uses
 ## Development
 * [DIDComm v2: Implementation and integration](https://iiw.idcommons.net/11D/_DIDComm_V2:_Implementation_and_integration_%27technical%27_-_did:key_and_did:keri_resolvers,_seamless_and_partial_integrations-)
 * [didcomm-rs implementation](https://drive.google.com/file/d/1dn5f2SqnCeQocOy5quJD9gpMPipKRmdC/view?usp=sharing) presentation
 - [decentralized-identity/didcomm-rs](https://github.com/decentralized-identity/didcomm-rs) github
 * [Trusted P2P Messaging with DIDs, DIDComm and VCs](https://medium.com/uport/trusted-p2p-messaging-with-dids-didcomm-and-vcs-398f4c3f3cda) uPort
  > about their path towards trusted P2P messaging and announces the [DIDAgent Framework (DAF)](https://github.com/uport-project/daf)
  > 
  > when we speak about a DID, then we need to be more precise and also speak about the particular DID method of that DID which defines the CRUD operations on a target system such as Ethereum.
 * [DIDComm Mythconceptions](https://www.youtube.com/watch?v=rwvQdRyMeY4) Daniel Hardman
  > DIDComm is a peer-to-peer communication technology for SSI (self-sovereign identity) with security and privacy properties rooted in DIDs (decentralized identifiers). Its core value proposition is often misunderstood or oversimplified. This webinar provides a proper mental model.
 * [FLOSS WEEKLY 685: DIDS AND DIDCOMM](https://twit.tv/shows/floss-weekly/episodes/685) Featuring Sam Curren
  > Sam Curren unpacks for Doc Searls and Dan Lynch why DIDs and DIDcomm are the best approach to identity—and to making people first-class citizens on the Internet. Curren also discusses the origin story of picos and the advantages of nomadic living and hacking.
 * [Steering Committee approved the DIDComm Messaging Spec (DIDComm v2)](https://twitter.com/IndicioID/status/1545208982863691777) @IndicioID
 * [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/)
  > DIDComm Messaging enables higher-order protocols that inherit its security, privacy, decentralization, and transport independence. Examples include exchanging verifiable credentials, creating and maintaining relationships, buying and selling, scheduling events, negotiating contracts, voting, presenting tickets for travel, applying to employers or schools or banks, arranging healthcare, and playing games.
 * [DIDComm v2 reaches approved spec status!](https://blog.identity.foundation/didcomm-v2/) DIF Blog
  > DIDComm defines how messages are composed into application-level protocols and workflows.
 * [Advanced DIDComm Messaging](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/advanced-didcomm-messaging.md) By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1
  > 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
 * [DIDComm & DIDComm Messaging](https://medium.com/datev-techblog/didcomm-didcomm-messaging-3e10fbf12bb8) Tim Vorgs, DATEV eG
 * [Blockchain and Self-Sovereign Identity Empowered Cyber Threat Information Sharing Platform](https://www.youtube.com/watch?v=lzS49R52PwA) Siddhi
  > looks interesting and different - uses DIDComm
  > 
  > Presented in 7th IEEE International Conference on Smart Computing(IEEE SmartComp 2021)
 * [Timo Glastra @TimoGlastra](https://twitter.com/TimoGlastra/status/1572976791136137216) via Twitter
  > Just got my first DIDComm protocol published on the [https://didcomm.org](https://t.co/GvWIyysx1k) website.
 * DIDComm: [ECDH-1PU Implementation](https://blog.identity.foundation/ecdh-1pu-implementation/) Identity Foundation
 In short, ECDH-1PU is a key derivation process that allows for sender authenticity and enables a “[Perfect Forward Secrecy](https://www.wired.com/2016/11/what-is-perfect-forward-secrecy/#:~:text=Perfect%20forward%20secrecy%20means%20that,of%20the%20user%27s%20sensitive%20data.)” mechanism, in addition to significant performance gains over JWS message nested in a JWE envelope, as used by existign ECDH-ES aproaches.
 - We at Jolocom strongly believe that DIDComm is a crucial infrastructure element for the broader and future-proof SSI stack, and [current work on DIDComm v2 includes Jolocom’s implementation of the specification](http://github.com/jolocom/didcomm-rs) with authcrypt (authenticated encrypted) and most of the low level of the protocol.
 * [trustbloc/hub-router](https://github.com/trustbloc/hub-router) DIDComm mediator and router with mailbox features.
  > The TrustBloc hub-router is a working implementation of the Mediator Coordination and the Pickup protocols built using Hyperledger Aries Framework - Go.
 * [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) uPort
  > Peers would still use their peer ID for [libp2p](https://libp2p.io/) routing and authentication. Alice and Bob would exchange their [DID](https://www.w3.org/TR/did-core/) out of band and will be able to find their counterparty’s peer ID via their [DIDs](https://www.w3.org/TR/did-core/).
 * [DIDComm Messaging through libp2p](https://medium.com/uport/didcomm-messaging-through-libp2p-cffe0f06a062) Oliver Terbu
  > We outlined the next generation decentralized messaging solution built on top of [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec/), [DIDs](https://www.w3.org/TR/did-core/) and [VCs](https://www.w3.org/TR/vc-data-model/) and a [libp2p](https://libp2p.io/) overlay network. We presented how Alice and Bob establish a connection, exchange messages and demonstrated what connection types are supported.
 * [DIF F2FJan21 - DIDComm Demo Session with Ivan Temchenko, Tobias Looker, and Oliver Terbu](https://www.youtube.com/watch?v=SaNvIorKQ9I&feature=youtu.be)
 During the live demo he showed the message lifecycle in various setups using the new, [open source didcomm-rs library](http://github.com/jolocom/didcomm-rs) on GitHub
 * [Aries RFC 0453 - credential issuance protocol using DIDComm V1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2)
 * [Aries RFC 0454 - Present Proof protocol V2 using DIDCommV1 data formats](https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2)
 ### DIDComm v2
 Work Item within DIF right now - envelope format with some other opinions we may or may want. Daniel Hardman gave vision - of parts that are done - leaving behind parts not done.
 - DIDCom V2 Envelops JWEs (a standard that exists)
 - Aries RFCs for payloads that go in JWE envelopes.
 - Send envelopes over HTTP as a starting point
 Michale Herman [is excited](https://twitter.com/mwherman2000/status/1511550968617263114) about the new  #VCA (Verifiable Credential Authorization) using the new #VCTPS (Secure Verifiable Credential Transport Protocol) over #DIDCOMM
--- a/identosphere-dump/open-standards/exchange-protocol/exchange-protocols.md
+++ b/identosphere-dump/open-standards/exchange-protocol/exchange-protocols.md
@ -1,191 +0,0 @@
 ---
 published: false
 ---
 # Credential Exchange
 * [IETF: Secure Credential Transfer](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0025.html)  Orie Steele (Monday, 4 April)
 * [https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html](https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html)
 This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information.
 * [Figuring out Verifiable Credentials Exchange - combining Bloom, Aires Protocols, Presentation Exchange into a unified - Killer Whale Jello Salad](https://iiw.idcommons.net/22H/_Figuring_out_Verifiable_Credentials_Exchange_-_combining_Bloom,_Aires_Protocols,_Presentation_Exchange_into_a_unified_-_Killer_Whale_Jello_Salad) by Kaliya Young, Orie Steele, Drummond , Kyle et al [ [presentation](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit#slide=id.p)]
  > - Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
  > - Goal to create a bridge between
  > - the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
  > - Aries protocols run on top of DIDComm
  > - If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
  > - Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
  > - So can be tested with next SVIP - testing.
  > - Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
  > - Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
  > - Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF
  > Result: [https://identity.foundation/arewewaciyet/](https://identity.foundation/arewewaciyet/)
 * [BBS+ Credential Exchange in Hyperledger Aries](https://iiw.idcommons.net/11E/_BBS+_Credential_Exchange_in_Hyperledger_Aries) [[presentation](https://iiw.animo.id)]
 * [Credentials Exchange - figuring it out - (Jello Bowl Death Match?)](https://iiw.idcommons.net/12F/_Credentials_Exchange_-_figuring_it_out_-_(Jello_Bowl_Death_Match%3F)_%E2%80%93) [[Slides](https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit#slide=id.p)]
  DIDComm, Verifiable Credential Exchange, Aries Protocol, Bloom Protocol, Presentation Exchange 
 The ultimate goal is to get to a clear exchange protocols.
 Also to have a paper similar to this one that outlines the choice landscape that is and points to a convergence point - [https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf](https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf)
 Good Health Pass is literally right now trying to figure this out and will “pick” solutions it needs to get implementations working in the next 30-90 days and point the whole industry in one direction.
 We started out with this framework of understanding
 Contextualizing VC Exchange in Layers
 Verifiable Credentials (VC or VCs) is one of the key standardized components of decentralized identity. [The VCs Data Model](https://www.w3.org/TR/vc-data-model/), defined at the W3C, is a universal data format that lets any entity express anything about another entity.  It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy-respecting, and machine-verifiable.
 There clarity emerging on standards that are interoperable with one another for the VC format.
 There is less clarity on the Exchange mechanisms.
 One way that has been proposed to look at the exchange options available is to see them in different layers.
 ### CHAPI
 * [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html) Manu Sporny CCG
 TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
 The Credential Handler API or CHAPI is currently a draft community group report developed by/under the Credentials Community Group at the W3C. At the heart of this model is a credential repository which is a Web application that can handle credential requests and credential storage on behalf of the user/holder.  The API Is designed to support the transmission of credentials between a web based issuer and a holder with a cloud wallet (credential repository) that is visible in the same browser but in a different tab.  It creates a “dumb pipe” between the two tabs in the holder’s browser and permits the transmition of the credential effectively from one tab to another.
 * [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html) Manu Sporny CCG
 TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
 * [TrustBloc - Duty Free Shop use case (CHAPI Save + WACI Share)](https://www.youtube.com/watch?v=aagFJBI1fBE)
 This video demonstrates the TrustBloc platform to Issue a W3C Verifiable Credential through CHAPI and Share the Verifiable Credential/Presentation through WACI.
 CHAPI
 * [VC-API Diagram for today. Focus on CHAPI](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0007.html)  Joe Andrieu (Tuesday, 2 November)
 ![https://www.notion.soimages/image7.png](https://www.notion.soimages/image7.png)
 * [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html)  Manu Sporny (Monday, 27 June)
 TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
 * [chapi.io playground upgrades - credential selector, resident card](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0111.html)  Manu Sporny (Wednesday, 27 July)
 The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue.
 * [...]
 We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary[...]
 * [You can try both of these new features out in the playground](https://playground.chapi.io/issuer)
 * [Jobs For The Future VC added to chapi.io playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0031.html)  Manu Sporny (Wednesday, 13 July)
 TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached.
 ### VC-HTTP-API  (VHA)
 The VC HTTP is a RESTful API specification (conforming with the [OpenAPI](https://swagger.io/specification/) [3.0 Specification](https://swagger.io/specification/) for constructing and verifying objects which conform to the Verifiable Credential Data Model specification.
 A bit more about the OpenAPI 3.0 specification itself:
 The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
 This API is versioned in conformance with the [Semantic Versioning 2.0 specification](https://semver.org/) to prevent breaking changes between minor versions, and to allow for reliable testing and integration of implementations of this API within enterprise environments. This API provides a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).
 This slide, from a slide deck presentation by Manu Sporny to the W3C Credentials Community Group on 20 April 2021, explains the relationship of the VC-HTTP-API to CHAPI:
 ### WACI
 There are interactions between a wallet and relying party that require passing information between the two. WACI provides a standard for these interactions.
 * [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/#status-of-this-document](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0/#status-of-this-document)
 WACI bound to JWT - signed. Could be JWE technically (would have to know the other parties DID and Keys - only optionally required here).
 Fully supports credential manifest and presentation exchange.
 Could be bound to DIDComm
 * [Introducing: WACI (Wallet And Credential Interaction)](https://iiw.idcommons.net/4K/_Introducing:_WACI_(Wallet_And_Credential_Interaction)) by Jace Hensley
 * [https://specs.bloom.co/wallet-and-credential-interactions/](https://specs.bloom.co/wallet-and-credential-interactions/)
 * [https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0](https://specs.bloom.co/wallet-and-credential-interactions/versions/v0.1.0)
 Orie linked this related github issue and discussion:[https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84](https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84)
 Also related: [https://w3c-ccg.github.io/vp-request-spec/#format](https://w3c-ccg.github.io/vp-request-spec/#format)
 Use cases support mobile wallets, backend services and web apps.
 Supports chaining of requests…. Relies on credential manifest and presentation exchange
 W3C CCG work seems focussed on the “vc-http-api” and “vp-request-spec” as the solutions to this problem…
 We reviewed IoT / Web / API considerations for presentation exchange.
 We notes the following hypothetically viable non interoperable solutions to this problem:
 1. DIDComm v1 (IIW ticket flows?)
 2. vp-request-spec + CHAPI
 3. vc-http-api + …. ? / w3c ccg traceability API.
 4. OIDF vp-token spec?
 * [WACI (Wallet And Credential Interaction)](https://identity.foundation/wallet-and-credential-interactions/)
 ### Message Format
 Presentation Exchange defined in DIF
 Presentation Exchange is a protocol to support the interaction between holders and verifiers. It supports them being able to express what combination of credential the verifier wants or needs.
 Credential Manifest as defined in DIF
 Asking for a presentation
 And asking proof to enable issuing a credential.
 Indy Proof Request
 Aries Exchange Protocol
 Define the messages that go back and forth between
 Issuer and holder (4 messages)
 Holder and Verifier (3 messages)
 Different formats (types of credentials) are different attachments in those messages.
 DIDComm v1, there is AIP v1 and AIP v2 :)
 Where does it go?
 ### Assorted
 - Work within DIF
 - [Credentials and Claims](https://github.com/decentralized-identity/org/blob/master/Org%20documents/WG%20documents/DIF_CC_WG_charter_v1.pdf) working group (explicitly mentions something like "unifying existing formats and protocols" in its charter) <- fast time
 - Or new WG, draft charter by Balazs: [https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/](https://docs.google.com/document/d/18L2-t4_2yrO_xZkwPjMCRcKIDiRGCziNs2X4k093pvo/)
 - DIF - presentation exchange?
 Timeline:
 - When is the next Claims and Credentials Group? (who are the chairs? - Martin, Wayne, Daniel McGrogan ) Bi-Weekly -
 - Work Items within DIF WG can have their own dedicated Calls.
 - Join DIF: [https://identity.foundation/join/](https://identity.foundation/join/)
 - Stewardship - , Orie, Brent, Snorre, Stephen? Troy
 - DIDComm Expert - Sam, Stephen
 - Presentation Exchange Expert -
 - Register for the first meeting:(26th April, Monday 1pm ET) [https://forms.gle/SqkymupnYc9tDARm9](https://forms.gle/SqkymupnYc9tDARm9)
 * [VC-HTTP-API discussion (FAQ, vs other APIs, etc)](https://iiw.idcommons.net/13E/_VC-HTTP-API_discussion_-FAQ,_vs_other_APIs,_etc-) by Dmitri Zagidulin
 * [https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/](https://w3c-ccg.github.io/meetings/2021-04-22-vchttpapi/)
 * [W3C CCG weekly call about VC HTTP APIs](https://iiw.idcommons.net/1P/_9am_PT:_W3C_CCG_weekly_call_about_VC_HTTP_APIs) – W3C CCG
 We discussed[https://github.com/w3c-ccg/vc-http-api](https://github.com/w3c-ccg/vc-http-api)[Address concerns with VC-HTTP-API #190](https://github.com/w3c-ccg/community/issues/190)
 * [[PROPOSED WORK ITEM] Traceability API #191](https://github.com/w3c-ccg/community/issues/191)  
 See also [https://w3c-ccg.github.io/meetings/](https://w3c-ccg.github.io/meetings/)
--- a/identosphere-dump/open-standards/exchange-protocol/mdl.md
+++ b/identosphere-dump/open-standards/exchange-protocol/mdl.md
@ -1,53 +0,0 @@
 # MDL
 * [Verifiable Driver's Licenses and ISO-18013-5 (mDL)](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html) Manu Sporny (Monday, 29 November)
  > Spruce, MATTR, and Digital Bazaar have collaborated on creating an interoperability test suite for something we're calling the "Verifiable Driver's License" (temporary name):
 * [The test suite](http://w3id.org/vdl/interop-reports) demonstrates that a few things are possible in addition to what mDL provides:
  > 1. The mDL data model can be expressed cleanly using W3C Verifiable Credentials
 * ["Apple launches the first driver’s license and state ID in Wallet with Arizona”](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0231.html) Liam McCarty (Wednesday, 23 March)
  > It’s sad and frustrating that this isn’t based on verifiable credentials… it appears vendor lock in is going to be hard to prevent.
  > 
  > For anyone who missed the November coverage about this, here’s a pretty outrageous CNBC article: "[Apple is sticking taxpayers with part of the bill for rollout of tech giant's digital ID card](https://www.cnbc.com/2021/11/14/apple-sticking-taxpayers-with-part-of-the-bill-for-digital-id-rollout.html)”
 * [Mike Jones shares](https://self-issued.info/?p=2136) that CBOR (Concise Binary Object Representation)  is officially a [specification at IETF](https://www.rfc-editor.org/rfc/rfc8943) - woohoo! and it is a key part of [ISO’s mDL standard](https://www.iso.org/committee/45144.html) (date fields must use it).
  > 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.
 - [The selective disclosure industry landscape, including Verifiable Credentials and ISO Mobile Driver Licenses (mDL)](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-why-selective-disclosure-00) – [Kristina Yasuda](https://twitter.com/kristinayasuda)
 * [Working Group for Privacy Enhancing Mobile Credentials](https://kantarainitiative.org/introducing-kantaras-working-group-for-privacy-enhancing-mobile-credentials/) Kantara Initiative
  > Clearly the use of a driver’s license goes well beyond proving eligibility to drive a vehicle. It has become the de-facto standard for proving that you are who you say you are – and are entitled to the product or service requested. An increasing number of states are adopting mobile ID systems to recognise and verify mobile credentials including driver’s licenses (mDL).
 * [Kantara Releases Report on Identity and Privacy Protection For mobile Driver’s Licenses](https://kantarainitiative.org/kantara-releases-report-on-identity-and-privacy-protection-for-mobile-drivers-licenses/)
  > The report outlines how to implement mDL systems as Privacy Enhancing Technologies. It provides guidance on protecting people’s individual privacy and the digital identifiers of an individual who carries or uses an mDL.
 * [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
  > A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
 * [Mobile Driver’s Licence (mDL) VS. Self-Sovereign Identity (SSI)](https://inatba.org/identity/mobile-drivers-licence-mdl-self-sovereign-identity-ssi-comparison/) INATBA
 The ISO mDL specification (ISO-compliant Driving License or IDL)  is purpose driven, as its name implies, but is said to be specifically intended to:
 - enable verifiers not affiliated with or associated with the issuing authority to gain access to and authenticate the information
 - allow the holder of the driving license to decide what information to release to a verifier
 - include the ability to update information frequently, and to authenticate information at a high level of confidence.
 * [Verifiable Driver's Licenses and ISO-18013-5 (mDL)](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html) Manu Sporny (Monday, 29 November)
  > Spruce, MATTR, and Digital Bazaar have collaborated on creating an interoperability test suite for something we're calling the "Verifiable Driver's License" (temporary name):
 * [ISO/IEC 18013-5 vs Self-Sovereign Identity: A proposal for an mDL Verifiable Credential](https://www.procivis.ch/post/iso-iec-18013-5-vs-self-sovereign-identity-a-proposal-for-an-mdl-verifiable-credential) Procivis
  > in the context of government identity programs we see it as useful to compare them on the following parameters – background, credential data model & trust anchor and transmission protocols.
 * [Community Project on mDL and VCs](https://newsletter.identosphere.net/i/73037307/where-the-wc-verifiable-credentials-meets-the-iso-mobile-driving-license)
 Next week we are hosting two community calls to collect input for the project On Sept 27th in [Asia morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-apac-time-tickets-425211377677) and on Sept 27th in [US morning time](https://www.eventbrite.com/e/where-the-w3c-vcs-meets-the-iso-180135-mdl-eu-africa-americas-time-tickets-425242470677).
 * [Kantara lays out trust-building recommendations for mDLs](https://kantarainitiative.org/kantara-lays-out-trust-building-recommendations-for-mdls/)
 A global digital ID association has published steps vendors and others need to take in order to build effective mobile driving license services that also put ID holders in control of their identity. The Kantara Initiative’s report starts from the premise that trust in mobile driving licenses grows with the degree of control that license holders have over the documents, their privacy and
 * [“Decentralised Identity: What’s at Stake?”](https://inatba.org/wp-content/uploads/2020/11/2020-11-INATBA-Decentralised-Identity-001.pdf). ← earlier paper
  > Looking at the above comparison, It is clear that both approaches strive to maintain user control of their personal data, selective disclosure/data minimization, and cryptographic methods to prove the integrity of identity claims. The differences are: first in their reliance (mDL) or independence (SSI) from issuer involvement in verification interactions, and second in their cryptographic approach, where the mDL relies on externally provided cryptographic tools while SSI builds on holder controlled private keys
 * [An Identity Wallet Bill of Rights - Starting With the Mobile Driver License](https://blog.spruceid.com/an-identity-wallet-bill-of-rights/) Spruce Systems
 Spruce’s continued mission is to let users control their data across the web, whether it’s web2, web3, or beyond. This also applies to credentials issued by existing entities, such as the Mobile Driver License (mDL) issued by motor vehicle authorities across the world.
 - [The selective disclosure industry landscape, including Verifiable Credentials and ISO Mobile Driver Licenses (mDL)](https://datatracker.ietf.org/meeting/114/materials/slides-114-jwp-why-selective-disclosure-00) – [Kristina Yasuda](https://twitter.com/kristinayasuda)
 * [Apple announces first states signed up to adopt driver’s licenses and state IDs in Apple Wallet](https://www.apple.com/newsroom/2021/09/apple-announces-first-states-to-adopt-drivers-licenses-and-state-ids-in-wallet/)
 Arizona, Connecticut, Georgia, Iowa, Kentucky, Maryland, Oklahoma, and Utah are among the first states to bring state IDs and driver’s licenses in Wallet to their residents
 * [Google is bringing Electronic IDs to Android](https://venturebeat.com/security/google-is-bringing-electronic-ids-to-android/) VentureBeat
 very soon, we will launch another [Jetpack compatibility library](https://venturebeat.com/2019/05/07/google-adds-10-libraries-to-android-jetpack-unveils-kotlin-toolkit-for-ui-development/) that app developers can use immediately to write such apps for various DMVs or whatever cards — in the future, maybe even travel documents, although that kind of standardization for international travel is even further out.
--- a/identosphere-dump/open-standards/exchange-protocol/oidc.md
+++ b/identosphere-dump/open-standards/exchange-protocol/oidc.md
@ -1,246 +0,0 @@
 # OpenID Connect
 * [Public Review Period for Proposed Final OpenID Connect Logout](https://openid.net/2022/07/05/public-review-period-for-proposed-final-openid-connect-logout-specifications/)
 Unless issues are identified during the review that the working group believes must be addressed by revising the drafts, this review period will be followed by a seven-day voting period during which OpenID Foundation members will vote on whether to approve these drafts as OpenID Final Specifications.
 * [More Killer Whale Jello Salad…figuring out how credential exchange can harmonize.](https://iiw.idcommons.net/24B/_More_Killer_Whale_Jello_Salad...figuring_out_how_credential_exchange_can_harmonize.) by Kaliya Young et al.
  > - Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
  > - Goal to create a bridge between
  > - the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
  > - Aries protocols run on top of DIDComm
  > - If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
  > - Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
  > - So can be tested with next SVIP - testing.
  > - Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
  > - Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
 * [OpenID Connect Presentation at IIW XXXII](https://self-issued.info/?p=2167)
 - [OpenID Connect](https://openid.net/connect/)
 - [Frequently Asked Questions](https://openid.net/connect/faq/)
 - [Working Group Mailing List](https://lists.openid.net/mailman/listinfo/openid-specs-ab)
 - [OpenID Certification Program](https://openid.net/certification/)
 - [Certified OpenID Connect Implementations Featured for Developers](https://openid.net/developers/certified/)
 * [Use CodeB SSI as OpenID Connect Identity Provider for WordPress](https://blog.codeb.io/use-codeb-ssi-as-oidc-identity-provider-for-wordpress/) CodeB
 The Self-Sovereign Identity System of CodeB does not only support W3C DID’s but comes also with an inbuilt OpenID Connect (OIDC) Identity Provider. [OpenID Connect meets distributed Self-Sovereign Identities.](https://www.codeb.io/openid-connect-meets-distributed-self-sovereign-identities/)
 * [Spruce Developer Update #20](https://blog.spruceid.com/spruce-developer-update-20/)
 We've set up a [release pipeline](https://github.com/spruceid/ens-oidc/) and had our first witnessed deployment for the ENS Community-Maintained OIDC IdP ([more info here](https://blog.spruceid.com/sign-in-with-ethereum-decentralizing-an-identity-provider-server/)
 * [Use-cases: OIDC for Verifiable Credentials - How do you want to use Identity Provider you control?](https://iiw.idcommons.net/12G/_Use-cases:_OIDC_for_Verifiable_Credentials_-_How_do_you_want_to_use_Identity_Provider_you_control%3F) by Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker
 * [Browser APIs to enable OpenID Session Management and Privacy](https://iiw.idcommons.net/13L/_Browser_APIs_to_enable_OpenID_Session_Management_and_Privacy) by Sam Goto
 How does logout in OIDC happen?
 - Classification problem - browsers do not know it is a logout now
 - Easiest way
 - Browser asks for a user consent
 - Hard from a permission implementation perspective
 - Tim: No issues with this idea
 - If user logged into several OPs, user will not look to all the ones they log out from
 - Option2
 - Browser classifies signing-in event
 - On log out does not prompt the user and IdP has no incentives to lie
 - RPs get to determine if they want to log the user out or not
 - Whether you can swap generic frame with fenced frame, frame can see it’s own cookies
 - May not be able to pass any parameters that you need to pass; no link decoration for framed frame
 - Subdomains also considered, but not well thought out
 - Logout URL - other option to add, but more work for RP: Resource metadata. Specification - not much adoption. It just feels like a place where RP metadata could be declared which could be useful in this context of the RP defining its metadata (e.g. what IDP it uses
 - [draft-jones-oauth-resource-metadata-01 - OAuth 2.0 Protected Resource Metadata (ietf.org)](https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01)
 - On digression: [https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png](https://cloudidentity.com/blog/wp-content/uploads/2013/01/3252.image_5F00_04277494.png)
 - Messy real-life situation - sign in to AAD with OIDC and WS-fed; register something at sign-in. From a user, same account, does not matter which protocol is used
 - What needs more to be discussed what log out means to the user
 - User does not understand when they log out from office, they also log out from Azure
 - Also a developer choice
 - Relevant one, but not much browsers can do about
 - If a bigger picture is browser wants to be in the middle, browser can do something in this area too.
 - Ugly part of logout - mechanisms to allow the range of services
 - IdP does not need to send back list of all RPs user is logging out from
 - Idea not entirely off for IdP to tell a browser from there it wants to log user out from
 - Browser have confident of the user intent
 - Prompt the user for the intent - never a good idea
 - Logout API that community can control a behaviour of
 - You call it, browser logs it, and tell where the user left of
 - Browser observes the login - passively. Heuristics - what if the browser has not seen it..
 - some of this is already starting to show up in chrome canarie
 - [https://chromium-review.googlesource.com/c/chromium/src/+/2837551](https://chromium-review.googlesource.com/c/chromium/src/+/2837551)
 - If domain name ETLD of the issuer is the same as IdP, automatically logs out
 * […]
 - Looks like we can preserve session management if we figure out logout
 - Next would be good to see pseudo code with concrete scenario and sequence diagrams
 - Pseudo text: [https://github.com/WICG/WebID/blob/main/cookies.md#logout](https://github.com/WICG/WebID/blob/main/cookies.md#logout)
 - Prototype is being built
 - AOB? At IIW?
 - Understand what third party cookies actually mean - no cookies at all? Partition cookies going away. The way firefox is doing it?
 * [@kimdhamilton](https://twitter.com/kimdhamilton) · [May 25](https://twitter.com/kimdhamilton/status/1397241823190523904)
 I've read every decentralized identity protocol so you don't have to. They all just read like "nothing to see here, just f- right off" Oh, except for OIDC Credential Provider. Well done to them!
 * [How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding](https://pranavkirtani.medium.com/how-a-combination-of-federated-identity-and-verifiable-credentials-can-help-with-customer-7e6518feb018) Pranav Kirtani
 Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding.
 * [OIDC with SIOPv2 and DIF Presentation Exchange](https://vimeo.com/630104529) Sphereon
 * [First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) OpenID
 - Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
 - Implementer’s Drafts vote announcement: Tuesday, January 18, 2022
 - Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *
 * [First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved](https://openid.net/2022/02/08/first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications-approved/) OpenID
 * [Vote for First Implementer’s Drafts of OIDConnect SIOPV2 and OIDC4VP Specifications](https://openid.net/2022/01/18/notice-of-vote-for-first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications/) OpenID
 The official voting period will be between Tuesday, February 1, 2022 and Tuesday, February 8, 2022, following the [45-day review](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) of the specifications.
 * [Differences between SAML, OAuth & OIDC (OpenID Connect)](https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/)
  > SAML 2.0 - Security Assertion Markup Language
 > 
 > OAuth 2.0 - Web Authorization Protocol
 > OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0
 * [OpenID Presentations at December 2021 OpenID Virtual Workshop](https://self-issued.info/?p=2214)
 - OpenID Connect Working Group [(PowerPoint)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_9-Dec-21.pptx) [(PDF)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_9-Dec-21.pdf)
 - OpenID Enhanced Authentication Profile (EAP) Working Group [(PowerPoint)](http://self-issued.info/presentations/OpenID_EAP_Working_Group_9-Dec-21.pptx) [(PDF)](http://self-issued.info/presentations/OpenID_EAP_Working_Group_9-Dec-21.pdf)
 use of IETF Token Binding specifications with OpenID Connect and integration with FIDO relying parties and/or other strong authentication technologies.”
 * [DIF and OIDF cooperation](https://medium.com/decentralized-identity/dif-oidf-9753b9bd0093) 
  > to work together on areas of mutual interest, allowing working groups to align and coordinate through dual-members. The first major collaboration, which has already been underway for weeks, is a process for revising the Self-Issued OpenID Connect (SIOP) chapter of the OpenID Connect (OIDC) specification.
 * [OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core is now a Final Specification](https://openid.net/2021/09/01/openid-connect-client-initiated-backchannel-authentication-ciba-core-is-now-a-final-specification/)
 The OpenID Foundation membership has approved the following [MODRNA](https://openid.net/wg/mobile/) specification as an OpenID Final Specification:
 * [OpenID Connect Presentation at 2021 European Identity and Cloud (EIC) Conference](https://self-issued.info/?p=2187)
 I gave the following presentation on the [OpenID Connect Working Group](https://openid.net/wg/connect/) during the [September 13, 2021 OpenID Workshop](https://openid.net/oidf-workshop-at-eic-2021-monday-september-13-2021/) at the [2021 European Identity and Cloud (EIC) conference](https://www.kuppingercole.com/events/eic2021/). As I noted during the talk, this is an exciting time for OpenID Connect; there’s more happening now than at any time since the original OpenID Connect specs were created!
 - OpenID Connect Working Group [(PowerPoint)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_13-Sep-21.pptx) [(PDF)](http://self-issued.info/presentations/OpenID_Connect_Working_Group_13-Sep-21.pdf)
 * [OIDC with SIOPv2 and DIF Presentation Exchange](https://vimeo.com/630104529) Sphereon
 * [OpenID Connect Presentation at IIW XXXIII](https://self-issued.info/?p=2196) Mike Jones
 - Introduction to OpenID Connect [(PowerPoint)](https://self-issued.info/presentations/OpenID_Connect_Introduction_12-Oct-21.pptx) [(PDF)](https://self-issued.info/presentations/OpenID_Connect_Introduction_12-Oct-21.pdf)
 The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect.
 * [First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications Approved](https://openid.net/2022/02/08/first-implementers-drafts-of-openid-connect-siopv2-and-oidc4vp-specifications-approved/) OpenID
 - [Self-Issued OpenID Provider v2](https://openid.net/specs/openid-connect-self-issued-v2-1_0-07.html)
 - [OpenID Connect for Verifiable Presentations](https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-08.html)
 * [Nat describes GAIN](https://nat.sakimura.org/2021/09/14/announcing-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.
 - [OpenID Connect Client-Initiated Backchannel Authentication Flow – Core 1.0](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html)
 A Final Specification provides intellectual property protections to implementers of the specification and is not subject to further revision.
 * [Intro to OpenID Connect at IIW XXXI](https://self-issued.info/presentations/OpenID_Connect_Introduction_20-Oct-20.pdf).
 It is a great overview of the key design principles of OpenID and how we got to now with the protocol 
 * [Identity, Unlocked... SIOP with Kristina Yasuda](https://auth0.com/blog/identity-unlocked-explained-season-2-ep-5/)
  > As a discovery mechanism to invoke a Self-Issued OP, the discussion on the podcast covered the usage of a custom schema 'openid://'. Alternative mechanisms to address the limitations of custom schemas are being actively explored in the WG.
 The conversation meanders through deeper details, from how the current [SIOP specification draft](https://bitbucket.org/openid/connect/src/master/openid-connect-self-issued-v2-1_0.md) under the OpenID Foundation picks up the mission from a [former attempt under DIF](https://identity.foundation/did-siop/) to encoding approaches for verifiable presentations (embedding in JWTs, [LD proofs](https://w3c-ccg.github.io/ld-proofs/), how to represent attributes
 * [The Era of Self-Sovereign Identity](https://www.chakray.com/era-self-sovereign-identity/) Chakaray
 VC-AuthN OIDC uses the OpenID connect standards to easily integrate with the supported systems and also provides a way to authenticate using the verifiable credentials, giving the control back to the user. This is similar to the traditional OpenID connect, the only difference is in the token information. Rather than using the user’s information to construct the token, this uses claims in the verifiable credentials presented by the user.
 * [Let’s talk about digital identity with Oscar Santolalla, Nat Sakimura and Petteri Stenius](https://www.ubisecure.com/podcast/openid-connect/)
 the history of OpenID Connect and how it became so prevalent, with special guests [Nat Sakimura](https://www.linkedin.com/in/natsakimura/), Chairman at the OpenID Foundation, and [Petteri Stenius](https://www.linkedin.com/in/petteri-stenius-6a637/), Principal Scientist at Ubisecure. [...]
 “New technology seldomly completely replaces the older technologies. They will form additional layers, and slowly start replacing it.”
 * [101 Session: OpenID Connect](https://iiw.idcommons.net/1B/_101_Session:_OpenID_Connect) by Mike Jones
 Described at: [https://openid.net/connect/](https://openid.net/connect/)
 * [OpenID Connect Claims Aggregation](https://iiw.idcommons.net/5B/_OpenID_Connect_Claims_Aggregation) by Nat Sakimura, Edmund Jay, Kristina Yasuda
 [2021-04-21_OpenID Connect Claims Aggregation](https://docs.google.com/presentation/d/1w-rmwZoLiFWczJ4chXuxhY0OsgHQmlIimS2TNlce4UU/edit?usp=sharing)
 * [OpenID Connect 4 Identity Assurance](https://iiw.idcommons.net/10J/_OpenID_Connect_4_Identity_Assurance) by Torsten Lodderstedt
  > [https://www.slideshare.net/TorstenLodderstedt/openid-connect-4-identity-assurance-at-iiw-32](https://www.slideshare.net/TorstenLodderstedt/openid-connect-4-identity-assurance-at-iiw-32)
  > 
  > Jacob Dilles proposed to allow RPs to use handles for pre-configured eKYC requests. I filled an issue for discussion by the WG ([https://bitbucket.org/openid/ekyc-ida/issues/1245/pre-configured-claims-ekyc-requests](https://bitbucket.org/openid/ekyc-ida/issues/1245/pre-configured-claims-ekyc-requests).
 * [OpenID Connect: Session Management vs Privacy](https://iiw.idcommons.net/11M/_OpenID_Connect:_Session_Management_vs_Privacy) by David Waite
 To recap:
 - Front-channel logout is simple
 - …but brittle and doesn’t give good security guarantees
 - Back-channel logout is robust
 - …but difficult to implement/support, can still miss signals
 - Session Management is useful for some apps
 - …but is broken in many browsers
 On their own independent schedules, all browsers have either broken or have plans to break state sharing via cross-site iframes to limit user tracking - arguably making the Session Management approach unusable.
 * [The OpenID Connect Logout specifications are now Final Specifications](https://self-issued.info/?p=2298)
 The OpenID Connect Logout specifications are now Final Specifications
 Thanks to all who helped us reach this important milestone! This was originally [announced on the OpenID blog](https://openid.net/2022/09/12/the-openid-connect-logout-specifications-are-now-final-specifications/).
 * [OpenID Connect for W3C Verifiable Credential Objects](https://iiw.idcommons.net/2F/_OpenID_Connect_for_W3C_Verifiable_Credential_Objects) by Oliver Terbu, Torsten Lodderstedt, Kristina Yasuda, Adam Lemmon, Tobias Looker
 Slides: [https://www.slideshare.net/TorstenLodderstedt/openid-connect-for-w3c-verifiable-credential-objects](https://www.slideshare.net/TorstenLodderstedt/openid-connect-for-w3c-verifiable-credential-objects)
 - Have been incubated in OpenID Foundation and DIF’s joint Self-Issued OpenID Provider WG - contact Kristina ([kristina.yasuda@microsoft.com](mailto:kristina.yasuda@microsoft.com) for participation details)
 * [First Public Review Period for OpenID Connect SIOPV2 and OIDC4VP Specifications Started](https://openid.net/2021/12/17/first-public-review-period-for-openid-connect-siopv2-and-oidc4vp-specifications-started/) OpenID
 - Implementer’s Drafts public review period: Friday, December 17, 2021 to Monday, January 31, 2022 (45 days)
 - Implementer’s Drafts vote announcement: Tuesday, January 18, 2022
 - Implementer’s Drafts voting period: Tuesday, February 1, 2022 to Tuesday, February 8, 2022 *
 * [Differences between SAML, OAuth & OIDC (OpenID Connect)](https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/)
  > SAML 2.0 - Security Assertion Markup Language
 > 
 > OAuth 2.0 - Web Authorization Protocol
 > OpenID Connect 1.0 (OIDC) - Simple identity layer on top of OAuth 2.0
 * OpenID: [Public Review Period for Proposed Final OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core Specification](https://openid.net/2021/06/07/public-review-period-for-proposed-final-openid-connect-client-initiated-backchannel-authentication-ciba-core-specification/)
 * [Distributed Open Identity: Self-Sovereign OpenID: A Status Report](https://identiverse.gallery.video/detail/videos/standards/video/6184823227001/distributed-open-identity:-self-sovereign-openid:-a-status-report?autoStart=true)
  > follow up of the Identiverse 2019 session “SSO: Self-sovereign OpenID Connect – a ToDo list”. (Decentralized Identity, Mobile, Verified Claims & Credentials, Standards, Preeti Rastogi, Nat Sakimura)
 * [Personal Digital Transformation and Holistic Digital Identity](https://www.youtube.com/watch?v=9DExNTY3QAk) OpenID Japan ← His last public talk
 from the OpenID Summit Tokyo 2020 Keynote […] about Claims, Identity, Self-ness, Who-ness, and OpenID Connect and Decentralized Identity.
 * [SIOP Use-cases - IIW Spring 2021](https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit#slide=id.p)
 - Continuity of a service
 - Offline Authentication
 - Speed, reduced latency
 - Choice, Portability
 - Privacy
 * [DID chooser for SIOP](https://iiw.idcommons.net/20A/_DID_chooser_for_SIOP) by tom jones & friends
 * [https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit?ts=607b7e5d#slide=id.gd2c45a9dcd_7_21](https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit?ts=607b7e5d#slide=id.gd2c45a9dcd_7_21)
 Goal is to allow folks to pick their DID they want to use for a website.
 “Subject choosing which DID to present”.
 Use case:
 A user goes to an RP, and decides to register for return visits.
 RP can’t offer folks the Nascar Problem (too many IDP logos on the login screen).
 Select a Wallet vs Select a Wallet and Identifier.
 What happens when SIOP arrives?
 We will need a DID chooser.
 Some wallets will hold credentials for multiple identifiers, some will hold only 1.
 An RP offers users multiple options for registration (Google, Facebook, Yahoo…. And coming soon… Personal)
 RP should disclose their ID and why they are asking the user for what data.
 Options we consider:
 - [https://w3c-ccg.github.io/credential-handler-api/](https://w3c-ccg.github.io/credential-handler-api/)
 - [https://w3c-ccg.github.io/vp-request-spec/#format](https://w3c-ccg.github.io/vp-request-spec/#format)
 - [https://specs.bloom.co/wallet-and-credential-interactions/](https://specs.bloom.co/wallet-and-credential-interactions/)
 - [https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84](https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/84)
 * [Using OpenID4VC for Credential Exchange; Technometria - Issue #62](http://news.windley.com/issues/using-openid4vc-for-credential-exchange-technometria-issue-62-1374264?via=twitter-card&client=DesktopWeb&element=issue-card)
 Extending OAuth and OIDC to support the issuance and presentation of verifiable credentials provides for richer interactions than merely supporting authentication. All the use cases we’ve identified for verifiable credentials are available in OpenID4VC as well.
--- a/identosphere-dump/open-standards/standards.md
+++ b/identosphere-dump/open-standards/standards.md
@ -1,150 +0,0 @@
 ---
 published: false
 ---
 # Standards
 * [FYI: What makes a standard ‘world class’?](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0213.html) Michael Herman (Trusted Digital Web) (Saturday, 14 August)
  > - A world class standard should have well-defined objectives that respond to real needs in a timely manner.
  > - Its technical content should be complete and accurate.
  > - It should be easy to understand (or as easy as the subject matter allows!) and easy to implement.
  > - Its requirements should be expressed clearly and unambiguously.
  > - It should be validated.
  > - It should be well-maintained.
  > 
  > Reference: [A Guide To Writing World Class Standards](https://www.etsi.org/images/files/Brochures/AGuideToWritingWorldClassStandards.pdf)
 * [Trust Frameworks? Standards Matter](https://medium.com/@trbouma/trust-frameworks-standards-matter-47c946992f44) Tim Bouma
  > He points at the NIST documents about it [Developing Trust Frameworks to Support Identity Federations](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8149.pdf) published in 2018. He also points at the Canadian government’s definition of standards.
  > 
  > “a document that provides a set of agreed-upon rules, guidelines or characteristics for activities or their results. Standards establish accepted practices, technical requirements, and terminologies for diverse fields.”  He goes on to highlight a lot of the work being done in Canada and where it all sits relative to being a standard - “In closing, there are lots of trust frameworks being developed today. But to be truly trusted, a trust framework needs to either apply existing standards or become a standard itself.”
 * [Open standards should be developed openly](https://blog.weareopen.coop/open-standards-should-be-developed-openly-1f0cf552308d) WeAreOpen
  > Open standards should be developed openly because not enough people work to ensure that equity is central to innovation and development. We believe that openness is an attitude, and one which bears fruit over time from which everyone can benefit.
 * [Global Standards Mapping Initiative](https://www.continuumloop.com/global-standards-mapping-initiative/) ContinuumLoop
 This past November, the GBBC released [The Global Standards Mapping Initiative 2.0](https://gbbcouncil.org/wp-content/uploads/2021/11/GBBC-GSMI-2.0-Report-1.pdf), updating the [standards published in 2020](https://gbbcouncil.org/wp-content/uploads/2020/10/GSMI-Legal-Regulatory-Report.pdf). The GBBC is a strong proponent of standardization and intends to serve as a baseline for establishing frameworks and standards that will allow for adoption and innovation.
 * [Premature Standardization & Interoperability](https://www.continuumloop.com/premature-standardization-interoperability/) Continuum Loop
 Here’s my premise – we don’t have standards nor interoperability – at least not as people really need. We have been through a process that is powerful and good – but what we have is what I call “premature standardization.” It’s a great start but nowhere near where things will be.
 * [Trinsic Basics: What Are SSI Standards?](https://trinsic.id/what-are-ssi-standards/)
  > There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.
 * [Manifesto: Rules for standards-makers](http://scripting.com/2017/05/09/rulesForStandardsmakers.html)
  > I've used all kinds of formats and protocols in a long career as a software developer, even created a few. My new manifesto summarizes what I've learned about what works and what doesn't.
 * [Linked Data Security](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0134.html) ([slide deck](https://lists.w3.org/Archives/Public/public-credentials/2021Feb/att-0134/2021-Linked-Data-Security.pdf)
  > The attached slide deck provides a basic overview (with examples) of Linked Data Security as well as the specifications in that orbit. The W3C CCG is  actively developing a number of these specifications.
 * [Roadmap: Verifiable Trust Standards](https://lists.w3.org/Archives/Public/public-credentials/2021Mar/0014.html)
  > Green - General data format standards
  > Yellow - Vocabulary standards (I the mislabeled VC work)
  > Magenta - Protocol standards (I mislabeled DID Resolution)
  > Red - Low-level cryptographic primitives
  > Purple - General crypto packaging/protocol standards
  > Orange - Application layer standards
 ### OMG
 * [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)
 A [public presentation on the Disposable Self-sovereign Identity RFI](https://www.brighttalk.com/webcast/12231/461001) will be held on February 3, 2021 at 11:00 AM ET.
  > 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.
 ## Agents
 * [Agent Frameworks & Infrastructure (“Layer 2”)](https://identity.foundation/faq/#agent-frameworks-infrastructure-layer-2)
 * [Mobile Agent Development FAQ](https://iiw.idcommons.net/1L/_Mobile_Agent_Development_FAQ) by Horacio Nunez
  > - What’s the best place to start creating your own mobile agent?
  > - How do you get updates once you ship your first version?
  > - Do I actually have to support a fork for every mobile agent I create?
  > - Do I need to use a Mediator?
 ## 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.
 ## JSON
 * [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.
 ## 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.
  > 
  > 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 v3 release, a Verifiable Credentials implementation](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0051.html)  Julien Fraichot (Monday, 13 December)
  > 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.
  > 
  > 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).
 ### XSL SDI
 * [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
 ## Oberon protocol
 * [Better and more secure methods for API authentication](https://iiw.idcommons.net/1D/_Better_and_more_secure_methods_for_API_authentication) by Michael Lodder
 Presentation slides: [https://docs.google.com/p>resentation/d/1UO25DzVmq25ya2S4_tV5UKTSP6NtBggln9vP1TEXSzE/edit](https://docs.google.com/presentation/d/1UO25DzVmq25ya2S4_tV5UKTSP6NtBggln9vP1TEXSzE/edit)
 Goal of the Oberon protocol when building an API:
 - Super effective: no separate session token to required for accessing the API; very fast to issue and verify tokens; 128 bytes required per message
 - Privacy preserving
 - No new crypto, uses BLS signature keys and Pointecheval saunders Construction
 ### Timestamping
 * [Trusted Timestamping Part 3: Family of Standards](https://medium.com/finema/trusted-timestamping-part-3-family-of-standards-f0c89a5e97ab) Nunnaphat Songmanee Finema
 Read more about timestamping and its concepts at [Trusted Timestamping Part 1: Scenarios](https://medium.com/finema/trusted-timestamping-part-1-scenarios-9bf4a7cc2364) and [Trusted Timestamping Part 2: Process and Safeguards](https://medium.com/finema/trusted-timestamping-part-2-process-and-safeguards-f75286a0c370).
 Family of standards related to timestamping
 ## GAIN
 - [Nat has a presentation](https://nat.sakimura.org/2021/09/14/announcing-gain/)
 - There is a [linked in Group](https://www.linkedin.com/groups/12559000/)
 ## JWP
 * [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](https://twitter.com/kodonog) and [John Bradley](https://twitter.com/ve7jtb)
 - [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](https://twitter.com/selfissued)
 - [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](https://twitter.com/selfissued)
 - [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
 ### ONDC
 * [ONDC: An Open Network for Ecommerce](https://www.windley.com/archives/2022/08/ondc_an_open_network_for_ecommerce.shtml) Phil Windley
 * [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.
 ### BBS Creds
 - [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
 ## C2PA
 * [FYI: C2PA Releases Specification of World’s First Industry Standard for Content Provenance](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0207.html)  Leonard Rosenthol (Wednesday, 26 January)
 Just wanted to update folks here that the C2PA has released version 1.0 of their specification at [https://c2pa.org/specifications/specifications/1.0/index.html](https://c2pa.org/specifications/specifications/1.0/index.html).  As previously mentioned, it includes native support for VC’s for use in identification of actors (be they human, organizations, etc.).  Thanks to everyone here for their input on our work and helping us to deliver.
--- a/identosphere-dump/open-standards/verifiable-credentials.md
+++ b/identosphere-dump/open-standards/verifiable-credentials.md
@ -1,123 +0,0 @@
 ---
 published: false
 ---
 # Verifiable Credentials
 ## Contents
 - Varieties
  - JSON-LD 
  - JSON-LD ZKP BBS+
  - JSON-JWT
  - ZKP-CL - [IIA] Indy Aries AnnonCreds
  - JWP
 ## History
 * [The original #VerifiableCredentials were PKI-based SIM cards and EMV cards.](https://twitter.com/Steve_Lockstep/status/1419935186188341249) @Steve_Lockstep
  > These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. [https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little](https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little)
  > ![](https://i.imgur.com/ucAVxCX.png)
 ## DHS
 * [FYI >> DHS W3C VC/DID Implementation Profile: Credential Data Model Representation Syntax & Proof Format](https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0253.html) Anil John
  > We are walking this path step-by-step by documenting the results and lessons from the DHS sponsored multi-platform, multi-vendor interoperability plug-fests and other rigorous plug-fests with similar goals to develop a “DHS Implementation Profile of W3C Verifiable Credentials and W3C Decentralized Identifiers” to ensure the use of Security, Privacy and Interoperability implementation choices that are acceptable to the USG such that these capabilities can be deployed on and connect to USG networks and infrastructure.
  > … please [find attached the DHS Implementation Profile](https://lists.w3.org/Archives/Public/public-credentials/2022Sep/att-0253/DHS.W3C.VC-DID.Implemenation.Profile-20220929-SHARE.pdf) of W3C VCs and W3C DIDs normative guidance on:
  > - Credential Data Model Representation Syntax
  > - Credential Data Model Proof Format
 ## Ontology
 * [Verifiable Claim Protocol](https://github.com/ontio/ontology-DID/blob/master/docs/en/claim_spec.md) Ontology
 ## Literature
 ### NGI
 * [Crossword wins NGI Atlantic funds for Verifiable Credentials project](https://www.crosswordcybersecurity.com/post/next-generation-internet-grant-win) Crossword Cybersecurity
  > European Commission’s Next Generation Internet (NGI) initiative to lead a project to test the OpenID Foundation’s protocols for transferring verifiable credentials. Crossword’s partners in this project are Spruce Inc from the USA and Fraunhofer from Germany
 ## VC-EDU
 * [Add Your VC-EDU Use Cases](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0296.html)  Kerri Lemoie (Friday, 30 July)
  > For Github users, submit your use cases as issues here: [https://github.com/w3c-ccg/vc-ed-use-cases/issues](https://github.com/w3c-ccg/vc-ed-use-cases/issues)
  > 
  > This template can help guide you: [https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md](https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md)
 * [W3C Verifiable Credentials Education Task Force 2022 Planning](https://kayaelle.medium.com/w3c-verifiable-credentials-education-task-force-2022-planning-efc9b07cc2a3) Kerri Lemoie
  > We’ve been hard at work writing use cases, helping education standards organizations understand and align with VCs, and we’ve been heading towards a model recommendation doc for the community.
 ## Questions and Answers
 * [Question About Signatures & Contexts](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0290.html)  Kerri Lemoie (Friday, 30 July)
  > Is a VC still considered to be valid if it contains fields that are not described in its context file(s)? Does it depend on the signature type?
  * [Re: Question About Signatures & Contexts](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0291.html) Manu Sporny
    > The short answers are "maybe" and "yes".
 * [Any Good use case of PAM (Privileged account Management) using Vcs](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0028.html) Bob Wyman (Sunday, 7 November)
  > A common example of this is when someone uses a "Power of Attorney," to sign a contract. When they do, they typically sign documents with their own names and an annotation "on behalf of," "for," or "by power of attorney," they don't forge the signature of the one who granted the power of attorney.
 ## Varieties
 * [Verifiable Credentials Specifications Relationship Diagram](https://github.com/manicprogrammer/vc-spec-rel/) "Good for anyone but especially useful when trying to jump in on the deep end. If you walk even this limited tree of specs you know a lot" - [@michaelruminer](https://twitter.com/michaelruminer/status/1328827452886540296)
 * [Paper based Verifiable Credentials](https://www.youtube.com/watch?v=EXvWxFjHvdY) Mattr
  > Paper-based Verifiable Credentials allow us to have a low-tech solution for adopting VC's in situations where access to a phone cannot be guaranteed. This presentation looks at how this solution can be used to aid with the distribution of Vaccine Credentials.
 * [The Flavors of Verifiable Credentials](https://www.lfph.io/2021/02/11/cci-verifiable-credentials-flavors-and-interoperability-paper/) Linux Foundation Public Health Blog [pdf]((https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf))
  > 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’.
 * [Why the Verifiable Credentials Community Should Converge on BBS+](https://www.evernym.com/blog/bbs-verifiable-credentials/)
  > 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.
 * [GS1 2021 VC Prototype Journey](https://iiw.idcommons.net/20P/_GS1_2021_VC_Prototype_Journey) by Paul Dietrich
  > There was some feedback that  BBS, PE, and DIDCommV2 are possible points of convergence.
  > 
  > Also comments that WACI Bloom may play a part in convergence
 ## VC for OAuth 2.0
 * [VC Issuance based on OAuth 2.0](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0084.html)  Nikos Fotiou (Thursday, 14 April)
 We design, implement, and evaluate a solution for achieving continuous authorization of HTTP requests exploiting Verifiable Credentials (VCs) and OAuth 2.0. Specifically, we develop a VC issuer that acts as an OAuth 2.0 authorization server, a VC verifier that transparently protects HTTP-based resources, and a VC wallet implemented as a browser extension capable of injecting the necessary authentication data in HTTP requests without needing user intervention.
 ### VC-HTTP-API
 * [Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0313.html)  Orie Steele (Saturday, 31 July)
  > [https://github.com/OR13/GNARLY](https://github.com/OR13/GNARLY)  (while we wait for a better name...)
  > 
  > This demo API and Spec has a number of improvements over the current
  > 
  > VC-HTTP-API, including tested support for VC-JWT, JsonWebSignature2020 and
  > 
  > BBS+ Selective Disclosure Presentation Exchange.
 * [Updated VC-API diagram for Supply Chain flow](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0141.html)  Joe Andrieu (Tuesday, 28 September)
  > ![](https://i.imgur.com/mH5TBtU.png)
 * [re: VC API: handling large documents client to server](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0035.html)  Manu Sporny (Thursday, 10 February)
  > Typical solutions to this problem require that you put the binary data outside of the VC, if at all possible. This works well for common static images such as logos. It is also possible to split the VC into two VCs... one with the machine-readable data from the issuer (with a digital signature) and one with the image data from any source (without a digital signature, since, if hashlinked, the signature will verify the validity of the image data). That latter approach can be more privacy preserving AND more complex than many might feel is necessary.
 * [VC-API interoperability test suites ready for experimental integration](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0126.html)  Manu Sporny (Tuesday, 26 April)
  > * [The VC API test suite for basic issuer interop is here](https://w3c-ccg.github.io/vc-api-issuer-test-suite/)
  > * [The VC API test suite for basic verifier interop is here](https://w3c-ccg.github.io/vc-api-verifier-test-suite/)
  > * [The Data Integrity test suite for Ed25519Signature2020 interop is here](https://w3c-ccg.github.io/di-ed25519-test-suite/)
 * [Cross-industry VC API test suite achieves first multi-vendor interop for issue/verify](https://lists.w3.org/Archives/Public/public-credentials/2022May/0041.html)  Manu Sporny (Wednesday, 18 May)
  > We are happy to announce today that we have our first demonstration of cross-vendor interoperability between Danube Tech and Digital Bazaar for the VC Issuer API and VC Verifier API. The test suites test the OAS definition files (which are used to generate the specification):
  > * [2.1 Verify Credential - Data Integrity](https://w3c-ccg.github.io/vc-api-verifier-test-suite/#Verify%20Credential%20-%20Data%20Integrity)
  > * [2.1 Issue Credential - Data Integrity](https://w3c-ccg.github.io/vc-api-issuer-test-suite/#Issue%20Credential%20-%20Data%20Integrity)
 * [Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0231.html)  Joe Andrieu (Monday, 16 August)
  > ![](https://i.imgur.com/4hCNLVA.png)
 * [Issuer API Cross Trust Boundary Scoping - VC-HAPI (f.k.a. VC-HTTP-API)](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0263.html)  Brian Richter (Saturday, 24 July)
  > I think I'm starting to understand how RAR fits into this picture. This decision can be made for us by punting the question to the authorization process entirely. With RAR we can force the user to authorize for the actual subject they are issuing the credential about. Is Alice authorized to issue VCs with claims about did:example:12345? To answer that question Alice asks for a token with the following RAR request
 * [RAR Structures for VC HTTP API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0208.html)  Justin Richer (Wednesday, 21 July)
  > It seemed like a good idea when I first invented it a decade ago: [](https://blue-button.github.io/blue-button-plus-pull/#scopes)[https://blue-button.github.io/blue-button-plus-pull/#scopes](https://blue-button.github.io/blue-button-plus-pull/#scopes) or when it got pulled into other efforts like [https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html](https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html)… and Orie even suggested the following set of parameterized scopes for this API:
  > 'create:credentials': Grants permission to create credentials\
  > 'derive:credentials': Grants permission to derive credentials\
  > 'create:presentations': Grants permission to create presentations\
  > 'verify:presentations': Grants permission to verify presentations\
  > 'exchange:presentations': Grants permission to exchange presentations\
  > So what’s the problem? I can say with full confidence after years of experience building and deploying systems to support parameterized scopes like this that they are fragile, awkward, and lead to insecure corner cases.
 * [Bikeshed: Renaming the VC HTTP API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0131.html)  Manu Sporny (Saturday, 17 July)
  > the fundamental issue is that stringing a bunch of consonants together ("HTTP") rarely leads to something easy to say in conversation.
 * [Identity, Unlocked... Explained: Season 2, Ep. 2](https://auth0.com/blog/identity-unlocked-explained-season-2-ep-2/) Vittorio Bertocci with Filip Skokan
  > a conversation about a few three-letter extensions to OAuth (which, incidentally, would also fit well in a pirate incantation!): PAR, RAR, and JAR. Filip is a Senior Engineer II at Auth0, the author of a popular book on open source identification, and a contributor to both the [IETF](https://www.ietf.org/) and the [OpenID Foundation](https://openid.net/foundation/).