Goals Simplify page Accomodate tables for richer presentations based on proof templates Try to incorporate changes that come with v2 protocols and DIF/W3C formats ==The bigger todo will be the design of the exchange record details pages as well the action pages== Sections

The BPA allows handle documents and (verified) credentials based on schemas. Currently, mostly Indy Schemas are supported. One exception is the Organizational Profile which is defined by a JSON-LD context. When adding a new document to the wallet you can select from the configured schemas. Schemas can be registered either during configuration or during runtime. Static configuration Example of the configuration of a bank acount schema in the application.yml. schemas:

Proof templates allow to store and reference templates for proofs/presentation requests. Proposed flow for policy builder UI Give the proof template a name Specify if revocation should be checked Select schema Auto Complete/Dropdown from configured schemas

Goal Evaluate integration of OPA as an ACA-py plugin to automate processes based on exchangable policies/business rules. The whole process that has been automated is the following: We have two agents with public DIDs Manual start using Swagger: Agent A DIDX Request to Agent B Agent B accepts request automatically (OPA Decision) Agent B automatically requests proof according to template managed as OPA data. We use an unrestricted request for the name attribute Agent A fullfills request based on OPA data

Problem Statement Hotel requests personal information from business traveler's basis Id and business information from her corporate Id. The proof request for the corporate Id has to be open ended (not restricted to a particular credential definition or issuer did) since there are many possible businesses. Hence, we need to decide to accept a proof after getting more information about the issuer. Concepts Tagging/Classification Allow to classify connections. Connections can be classified manually or automatically based on a defined policy. Issuer has to be a "verified organization"

Motivation Organizations, i.e. legal entities, play a vital role in an SSI ecosystem. In most cases organizations will take the role of an issuer and verifier of credentials, but will also hold credentials themselves. We assume that in almost all cases organizations want to have a public identity. Although an organization might need private, context-specific identities (personas) as well. In the following we want to discuss a simple mechanism to provide public information concerning an entity by advertising a public profile service in the DID document of a public DID. A good analogy for this public identity information would be a machine-readable and cryptographically-verifiable imprint. Description Since we assume that organizations require a public identity, we assume that the organization has a public DID and may be registered on a public ledger. Given a public DID an interested party is able to resolve the DID to a DID document. We suggest introducing a new service type profile that returns a (static) JSON-LD Verifiable Presentation (VP) consisting of self-attested and third-party Verifiable Credentials (VCs) that provide basic information about the entity. Ideal candidates for VCs included in the public profile would be VCs as published in commerical registers like the OrgBook or a GLEIF's vLEI. Example of a profile service included in a DID document

AnonCreds are typically bound to a holder by using a link secret and not by issuing a credential to a public DID. In order to add such a credential (or a subset of attributes) to the public profile, we suggest the following mechanism which expresses the intent: I self-attest that I have this credential with the specific attribute values, if you require a proof you can ask me using the Aries present proof protocol. Given an AnonCred based on the schema M6Mbe3qx7vB4wpZF4sBRjt:2:bank_account:1.0 with attributes iban: 456 bic: 1234 we dynamically create the following VC with an inline context generated on the fly: {

Status Quo Presentations can be requested by Credential Defintion IDs (CredDefId). The Credential Definitions are hard coded in the frontend with a list for ILL and IDunion network. In addition it is possible to enter a CredDefId manually in "Expert mode". templates: { iil: [ { credentialDefinitionId: "5mwQSWnRePrZ3oF67C4KqD:3:CL:1077:commercial register entry", label: "Commercial Registry Entry",

Motivation There are two main motivations for limiting the validity of verifiable credentials: Claims may change Credentials might get stolen Fraudulent credentials have been issued General Approaches to limit validity Expiration Attestations typically have an expiration date or a validity period.

Motivation As an operator of the user interface of the business partner agent, I want to know when a new business partner has been added when a new verified credential is added to the wallet Optionally we might also want to be notified: when a presentation has been received

Motivation The Commercial Registry Entry serves the following functions: Should demonstrate an authoritative binding of a DID to an organization Should fix the gap, that currently ACA-PY does not allow connections based on public DIDs Should demonstrate the transfer of verified (or authoritative) master data Resolutions from Sprint Planning In the last sprint planning, we defined the following approach:

Issuing an employee credential sequenceDiagram Getting a Commercial Register VC using a derived eID and the Employee Credential We assume we have a mobile SSI wallet (lissi, esatus) with a derived national ID (Bundesdruckerei). We would do this process outside of the Business Partner Agent UI, but we could start the process from a link within the Business Partner Agent UI. sequenceDiagram Bosch Officer->>Open Corporates Proxy: Go to service

As part of SSI4D, we want to demonstrate the issuance and exchange of verified bank account information. We have the scenario that Bosch has a bank account with Commerzbank and needs to communicate the bank account with its customer Daimler. Incorrect, out-dated or tampered bank account data can be costly, therefore we aim to exchange verified bank account data in form of a verifiable credential issued by the autoritative issuer - Commerzbank - and transferred via an authenticated communication channel between Bosch and Daimler. In the following we concentrate on the process of issuing the credential to Bosch Assumptions Commerzbank is represented as an ACA-Py (version? we use 0.5.3) with a public DID and role endorser on the ID Union network Commerzbank creates a schema for bank account information on the ID Union network Bosch's Business Partner Agent does not support handling of revocable credentials yet, so we might add an expiration time.