Aries provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions
Key components of an Aries solution are: agents, DID communications, protocols.
- Multiple Aries Agent SDKs
- Only Python fully ready, documented
- GO, dotNet both available
- Other SDKs not happening
- Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo
m Hyperledger Indy
https://github.com/hyperledger/aries-cloudagent-python/blob/master/docs/GettingStartedAriesDev/IndyBasics.md
https://github.com/hyperledger/aries
https://www.youtube.com/watch?v=dj_VyVyWuu8&t=1s
- Hyperledger Aries allows trusted online peer-to-peer interactions based on decentralized identities and verifiable credentials.
- Aries includes a protocol definition, tools, and reference implementations.
- The Aries protocol supports identities rooted in a variety of distributed ledgers or blockchains.
- This approach to identity is often called Self Sovereign Identity (SSI).
Key components of an Aries solution are:
Aries is a young project that is maturing quickly. As such, be warned that the project documentation and links may get out of out-of-date. If you find there is something missing, please connect with the community on the Aries Hyperledger Rocketchat Channel. And of course, pull requests are always welcome to fix things that are confusing!
If you are entirely new to the decentralized identity space and the Hyperledger projects there is a Linux Foundation edX course on decentralized identity and Hyperledger Indy, Aries and Ursa. Start there! A companion developers edX course is planned for "early" 2020.
If you know about decentralized identity and verifiable credentials and want to get started building applications on top of Aries (and Indy), the most consistently maintained guide for new developers is the one included in the Aries Cloud Agent Python (ACApy):
The Aries project contains a number of repos, which can be grouped into some important categories.
Developers who want to solve business problems (vs. contributing directly to Aries) should start with an Aries agent framework. Agent-based applications are created by adding application-specific code that control the Aries agent.
There are several Aries general purpose agent frameworks that are ready to go out of the box.
- Aries Cloud Agent - Python (ACA-Py) is suitable for all non-mobile agent applications and has production deployments. ACA-Py and a controller run together, communicating across an HTTP interface. Your controller can be written in any language and ACA-Py embeds the Indy-SDK.
- Aries Framework - .NET can be used for building mobile (via Xamarin) and server-side agents and has production deployments. The controller for an aries-framework-dotnet app can be written in any language supporting embedding the framework as a library in the controller. The framework embeds the Indy-SDK.
- Aries Static Agent - Python is a configurable agent that does not use persistent storage.
There are several other frameworks that are currently under active development, including:
- Aries Framework - Go is a pure golang framework that provides a similar architecture to ACA-Py, exposing an HTTP interface for it's companion controller. The framework does not currently embed the Indy SDK and work on supporting a golnag-based verifiable credentials implementation is in progress.
- aries-sdk-ruby
- aries-framework-javascript
The Aries project provides some useful tools for developing agents and testing that they are compatible with other agents in the ecosystem.
Coming Soon There are also a set of shared open source libraries that provide C-callable APIs that can be used by agents and frameworks to support the Aries protocols.
- Aries Key Management: Functions for managing keys, including storage plugins.
- Aries Verifiable Data Registry Interface: An interface for verifying data agianst an underlying ledger.
- Aries Util: Utility functions for Aries communication, such as message packing.
While these are in development, the ACA-Py and .NET frameworks embed the Indy-SDK, while the Go framework is building the capabilities in golang.
If you want to understand the theory and the open standards that these agents and frameworks implement, then you should refer to the Aries protocol documents:
If you want to start build decentralized identity capabilities around Indy, you should use the existing Aries Agent frameworks described above that embed the Indy SDK. If you are already using the Indy SDK to build a decentralized identity solution, you can keep using it knowing that it will continue to be maintained. If and when the Indy SDK is fully or partially deprecated, a transition process will be communicated.
In such a deployment there are always two components - a configured agent itself, and a controller that injects into that agent the business rules for the particular agent instance (see diagram).
Conceptual Network of Aries Agents in Context
https://github.com/hyperledger/aries-cloudagent-python/blob/master/docs/GettingStartedAriesDev/AriesBigPicture.md
Sovrin network is shown but this could be another Indy network
The agents in the picture shares many attributes:
- They have some sort of storage for keys and other data related to their role as an agent
- They interact with other agents using secure. peer-to-peer messaging protocols
- They have some associated mechanism to provide "business rules" to control the behaviour of the agent
- That is often a person for phone, tablet, laptop, etc. based agents
- That is often backend enterprise systems for enterprise agents
- Business rules for cloud agents are often about the routing of messages to and from edge agents
While there can be many other agent setups, the picture above shows the most common ones - edge agents for people, edge agents for organizations and cloud agents for routing messages (although cloud agents could be edge agents. Sigh...). A significant emerging use case missing from that picture are agents embedded within/associated with IoT devices. In the common IoT case, IoT device agents are just variants of other edge agents, connected to the rest of the ecosystem through a cloud agent. All the same principles apply.
Misleading in the picture is that (almost) all agents connect directly to the Ledger network. In this picture it's the Sovrin ledger, but that could be any Indy network (e.g. set of nodes running indy-node software) and in future, ledgers from other providers. That implies most agents embed the ledger SDK (e.g. indy-sdk) and makes calls to the ledger SDK to interact with the ledger and other SDK controlled resources (e.g. secure storage). Thus, unlike what is implied in the picture, edge agents (commonly) do not call a cloud agent to interact with the ledger - they do it directly. Super small IoT devices are an instance of an exception to that - lacking compute/storage resources and/or connectivity, they might communicate with a cloud agent that would communicate with the ledger.
While current Aries agents currently only support Indy-based ledgers, the intention is to add support for other ledgers.
The (most common) purpose of cloud agents is to enable secure and privacy preserving routing of messages between edge agents. Rather than messages going directly from edge agent to edge agent (which is often impossible - for example sending to a mobile agent), messages sent from edge agent to edge agent are routed through a sequence of cloud agents. Some of those cloud agents might be controlled by the sender, some by the receiver and others might be gateways owned by agent vendors (called "Agencies"). In all cases, an edge agent tells routing agents "here's how to send messages to me", so a routing agent sending a message only has to know how to send a peer-to-peer message. While quite complicated, the protocols used by the agents largely take care of this complexity, and most developers don't have to know much about it.
InfoQ article on Aries
https://www.infoq.com/news/2019/05/Hyperledger-Aries-Identity/
In a recent blog post, the Hyperledger project announced their 13th project called Hyperledger Aries, which provides an interoperable identity management toolkit that enables creating, transmitting and storing verifiable digital certificates. Using this toolkit, organizations can support secure, interoperable peer-to-peer messaging across different distributed ledger technologies (DLT).
Identity management continues to be one of the most important and challenging aspects of building DLT applications. Tykn, a digital identity management organization, classifies the problem as:
Most of the current identity management systems are weak and outdated. Paper-based systems are at risk of loss, destruction or fraud. Digital systems, if centralized, are honeypots of personal data for hackers. Constantly subject to leaks and breaches. Since 2017 alone, more than 600 million personal details – such as addresses or credit card numbers – have been hacked, leaked or breached from organizations. Identities need to be portable and verifiable everywhere, any time, and digitization can enable that. But being digital is not enough. Identities also need to be private and secure.
Hyperledger Aries plans to address some of these identity challenges through the use of verifiable digital credentials. Nathan George, cto Sovrin Foundation and Hyperledger Aries sponsor, explains:
Identity is commonly cited as one of the most promising use-cases for distributed ledger technology. Initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials will benefit from a shared, reusable, interoperable tool kit.
The Hyperledger project has been very clear that Aries is not a blockchain, nor is it an application. The toolkit has roots from both the Hyperledger Indy, from a resolver implementation perspective, and Hyperledger Ursa, which it has leveraged some cryptographic functionality from. However, Hyperledger Aries does provide a blockchain interface layer, known as a resolver that allows for the creation and signing of blockchain transactions. It also includes secure storage that acts as a cryptographic wallet where secrets can be stored and includes an implementation of a Decentralized Key Management System (DKMS) which is currently being incubated in Hyperledger Indy.
Aries includes an encrypted messaging system for off-ledger interactions between clients across different transport protocols and the ability to abstract higher level protocols through API-based secure messaging interactions.
Additional technology from another Hyperledger project, Hyperledger Ursa, is being leveraged within Aries. An implementation of Zero Knowledge Proof (ZKP) capable W3C verifiable credentials using the ZKP primitives is being included. ZKP-capable W3C verifiable credentials can represent the same knowledge that may be found in physical credentials, such as a driver’s license, passport or health insurance card, but includes privacy-preserving and data-minimization features.
Image source: https://www.hyperledger.org/blog/2019/05/14/announcing-hyperledger-aries,-infrastructure-supporting-interoperable-identity-solutions
While the generic Aries resolver interface will support Hyperledger Indy, it is flexible that developers can build a pluggable method using another decentralized identifier (DID) method resolver based upon Hyperledger Fabric or Ethereum.
Moving forward, the project is focused on enhancing identity storage and exchange capabilities. George explains:
The ultimate goal of Hyperledger Aries is to provide a dynamic set of capabilities to store and exchange data related to blockchain-based identity. These capabilities will range from the secured, secret storage of data, such as private keys, up to the capability of globally accessible data that can be viewed and accessed by anyone. An example of such support is the creation of a secure storage solution similar to the wallet available in Hyperledger Indy today.
Developers can learn more about Hyperledger Aries by visiting their wiki or joining the Hyperledger chat channel.
https://github.com/hyperledger/aries-cloudagent-python/tree/master/docs/GettingStartedAriesDev
This guide is to get you from (pretty much) zero to developing code for issuing (and verifying) credentials with your own Aries agent. On the way, you'll look at Hyperledger Indy and how it works, find out about the architecture and components of an Aries agent and its underlying messaging protocols. Scan the list of topics below and jump in as soon as you hit a topic you don't know.
Note that in the guidance we have here, we include not only the links to look at, but we recommend that you not look at certain material to which you might naturally gravitate. That's because the material is out of date and will take you down some unnecessary rabbit holes. Keep your eyes on the goal - developing with Indy and Aries.
https://github.com/bcgov/vc-authn-oidc
This repository is the home of a project to achieve verifiable credential based authentication using OpenID Connect.
The VCAuthn-Service has two main dependencies
- A backend database, postgres is used as the provider
- An instance of ACA-Py for handling the interactions with verifiable credentials
To run the OIDC-Controller in debug, first you must run these dependencies with the following command
docker-compose -f ./docker/docker-compose.local-debug.yml build
docker-compose -f ./docker/docker-compose.local-debug.yml up
Following this you can either launch the VCAuthn-Service in debug via an IDE like VS Code or Visual Studio or run the following command
dotnet run ./src/VCAuthn
https://github.com/bcgov/vc-authn-oidc/blob/master/docs/README.md
authentication-oidc-verifiable-credential-from-oidc-for-aries-agent-2020.pdf
Verification Flow
this particular integration aims to provide an easy integration path that allows parties to start leveraging the power of verifiable credentials for user authentication in a non-disruptive fashion. This is achieved by extending the vastly popular OpenID Connect family of specifications.
In reference to the above diagram. A supporting OP will act as the verifier on behalf of a RP for a verifiable credentials presentation. This mode of integration means RP's that already support OIDC only have to extend their support to making VC-AuthN based OIDC requests to a supported OP, rather than adding full support for verifiable credential interactions directly. The holder will use an IdentityWallet (IW) mobile app to store their verifiable credentials and manage presentation requests from verifiers.
https://openid.net/specs/openid-connect-core-1_0.html#Overview
https://stackoverflow.com/questions/57588346/oidc-cloud-agent-vs-siop-edge-agent
This answer assumes you know a fair bit about Indy, Aries, DIDs, verifiable credentials and OIDC. I know a lot about the first set of topics, but am not an expert on OIDC, so bear with me :-).
SIOP (Self-Issued OpendID Connection Provider) is a standard extension to OIDC, althought it is not implemented by most of the IAM vendors. When implemented, an OIDC Relying Party (RP) can use the SIOP protocol to directly contact a DID holder (say, an Identity Wallet) and get back a verified identifier using a standard OIDC protocol. A project (Interop Project) at the Decentralized Identity Foundation (DIF) is using SIOP to implement DID Authentication. There is an article about the approach here - https://medium.com/decentralized-identity/using-openid-connect-with-decentralized-identifiers-24733f6fa636. The interop project can be found here: https://github.com/decentralized-identity/interop-project
An alternative that we are working on at British Columbia (BC) Gov with Mattr Global (New Zealand) uses an OIDC cloud agent to implement a standard OIDC Identity Provider (OP) that talks OIDC on one side, and uses a DID protocol (DIDComm) on the other side to talk to a Verifiable Credential holder (again, an Identity Wallet). We're using a standard OIDC client library on one side to receive authorization requests from the RP, and then (using HTTP) to send requests to an Aries Agent (based on Indy) to interact with the Identity Wallet (itself an Aries Agent - or at least one that talks DIDComm) to request a proof, and to receive back the proof. The OIDC library then takes the data from the claims, maps them into an OIDC token to return to the RP. The implmentation assumes that the RP and IdP (combination of OIDC client library and Aries Agent) are operated by the organization requesting the authorization.
This link has a picture of what the two implementation look like: https://github.com/decentralized-identity/interop-project/issues/16#issuecomment-521130043
Note that the SIOP implementation is about verifying DIDs, while the OIDC Agent implementation is focused on verifiying claims from verifiable credentials (VC). We are thinking that a degenerative case of the VC authorization is proof of a DID, so the OIDC Agent approach may be able to handle both cases.
There is a good discussion/summary of the pros and cons of the approaches here: https://github.com/decentralized-identity/interop-project/issues/9
The work we (BC Gov and Mattr Global) is here: https://github.com/bcgov/vc-authn-oidc
answered Aug 22 '19 at 16:58
Article - Using OpenId Connect with DIDs
https://medium.com/decentralized-identity/using-openid-connect-with-decentralized-identifiers-24733f6fa636
related github project
https://github.com/decentralized-identity/interoperability
Continious technical demonstration of interoperability between DID Methods, Wallets, Agents, Encrypted Data Vaults, and Verifiable Credentials. https://identity.foundation/interoper…
https://github.com/decentralized-identity/interoperability/blob/master/docs/InteropProject.png
https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof
verification-present-proof-protocol-aries-std-2020.pdf
The present proof protocol consists of these messages:
- Propose Proof - Prover to Verifier (optional)
- Request Proof - Verifier to Prover
- Present Proof - Prover to Verifier
In addition, the ack and problem-report messages are adopted into the protocol for confirmation and error handling.
This protocol is about the messages to support the presentation of verifiable claims, not about the specifics of particular verifiable presentation mechanisms. This is challenging since at the time of writing this version of the protocol, there is only one supported verifiable presentation mechanism(Hyperledger Indy). DIDComm attachments are deliberately used in messages to try to make this protocol agnostic to the specific verifiable presentation mechanism payloads. Links are provided in the message data element descriptions to details of specific verifiable presentation implementation data structures.
Choreography ( from draw.io )
Last week, we began a conversation about Trust over IP. Lucy has reached out to the Evernym team for a presentation, which will happen at our next innovation call on Wednesday, June 10th at 9 am PST - be on the lookout for invitation.
This week, we will discuss what is missing from the work we have been doing so far and what events need to be captured.
Wallets. What wallet capabilities do we want to achieve with having the wallet in the vehicle?
Create a clear set of questions and goals:
How is interoperability achieved for identity wallets? Interchange standards
What security standards are used/built on?
Execution environment - where have they been deployed?
How is hardware key encryption done?
What capability should be on a wallet for VID?
What are the security, hardware and software specs needed for VID wallets?
Pricing information
Reference baseline from the wallet companies
Holding VCs in wallets including identity
What platforms are conceptually supported by these wallets?
Autonomously engage in transaction through their agents
What EAL (evaluation assurance level) does the hardware wallet have?
The wallet is a private key with computational elements. The main issue is where will the wallet be located? It’s most likely going to be in the ECU (Engine control unit)/ head unit. However, the issue is that the ECU is not made by the majority of OEMs. Toyota and Honda do not make their own. Having a tier 1 provide the changes on the head unit is a 3 year process before we see it in the next model of the car.
Part of the design process should ensure that the wallet is still functional if there is an accident and the ECU is damaged.
One outcome would be that there is an outfit (Toyota as an example) with good software with bad hardware - Toyota could source a tier 2 wallet vendor (Riddle & Code or ZF) who will provide the software and potentially the crypto chip and they will send the package to a tier 1 (Denso) who will put it in their ECU and send it as completed assembly to Toyota. That lead time is extremely long.
If there is a yes today, these wallets will end up in cars 7 years from now. GIven this length of time, why is it required to have the wallet in the car? Cars already have the OEM certificate inside which can be encrypted. An alternative is to have it on your phone. Or designate the OEM as custodian. However, when you talk about congestion prices you need an autonomous agent inside the vehicle to make these transactions. There are also privacy reasons.
In the short term, it will most likely be a custodian approach and we will need a cloud based wallet as well. There can be hardware or hybrid model for the wallet. The wallet will need to be able to do transactions off-line. The wallet will need cloud based services for backup and recovery.
How is interoperability achieved for wallets?
DID com protocol. Interoperability at this layer is the interchange. What interchange standards apply? If we are expecting DIDs to be the medium of exchange, then the protocol (DID com) needs to be required to exchange the verifiable credentials.
Details on key management? Do you use the same public key more than once? Is there a payment capability that we need? How are the transaction audits done?
Will still need key management as you are generating multiple public keys and will never use the public key more than once. We will need to come up with some core functionalities and requirements.
In Aries, agents = wallets
Wallet = public/private key data store
Requirements for wallets:
Hold VCs (verifiable credentials) - from the manufacturer, DMV, etc - does it with some DID com capabilities. How do you get funds in and out of the wallet itself? Through transactions and payments. DID com is just messaging. The other piece that will give us interoperability is the resolve.
DID com capabilities
Data storage
public/private keys
Audit capabilities - ledger of DID com events
Payment capabilities
Security standards -
Extensibility - ability to add features/ software updates
Backup/recovery - needs to be innovated because you cannot recover what’s in a chip
Resolver
Generate proofs (ZK proofs)
Crypto wallets make sense if the owner of the funds is the vehicle. The core component is a crypto chip.
What is the difference between agents and wallets?
Wallet is the container; wallet is the hard drive
Agent is the logic to get stuff in and out of the container; agent is the operating system
Evernym can also answer questions about the wallet. See article:
Jim Mason : are these docs current for the current release ?? https://trustos.readthedocs.io/en/latest/id.html
Jorge Ordovas : This docs are related to Telefonica’s TrustOS API, but not related to TrustID (the documentation is in the GitHub repository Maria Teresa is presenting, on Hyperledger Labs)
Jorge Ordovas : https://github.com/hyperledger-labs/TrustID
Rouven Heck : The interOp Charter: https://docs.google.com/document/d/1a01GQVtZB7tDVcm9avS8zuYPHQzEEDtTOEh4Bqu-8Bs/edit
Rouven Heck : https://identity.foundation/interop/
Rouven Heck : https://github.com/decentralized-identity/interoperability
Rouven Heck : this working group meets weekly ^^
Rouven Heck : recently kicked off, so all pretty new
Jim Mason : Thanks @rouven — looks good. Aries already has done some work with OIDC for authentication to legacy systems as well
Rouven Heck : There was recently a workshop with OIDC to discuss/represent DID Auth SIOP, there is close collaboration happening: https://identity.foundation/working-groups/authentication.html
Rouven Heck : DIF has people from the Aries community part of it. Might be the same effort
Rouven Heck : similar with DIDComm - close collaboration across ecosystems
https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS172x+3T2019/course/
digital trust goal
about identity on the Internet and being able to trust the data passed to you. They are about being able to prove to others who you are and you being certain who they are
-------------
aca.pug>
stephen curran
andrew whitehead
telegram sam
wade
hardening revocation handling in acapy 5.5
deployments of credentials to orgbook
issuing credentials to humans
verifier kit ( eg tsa )
std apps for verifiable credentials ( eg tsa )
From Wade to Me: (Privately) (2:08 PM)
Regarding volumes. We BC Gov, have experience with scales in the 10 to 15 million credential area.
Also volume loading of those credentials.
andrew whitehead
record api transaction interface for Indy lib
sqlite type rust lib
prep stmts
static validations
From Wade to Me: (Privately) (2:08 PM)
Regarding volumes. We BC Gov, have experience with scales in the 10 to 15 million credential area.
Also volume loading of those credentials.
From Me to Wade: (Privately) (2:10 PM)
Thanks very much. My State is probably similar in size to bc.gov … 700K businesses to license etc
We have 1 M individual incense transactions per year
From Wade to Me: (Privately) (2:11 PM)
9,995,053 creds in BC right now.
From Me to Wade: (Privately) (2:11 PM)
excellent. that would be a good capacity for where we may get to.
From Wade to Me: (Privately) (2:12 PM)
11,209,434 for the Ontario version of OrgBook
From Stephen Klump aka 613 612 7749 to Everyone: (2:12 PM)
Work in progress: https://github.com/sklump/aries-rfcs/tree/441-present-proof-best-practices/concepts/0441-present-proof-best-practices
From Wade to Me: (Privately) (2:15 PM)
The wallet for Ontario is currently 254GB
Most of the space in the wallets is consumed by tags.
From Wade to Me: (Privately) (2:17 PM)
You need to be concerned about credential exchange records, as they can cause significant bloat if you done clean them up.
From Me to Wade: (Privately) (2:20 PM)
Do you have an email ? ( i’m jmason900@yahoo.com ). I would love to have you present at https://wiki.hyperledger.org/display/PSSIG on the work your team has done for bc.gov
sorry - you are doing this for Ontario or BC?
From Wade to Me: (Privately) (2:20 PM)
Both
We're also helping the Federal government.
From Me to Wade: (Privately) (2:21 PM)
excellent .. thanks .. let me know if you have the interest and the time .. the group would really benefit from your experi
ence
I'm in the BC DTS team with Stephen Ian, Emiliano, and Andrew.
I'm the SRE and DevOps engineer.
From Wade to Me: (Privately) (2:22 PM)
Contact info can be found here; https://github.com/WadeBarnes
From Wade to Me: (Privately) (2:23 PM)
As far as presentations go Stephen is much better at that than I.
From Me to Wade: (Privately) (2:25 PM)
thanks … I will twist his arm “really hard” then .. thanks very much
You can also connect to us on http://chat.hyperledger.org/
swcurran and WadeBarnes
swcurran and WadeBarnes
Here is a list of some of our opensource work; https://github.com/search?q=topic%3Averifiable-organizations-network
From Wade to Me: (Privately) (2:30 PM)
which includes the hyperledger contributions.
From Wade to Me: (Privately) (2:31 PM)
This one in particular would be of interest to you; https://github.com/bcgov/issuer-kit
This PoC includes personal digital identity bits; https://vonx.io/safeentry/
OpenShift (k8s) configurations and links to code for that can be found here; https://github.com/bcgov/essential-services-delivery
remote web hooks api for call backs
use api key for wallet, transaction reference on call back
api key in controller - controller can check in the path to grep
This is the issue: https://github.com/hyperledger/aries-cloudagent-python/issues/578
Ian>>
working on multi-tenancy
add mediator for wallets
mediator support presentation coming
iiw session on cam, kiva for pssig ???
https://www.hyperledger.org/blog/2019/05/01/an-overview-of-self-sovereign-identity-the-use-case-at-the-core-of-hyperledger-indy
-----------------
aries.m200520>
a> aries test harness review
3 agents - holder, issuer, malicious
a> find aries tutorials to test
a> stellar - create a custom token
daniel hardman
rfc for chained credentials
issued and then delegated thru 3rd parties
works w w3c credentials ( vs indy )
vc -verifiable credentials
i> how long are the trust chains required?
if a trusted entity has other entity relations how are they trusted?
g> smaller trust lists, p2p trust links
ex> employment credential from acme uses a govt credential for name id
eg passport as a cited sources for credentials
cite sources for authority and ..
c> a credential has an embedded schema to avoid external lookups
field - provenance proofs -- chain of data
i> can issue chained credentials but verifiers need to support chains
i> need better revocation tracking on vc
r> need to back trace the vc chain for delegation
r> proof of employment credential and name came from govt passport
q> WHAT exactly is the proof ??? an id, a string = passport or ???
q> how do you handle changing uids from issuers ??
q> does each step have a nonce in the presentation of the chain?
c> bank did kyc on customer - bank saves the verification
has the nonce and presentation of it
historical provenance
proves there was past authority
zkp revocations ?
next step
has this credential been revoked since then?
liveness check on revocation
i> what was disclosed at point in time upstream is available downstream
so use limited zkp where feasible
q> how are parties in a chain private from one another?
based on zkp, encryption
parties in chain could be private from each other
ex> look at car rental use case flow thru
early vs late anonymous to valet -- risky
https://www.youtube.com/watch?v=UalIJmbkbUU
sample code block
Related articles
