Key Points

1. Multiple Aries Agent SDKs
2. Only Python fully ready, documented
3. GO, dotNet both available
4. Other SDKs not happening

References

Key Concepts

Indy Identity Networks for SSI

m Hyperledger Indy

https://github.com/hyperledger/aries-cloudagent-python/blob/master/docs/GettingStartedAriesDev/IndyBasics.md

Aries Concepts 

https://github.com/hyperledger/aries

1. Hyperledger Aries allows trusted online peer-to-peer interactions based on decentralized identities and verifiable credentials.
2. Aries includes a protocol definition, tools, and reference implementations.
3. The Aries protocol supports identities rooted in a variety of distributed ledgers or blockchains.
4. This approach to identity is often called Self Sovereign Identity (SSI).

Key components of an Aries solution are:

• agents,
• DID communications,
• protocols
• and key management

Getting Started

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):

Repos

The Aries project contains a number of repos, which can be grouped into some important categories.

Aries Agent Frameworks

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

Development Tools and Test Suites

The Aries project provides some useful tools for developing agents and testing that they are compatible with other agents in the ecosystem.

• aries-toolbox
• aries-protocol-test-suite

Shared Libraries

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.

Protocols

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:

• aries-rfcs

Use Aries to build identity solutions on Indy DLT

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.

Aries Architecture Diagram

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.

Aries Resources 

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.

Aries Python Agent SDK Getting Started Guide ( none for GO yet )

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.

• I've heard of Indy, but I don't know the basics
• I know about Indy, but what is Aries?
• Demos - Business Level
• Aries Agents in Context: The Big Picture
• Aries Internals - Deployment Components
• An overview of Aries messaging
• Demos - Aries Developer
• To Do: Establishing a connection between Aries Agents
• To Do: Issuing an Indy credential: From Issuer to Holder/Prover
• To Do: Presenting an Indy credential: From Holder/Prover to Verifier
• To Do: Next steps: Creating your own Aries Agent
• What should I work on? Options for Aries/Indy Developers
• Deeper Dive: DIDcomm Messages
• Deeper Dive: DIDcomm Message Routing and Encryption
• Deeper Dive: Routing Example
• To Do: Deeper Dive: Running and Connecting to an Indy Network
• Steps and APIs to support credential revocation with Aries agent

JWS - Json Web Signature

https://datatracker.ietf.org/doc/html/rfc7515

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based [RFC7159] data structures. The JWS cryptographic mechanisms provide integrity protection for an arbitrary sequence of octets. See Section 10.5 for a discussion on the differences between digital signatures and MACs.

Two closely related serializations for JWSs are defined. The JWS Compact Serialization is a compact, URL-safe representation intended for space-constrained environments such as HTTP Authorization headers and URI query parameters. The JWS JSON Serialization represents JWSs as JSON objects and enables multiple signatures and/or MACs to be applied to the same content. Both share the same cryptographic underpinnings.

Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) [JWE] specification. Names defined by this specification are short because a core goal is for the resulting representations to be compact.

DIDComm and DIDComm Messaging

https://medium.com/datev-techblog/didcomm-didcomm-messaging-3e10fbf12bb8

DIDComm amp DIDComm Messaging.pdf

• The DID Exchange Protocol exchanges messages to establish a connection between two parties. Part of what's exchanged is a DID Doc. The DID Doc is more like data than it is like an ordinary message, since it has meaning at rest and outside the protocol.

Data can be "attached" to DIDComm messages in 3 ways:

1. Inlining
2. Embedding
3. Appending

• Appended attachments are the most flexible but also the hardest to run through semantically sophisticated processing.
• A protocol that needs to pass an arbitrary collection of artifacts without strong knowledge of their semantics might find this helpful, as in the example mentioned above, where scheduling a venue causes various human-usable payloads to be delivered.

Attachment IDs

The @id field within an attachment descriptor is used to refer unambiguously to an appended (or less ideally, embedded) attachment, and works like an HTML anchor. It is resolved relative to the root @id of the message and only has to be unique within a message.

This indirection offers several benefits:

