EIC Abstract Five years ago, my co-founders and I started Animo Solutions with one aim: to make self-sovereign identity and verifiable credentials easy and accessible for all. Since then, our team has created and assisted others in developing verifiable credential solutions for various applications, mainly using Hyperledger Aries standards. We've primarily used Aries Framework JavaScript (now Credo) and are still project maintainers today. The digital identity world is changing quickly, with decentralized identity gaining global recognition. Governments like the European Commission are adopting it, yet each approach is unique, leading to the constant emergence of new standards. This can make creating and maintaining accessible tools challenging. In this presentation, we'll discuss how Animo Solutions has adapted to these changes. We'll share our experience in developing user-friendly SSI tools and keeping up with evolving technical and legal standards. We'll also cover the importance of community involvement, our strategy for keeping up with trends, and why being a leader sometimes means embracing change first.

This document outlines the design of integrating W3C VC data model compliant AnonCreds credentials into Aries Framework JavaScript and Bifold. Opportunity: https://marketplace.digital.gov.bc.ca/opportunities/code-with-us/6f08d6d5-7e3d-489a-a98f-d7c607309dc9 Aries Framework JavaScript The following lists all the planned changes and areas of complexities we see in Aries Framework JavaScript. Overview: The first step will be to update AFJ to store all credentials in the new W3C format and not break current flows. Next, we will focus on issuing credentials in the W3C format using the W3C Verifiable Credential Data Integrity Attachment format. The third step is to allow requesting and presenting presentations of verifiable credentials (anoncredsvc-2023) in W3C format. After creating a release in AFJ containing the previously mentioned changes, during the last part, we will update Bifold's AFJ version and integrate the newly created functionality.

:::warning A lot of the tasks listed below are about renaming and removing the Aries brand. Agent Framework JavaScript was originally intended as a working title. In order to move forward quickly and avoid confusion, we need to decide on a name ASAP. ::: Technical AFJ main [x] Migrate repo to OWF org [ ] Update README(s) -- replace/remove all mentions of aries [ ] Update repo tags -- replace/remove all mentions of aries [ ] Verify CI pipeline is working as expected

Include the name of project being proposed. Agent Framework JavaScript (for now, at least we can keep the AFJ acronym) Preferred Maturity Level Specify the stage that you want this project to enter. See project lifecycle for information on the different stages. Stage summary Labs Stage: This initial stage is for projects that are either early-stage or well-established with minimal resource needs. It provides a neutral home to foster collaborative development and align with OpenWallet Foundation projects. Labs projects receive minimal support and undergo an annual review.

Todo [x] Write GH Discussion announcement [x] Ask for a slot during Aries WG [x] Write Discord/mailing list message [x] Post announcement to Discord[x] #aries [x] #aries-framework-javascript [x] #bifold [x] Post message to mailing list -> aries@lists.hyperledger.org

Generic mDoc library for TypeScript Various ecosystems (the US, Candada, the EU) are adopting the mDoc standard. As such, the demand for mDoc libraries will likey grow in the near future.mdl Eventhough there are various TypeScript based SSI ecosystems (AFJ, Veramo, etc.), there isn't a generic TypeScript library to handle the mDoc format. By making it a generic library instead of specific to AFJ, we we may catch the interest of other communities, increasing our chances to get funded. AFJ Proximity Module NOTE: this idea builds on top of the previous one.

This document aims to describe an interoperable method in which different agents, from different vendors can perform DIDComm based communication using Bluetooth as a means of transport. There are multiple versions of Bluetooth, and each version of Bluetooth supports multiple protocols, profiles and modes. Because of the wide range of methods to connect and exchange data, defining an interoperable method to exchange data over Bluetooth is not as straightforward as defining the transport for, lets say, HTTP. Bluetooth can not be treated as being on the same layer of HTTP, but more as TCP, where HTTP is a protocol that uses TCP. We need to define the specific Bluetooth protocols and methods to use to achieve interoperable communication. This document describes how DIDComm based communication can be achieved using Bluetooth Low Energy. Bluetooth Low Energy (BLE) is developed by Bluetooth SIG that builds on the lessons learned from building lots of Bluetooth Classic devices. Compared to Bluetooth Classic, BLE consumes less power, requires less time and effort to pair devices, and provides lower connection speeds. Although Classic Bluetooth has a bigger range and higher throughput, BLE shines at interoperability and the ease of connecting. Some methods in this document describe some well known BLE practices. In the future it may be best to reduce the size of the document to a required minimum, referencing other documents where needed.

