Standardize method for enumerating properties of trust, including expressions of trust beyond binary decisions Standardized method providing foundations of credential issuer and verifier trust. Support offline and near-offline evaluations via cacheable assets Avoid leaking information about trust evaluations to parties other than the one performing the evalution. Enable advice for humans making trust decisions Enable automated trust decisions. Produce relevant specifications and reference implementations. Guide decisions of interoperability profiles using these specifications. Disussed in WG

This is just a sketch to use in proposing what AIP 3.0 might look like. Note that the presence of DIDComm v2 as a referenced spec consolidates concepts that were present in a variety of Aries RFCs. The list is shorter, but no concepts have been dropped. Base Requirements RFC Type RFC/Link to RFC Version Note Spec

Authors: Timo Glastra, Sam Curren Status: PROPOSED Since: 2023-02-08 Status Note: Start Date: 2018-12-26 Tags: feature Summary The identifier part of the DID is calculated in the same way as a did:sov DID. did:legacypeer DIDs cannot be resolved without being provided a DID Document via the Aries Connections or DID Exchange Protocols.

References for both DIDComm v1 and DIDComm v2 Protocols are provided. Currently (Feb 8, 2023) Aries projects are still using DIDComm v1 protocols. DIDComm V2 and associated protocols will begin deployment over the next several months. Forward Protocol Used to send messages to a mediator for delivery to the message receipient DIDComm v1: https://github.com/hyperledger/aries-rfcs/blob/08653f21a489bf4717b54e4d7fd2d0bdfe6b4d1a/concepts/0094-cross-domain-messaging/README.md DIDComm v2: https://identity.foundation/didcomm-messaging/spec/#routing-protocol-20

Aries goals: Replace did:peer:2 no external dependancies outside the relationship complete on initial communication, capable of dropping 'extra' for efficiency initially: Non-transferrable AIDs with no witnesses Needs Service Endpoint

Basic Cryptography Warning: Not a deep cryptography discussion Sign: Using a private key, create a signature Verify: Using the corresponding public key, verify the signature. The signed data cannot be modified without invalidating the signature. Symetric Keys: one key used for both encryption and decryption, or sign and verify Asymetric Keys: two keys (one private, one public) that can be used to encrypto and decrypt, sign and verify

Stuff we agree on Functions as a root of trust within an ecosystem Managed / made available by existing(?) authorities Lots of them Uniform access is important