• The same attachment may be referenced at more than one place in the schema, without duplicating the content.
• The message may now include any number of attachments besides the 3 that are required, and mingle them freely with the others. (In our example, perhaps the student wants to add side and overhead shots of each work of art, not just front views).
• Attachments may now have formal semantics, instead of requiring human intelligence to handle. (How many times have we written emails with multiple attachments, and added verbiage like, "My photo of the door is attached as image1.jpeg; my photo of the damaged trunk is attached as image2.jpeg"?)

Content formats

base64url

This content encoding is an obvious choice for any content different than JSON. You can embed content of any type using this method.

json

If you are embedding an attachment that is JSON, you can embed it directly in JSON format to make access easier, by replacing data.base64 with data.json, where the value assigned to data.json is the attached content:

links

All examples discussed so far include an attachment by value--that is, the attachment's bytes are directly inlined in the message in some way. This is a useful mode of data delivery, but it is not the only mode.

Another way that attachment data can be incorporated is by reference. For example, you can link to the content on a web server by replacing data.base64 or data.json with data.links in an attachment descriptor:

This makes it possible to send brief descriptors of attachments and to make the downloading of the heavy content optional (or parallelizable) for the recipient.

The links field is plural (an array) to allow multiple locations to be offered for the same content. This allows an agent to fetch attachments using whichever mechanism(s) are best suited to its individual needs and capabilities.

The set of supported URI types in an attachment link is limited to:

• HTTP
• HTTPS

Signing Attachments

In some cases it may be desirable to sign an attachment in addition to or instead of signing the message as a whole. Consider a home-buying protocol; the home inspection needs to be signed even when it is removed from a messaging flow. Attachments may also be signed by a party separate from the sender of the message, or using a different signing key when the sender is performing key rotation.

Embedded and appended attachments support signatures by the addition of a data.jws field containing a signature in JWS (RFC 7515) format with Detached Content. The payload of the JWS is the raw bytes of the attachment, appropriately base64url-encoded per JWS rules. If these raw bytes are incorporated by value in the DIDComm message, they are already base64url-encoded in data.base64 and are thus directly substitutable for the suppressed data.jws.payload field; if they are externally referenced, then the bytes must be fetched via the URI in data.links and base64url-encoded before the JWS can be fully reconstituted

{
"@type": "https://didcomm.org/xhomebuy/1.0/home_insp",
"inspection_date": "2020-03-25",
"inspection_address": "123 Villa de Las Fuentes, Toledo, Spain",
"comment": "Here's that report you asked for.",
"report~attach": {
"mime-type": "application/pdf",
"filename": "Garcia-inspection-March-25.pdf",
"data": {
"base64": "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ... (bytes omitted to shorten)",
"jws": {
// payload: ..., <-- omitted: refer to base64 content when validating
"header": {
"kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th"
},
"protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)",
"signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)"
}   }    }
}

Here, the JWS structure inlines a public key value in did:key format within the unprotected header's kid field. It may also use a DID URL to reference a key within a resolvable DIDDoc. Supported DID URLs should specify a timestamp and/or version for the containing document.

The JWS protected header consists of at least the following parameter indicating an Edwards curve digital signature:

{
  "alg": "EdDSA"
}

Security Implications

Attachments are a notorious vector for malware and mischief with email. For this reason, agents that support attachments MUST perform input validation on attachments, and MUST NOT invoke risky actions on attachments until such validation has been performed. The status of input validation with respect to attachment data MUST be reflected in the Message Trust Context associated with the data's message.

Privacy Implications

When attachments are inlined, they enjoy the same security and transmission guarantees as all agent communication. However, given the right context, a large inlined attachment may be recognizable by its size, even if it is carefully encrypted.

If attachment content is fetched from an external source, then new complications arise. The security guarantees may change. Data streamed from a CDN may be observable in flight. URIs may be correlating. Content may not be immutable or tamper-resistant.

However, these issues are not necessarily a problem. If a DIDComm message wants to attach a 4 GB ISO file of a linux distribution, it may be perfectly fine to do so in the clear. Downloading it is unlikely to introduce strong correlation, encryption is unnecessary, and the torrent itself prevents malicious modification.

Attachment Descriptor Structure