By: Karim Stekelenburg (Animo Solutions) -- karim@animo.id Date: 18-07-2022 Version: 0.1 Introduction DIDComm is a promising technology. Although it finds its origin in the space of self-sovereign identity and is primarily used for the exchange of verifiable credentials and presentations, its potential stretches far beyond. One application where DIDComm has potential is chat. Why? DIDComm provides a secure and private communication channel based on decentralised identifiers (DIDs). One can leverage this nature of DIDComm for application specific use cases, by writing protocols atop of DIDComm. Although it is already possible to exchange simple text messages over DIDComm by using the basic-message protocol, 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.

Holder/subject binding In general, there are three ways to bind a credential to a specific holder or subject: using proof of identifier control, private holder binding/link secrets and biometrics. Proof of Identifier Control With this mechanism, it is assumed the holder or subject has some kind of identifier, and is able to prove control over it. When a credential is being issued, the issuer will include this identifier in the credential. In the W3C Verifiable Credential format, the key credentialSubject.id is used for this purpose. When the holder provides proof of this credential to a verifier, the holder is expected to prove that they have control over the identifier inside the credential. This way the verifier can be sure the credential is actually bound to the holder and that they’re not just the bearer of the credential. DIDs are a popular scheme to use for this identifier because it has a builtin cryptographic mechanism for proving control, but other identifiers can be used as well. For example, if you own the domain https://i-am-alice.com, this could theoretically be used as an identifier. In order to prove to a verifier that you control this domain, you could for example upload a file under https://i-am-alice.com/proof.txt that contains a long number that was provided by the verifier.

Elke seconde telt bij het verlenen van hulp in noodsituaties. Vanaf het plaatsvinden van een incident tot succesvolle interventie van hulpdiensten kunnen verschillende zaken het hulpverleningsproces vertragen. Pilotproject 'professionals buiten dienst' realiseert een oplossing voor het inzetten van gekwalificeerde burgerhulpverlening om de tijdsduur voor succesvolle interventie te verminderen. De scope van dit project is mensen met bestaande, vertrouwde kwalificaties. Zoals professionals werkzaam bij de meldkamer of brandweer. De volgende beoogde stap is het betrekken van burgerhulpverleners met bestaande, vertrouwde kwalificaties zoals BHV'ers, of mensen met een EHBO diploma. De uiteindelijke visie van het project is het betrekken van mensen met specifieke vaardigheden of eigenschappen die willen assisteren, zoals de dronebestuurder, duiker of oplettende buurtbewoner. De hulpverlener Deelnemers downloaden een app waarin zij al hun kwalificaties kunnen opslaan. Deze kwalificaties zijn een digitale versie van de bekende papieren diploma's. De kwalificaties worden uitgereikt door instanties die gekwalificeert zijn om deze uit te reiken. In de app kunnen deelnemers een oproep ontvangen, wanneer zij over bepaalde relevante kwalificaties beschikken. De oproep bevat informatie over het incident, de locatie en specifiek wat er van de hulpverlener wordt verwacht. Zij ontvangen deze oproep alleen wanneer zij:

🚧 1.1 Definitie digitale certificaten en in kaart brengen relatie tussen kwalificaties en meldcodes waarbij hulpverlening geschikt is. ✅ 1.2 Cloud service voor uitgifte digitale certificaten opzetten. 🚧 1.3 Security laag tussen cloud service en webportaal. ✅ 1.5 Communicatie en afstemming testlokatie(s) en VRD. ✅ 2.1 Basis architectuur mobiele applicatie. ✅ 2.2 Opslag van digitale certificaten realiseren. ✅ 2.3 Filtering van digitale certificaten realiseren. ✅ 2.4 Hoge resolutie locatie tracking. ✅ 2.5 Lage resolutie locatie tracking.

Digital Marketplace Opportunity BCGov Design Document ACA-Py working branch Table Of Contents [TOC] What we're looking for AATH Issue Credential video.

User calls Emergency Push Notification Push Notification Data: { "eventId": "string", "location": { "latitude": 50.234232, "longitude": 10.132223 },

Verifiable Credentials & Linked Data Proofs Table of Contents [TOC] Introduction Linked Data Proofs provide a mechanism to for ensuring the authenticity and integrity of Linked Data documents using mathematical proofs. Related Documents Notes on JSON-LD

Notes on JSON-LD Table of Contents [TOC] Introduction JSON-LD (or JavaScript Object Notation - Linked Data) is a mechanism that is used primarily for two use cases: providing context and creating decentralized references between data sets. Resources Used Internationalized Resource Identifier (IRI) Specification