This design proposes to extend the Aries Cloud Agent Python (ACA-PY) to support Hyperledger AnonCreds credentials and presentations in the W3C Verifiable Credentials (VC) and Verifiable Presentations (VP) Format. The aim is to transition from the legacy AnonCreds format specified in Aries-Legacy-Method to the W3C VC format. Overview The pre-requsites for the work are: The availability of the AnonCreds RS library supporting the generation and processing of AnonCreds VCs in W3C VC format. The availability of the AnonCreds RS library supporting the generation and verification of AnonCreds VPs in W3C VP format. The availability of support in the AnonCreds RS Python Wrapper for the W3C VC/VP capabilities in AnonCreds RS. Agreement on the Aries Issue Credential v2.0 and Present Proof v2.0 protocol attachment formats to use when issuing AnonCreds W3C VC format credentials, and when presenting AnonCreds W3C VP format presentations.For issuing, use the (proposed) RFC 0809 VC-DI Attachments For presenting, use the RFC 0510 DIF Presentation Exchange Attachments

Why? We want to encourage the use of AnonCreds in the W3C VC community, including through the use of multiple signatures (AnonCreds and others) on VCs. The introduction of AnonCreds @context creates friction in accomplishing that goal. Specifcally, guidance in the JSON-LD specification defines that it is a security risk for a component (such as a verifier) processing a JSON-LD object to dynamically load @context files. Thus, if a VC has both a NIST and AnonCreds signature, a verifies that receives a VC embedded in a non-AnonCreds VP would refuse to process the VC since it contains an @context that it has not pre-loaded. If we can eliminate the AnonCreds @context we can eliminate that friction. Note that a VP AnonCreds @context could remain because an AnonCreds VP should not be presented with multiple proofs. It makes no sense to present an AnonCreds VP with embedded VCs that expose all of the data. One would either present an AnonCreds VP and get the privacy-preserving benefits, or present a non-AnonCreds VP and lose those benefits. In this, suggestions are offered on how to eliminate the AnonCreds @context from the VP as well. <tl;dr> Proposed minimum changes to eliminate the VC AnonCreds @context array entry: Define the VC proof as a Data Integrity Proof with the cryptosuite of anoncredsvc-2023.Question: Does that require converting to the W3C VC Data Model (VCDM) 2.0?No -- there is a "standard" DataIntegrityProof context to add to a W3C VCDM 1.1 If we do switch to W3C VCDM 2.0, the IssuanceDate also needs to be changed to validFromQuestion: Any other changes needed?

After listening to the overview of Load Test Generator based on Locust, I think this is what we need for the load testing scenario we outlined in the Code With Us. As noted below, this a combination of generic features, some of which are for test management purposes only (e.g., request an invitation from a service by sending an HTTPS request), and others are "typical" Aries Agent controller "business logic" processing. Basic Script This is the script that we would like to see for our specific use case. The script has a number of general features (listed after) and those general features are assembled into the specific use case. The overall script could be altered for other use cases. Start load agent by connecting to mediator Request invitation from Issuer via HTTPS Process invitation in Agent to contact Issuer Auto-respond to IssuerAccept connection Receive Offer/Request/Receive Credential

Introduction A key goal in the use of digital credentials is that the issuers give credentials to holders, and the holders share the credentials with whomever they choose, without the knowledge of the issuers. A challenge in the acceptance of digital credentials, particularly those credentials issued by governments, is if the issuer tracks, or is perceived to track, the use of credentials by holders. In the use of unlinkable credentials, such as AnonCreds, the feature that could lead to Issuer tracking, or the perception of tracking, is revocation. In order to create a presentation that includes the revocation status of their credentials, holders must have reasonably up-to-date revocation data about those credentials. In practice, that means each time they share their data in a presentation, they have to collect revocation data. If the issuer is, or is perceived to be, the provider of that data, then tracking (or the perception of tracking) is possible. A ledger is used to mitigate that risk -- a neutral, disinterested party providing revocation data when needed. However, when a non-ledger approach is used, such as did:web (or did:webs), or the ledger is operated by the issuers themselves, that mitigation is lost. This paper proposes that instead of the holder retrieving the necessary revocation data from the provider, the verifier does that, and provides it to the holder. In that way, any tracking or perception of tracking is of the verifier, not the individual holders. Approach

Introduction This note covers the proposed design an ACA-Py Cluster, a cloud-native, scalable, highly available instance of ACA-Py that supports HTTP, Web Sockets and Return-Route transports. Currently, a Mediator Cluster is an ACA-Py Cluster that is deployed specifically to support the Mobile Wallet Mediator use case. A Cluster deployment requirement is that all components are horizontally scalable, with (almost) all components stateless. The specific exception about state is called out below. In these designs, the Controller is treated as an external component. The controller component may also be deployed in a cloud native, scalable manner. However, the deployment of the controller is an exercise left for the reader. Non-HA ACA-Py Deployment The following is a simple ACA-Py deployment, assumed to be on a cloud native platform (e.g., Kubernetes, OpenShift), that lacks robust high availability (HA) support. In-memory queues are used in the ACA-Py instances such that when instances are terminated abruptly (no graceful shutdown), messages could be lost. cloud Internet { node agent1 as a1

Authors: Stephen Curran, Clecio Varjao Status: PROPOSED Since: 2023-03-31 Status Note: New RFC being proposed. Supersedes: None Start Date: 2023-03-31 Tags: feature Summary Some credentials include attributes that are not simple strings or numbers, such

Mediators Design 1: No Relay/Deliverer, No Controller A "no controller deployment" is viable by either setting the --auto flags, or by extending the mediation negotiation plugin to include business logic, so that there is no need for a controller. cloud Internet as ags { node agent1 as a1 node agent2 as a2 node agent3 as a3 }

Background The PEx effort is focused on the process of a verifier sending a request for a presentation message to a prover, and the prover responding with a presentation that (crytopgraphically at least) satisfies the verifier's request. The request is a DIF Presentation Exchange presentation definition, and the response is a DIF Presentation Exchange presentation submission containing one or more verifiable presentations. Those are the only two messages allowed in the flow. The WACI protocol specification's Request/Share section describes how that exchange is accomplished using that protocol with a challenge token (the request) and a callback to an HTTP endpoint for the response. Within the set of protocols that make up Aries Interop Profile (AIP) 2.0 are two messages (Out of Band and Present Proof V2) that implement this same exchange on top of a DIDComm v1 connection using DIDComm v2 message envelopes. This document details the flow, including both the messages that are sent, a summary of the internal Aries agent processing that is occuring and the callouts to the business code (in Aries terms, the "controller" for the verfier and the prover). The internal processing notes are included to provide visibility into the message and protocol handling in the Aries frameworks to simplify the business processing layer. All of the cryptographic processing, identifier resolution, and message and protocol handling is handled by the Aries framework, and the business layer deals with send requests via an HTTP API to, and receiving events from, an Aries framework. Assumptions An out-of-band (non-Aries) communication channel is available between the verifier and the prover(s) sufficient to allow the verifier to provide a URL to the prover.