• @id: A JSON-LD construct that uniquely identifies attached content within the scope of a given message. Recommended on appended attachment descriptors. Possible but generally unused on embedded attachment descriptors. Never required if no references to the attachment exist; if omitted, then there is no way to refer to the attachment later in the thread, in error messages, and so forth. Because @id is used to compose URIs, it is recommended that this name be brief and avoid spaces and other characters that require URI escaping.

• description: An optional human-readable description of the content.

• filename: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and mime-type is not, the extension on the filename may be used to infer a MIME type.

• mime-type: Describes the MIME type of the attached content. Optional but recommended.

• lastmod_time: A hint about when the content in this attachment was last modified.

• byte_count: Optional, and mostly relevant when content is included by reference instead of by value. Lets the receiver guess how expensive it will be, in time, bandwidth, and storage, to fully fetch the attachment.

• data: A JSON object that gives access to the actual content of the attachment. Contains the following subfields:

  • jws: A JSON Web Signature over the content of the attachment. Optional.

  • sha256: The hash of the content. Optional. Used as an integrity check if content is inlined. if content is only referenced, then including this field makes the content tamper-evident. This may be redundant, if the content is stored in an inherently immutable container like content-addressable storage. This may also be undesirable, if dynamic content at a specified link is beneficial. Including a hash without including a way to fetch the content via link is a form of proof of existence.

  • links: A list of zero or more locations at which the content may be fetched. Optional.

  • base64: Base64url-encoded data, when representing arbitrary content inline instead of via links. Optional.

  • json: Directly embedded JSON data, when representing content inline instead of via links, and when the content is natively conveyable as JSON. Optional.

Attaching other data to DIDComm Messages

https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#links

DIDComm messages use a structured format with a defined schema and a small inventory of scalar data types (string, number, date, etc). However, it will be quite common for messages to supplement formalized exchange with arbitrary data--images, documents, or types of media not yet invented.

We need a way to "attach" such content to DIDComm messages. This method must be flexible, powerful, and usable without requiring new schema updates for every dynamic variation.

JSON-LD spec for Linked Data

https://w3c.github.io/json-ld-syntax/#interpreting-json-as-json-ld

Using OIDC Authentication with a DID

Verifiable Credential Authentication with OpenID Connect (VC-AuthN OIDC)

https://github.com/bcgov/vc-authn-oidc

This repository is the home of a project to achieve verifiable credential based authentication using OpenID Connect.

Run in Debug Mode

The VCAuthn-Service has two main dependencies

1. A backend database, postgres is used as the provider
2. 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

Quick Demo using VON network

You will need an instance of von-network running in Docker

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.

Reference OpenId Protocol

https://openid.net/specs/openid-connect-core-1_0.html#Overview

Stackoverflow notes

https://stackoverflow.com/questions/57588346/oidc-cloud-agent-vs-siop-edge-agent

answered Aug 22 '19 at 16:58

Stephen Curran

• Thanks, Stephen. I have a question when you talk about SIOP at the beginning and you say: "..and get back a verified identifier using a standard OIDC protocol". My understanding of the DID Auth is that implement the authentication in two steps: 1) by validating the signatures 2) verification of the DID with the DID registry. So when you say that the wallet sends back a verified identifies, is the wallet performing those two steps I mentioned before? It does not make sense to me to ask the Issuer for the ownership verification but ask to the blockchain (let say DID Registry). Thanks! – MarcosF8 Aug 23 '19 at 8:11
• I was doing these Microsoft labs ( didproject.azurewebsites.net/docs/overview.html) for DID (mainly Lab 4 - Authenticate DIDs) that use DID-Auth-Jose library for the wallet, it supposes to be SIOP, indeed debugging everything I was able to see that the wallet respond with the verifiable information (self-issued) but then when this response arrives at the RP, the library (did-auth-jose) makes a request to the DID Registry to verify the ownership of the DID. – MarcosF8 Aug 23 '19 at 8:34

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

RFC - Present Proof Protocol for Verification Request

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 )

MOBI questions on digital wallets

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:
 

CHAPI and DIDComm protocol

Fnality uses CHAPI for Web-based comm

CHAPI overview

