| Table of Contents |
|---|
Key Points
...
...
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
...
- Inlining
- Embedding
- 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:
...
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)"
} } }
}...
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
...
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
...