https://iiw.idcommons.net/101_Session:_Verifiable_Credential_Handler_(CHAPI)_and_DIDComm

The CHAPI protocol allows your digital wallet to receive Verifiable Credentials from an independent third-party issuer - or present Verifiable Credentials to an independent third-party verifier - in a way that establishes trust and preserves privacy.

CHAPI is an open protocol designed to solve the “NASCAR Problem” - too often, users are presented with a fixed set of options for authentication with third-party sites. The CHAPI protocol provides mediation between any CHAPI-enabled web application and a third-party site. Just register your web app with your browser, and off you go!

CHAPI browser plugin handles credential verification requests

A Credential Handler is an event handler for credential request and storage events. Web app developers can use CHAPI to provide their users with Credential Handlers that run in the browser. These Credential Handlers can respond when users visit other websites that present, request, or store Verifiable Credentials.

https://chapi.io/developers/wallets

CHAPI integrates easily into digital wallet software, allowing your wallet to receive and present Verifiable Credentials to/from third party sites:

https://chapi.io/developers/issuers

CHAPI integrates easily into issuer websites, allowing your site to issue Verifiable Credentials and present them for storage in the recipient’s digital wallet:

https://chapi.io/developers/verifiers

CHAPI integrates easily into verifier websites, allowing your site to request Verifiable Credentials presentations from a user’s digital wallet

CHAPI and DIDComm blog post

https://iiw.idcommons.net/101_Session:_Verifiable_Credential_Handler_(CHAPI)_and_DIDComm

CHAPI 101 General: Connectivity between issuer, holder, and verifier

CHAPI“Dumb pipe”, open the communication channelCHAPI solves for the browser security modelProblem statementHow do you enable communication between App and web browser?How do you enable communication between different tabs in a web browser?SolutionEnable two websites to communicate between each other in a web browserBrowser can create real time pipeline between two browser tabs (client to client edge communication)

CHAPI allows to move data between two websites without leaving the machine

CHAPI doesn’t care about the content of the pipes Has a path that can grow into “WRAPI”—Web Request API—that lets any two websites talk privately via the browser

Question about REST API - there is not one in CHAPI by itself

But in the DHS (US Department of Homeland Security) intro project the HTTP APIs and CHAPI APIs are both in use and therefore may seem intertwined

DIDCOMM 101

Q&A - Some requests for more explicit definitions:

From the charter of the DIDComm WG at DIF: “Produce one or more high-quality specs that embody a method (“DIDComm”) for secure, private and (where
 applicable) authenticated message-based communication, where trust is rooted in DIDs and depends on the messages 
themselves, not on the external properties of the transport(s) used. The method must be usable over many means of
 transport, including those that are asynchronous and simplex, and ones that do not necessarily use the internet. It
 must support routing and relay through untrusted intermediaries, not just point-to-point delivery. In addition to the 
communication and protocols described above, the protocols for exchanging DIDs/keys to bootstrap such
 communication are within scope. These protocols can be the foundation of higher-level protocols such as credential
 exchange and higher-level authentication protocols.”

DIDComm in layman’s terms: http://www.windley.com/archives/2019/06/did_messaging_a_batphone_for_everyone.shtml

From Geovane Fedrecheski and Oliver Terbu, in the chat: “DIDComm is a standard way to exchange DID-aware encrypted messages, regardless of transport (e.g., unlike TLS, which is limited to TCP)
- a set of subprotocols and related messages, such as those used for credentials exchange”

Other Q&A

Sam Curren: explicit ACKs allowed (but not forced at this level), threading (see RFC [1])

The fact that CHAPI is named CHAPI is misleading, because its not just about VC exchange

Manu explained that the name Credential Handler API is so called because the browser vendors called their API the “Credential API”.

Potential Value Opportunities

Potential Challenges

Aries coordination with other identity systems: DIF, TrustID etc

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

Candidate Solutions

Old EDX Indy, Aries course LFS 272x

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

Aries Meetings

m201028 - aries agent updates and BC.gov info

-------------
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

m200520 - review rfc verifiable credentials chains

-----------------
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

Evernym video on Future of Authentication

https://www.youtube.com/watch?v=UalIJmbkbUU

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles