Agenda Karim - report from RWOT Snorre's question about whether we want endpoints Rodolfo - mediator demo

368 - move tracing?: Suggest we merge PR #372 and then close the issue. 351 - didcomm:// scheme: got proposal from Timo; added comments to ticket; added PR #373 326 - apu and apv in ECDH-ES: awaiting PR from Baha 321 - Yolan's big review: resolved by PR #377 315 - Crystals-Kyber ex: defer 311 - multiple presentations: defer 298 - P521: PR #374 from Daniel 285 - terminology section: suggest we defer. TOIP has tooling that can generate glossaries, and we can publish one as a separate artifact. Having it in the spec is a nice-to-have that we can skip. 269 - refactor kid/skid: defer or "won't fix" (we have wordsmithed this section to some extent already): PR #375 from Daniel 263 - media type rewords: suggest close as "wont fix"

Peer DIDs were invented before KERI was formally described. Once KERI came along, it became clear that KERI is a more sweeping generalization of the same principles that informed most of the peer DID design. Peer DIDs embody the main principles that KERI advocates, but use just a subset of KERI's features. This means that we can redefine peer DIDs in terms of KERI. The benefits of doing so are: The peer DID spec can be much, much simpler. Peer DIDs get an upgrade path. KERI gets added momentum. Communities can come together. The DID method landscape can consolidate. This document is a first cut at redefining peer DIDs this way.

thanks to Sam Curren for suggesting this Meetings are expensive, especially if we are only interested or needed for a small slice of them. Async interactions are cheaper and more flexible. We love the way we can tolerate remote work and different timezones. However, they lack the focus and rhythm of traditional get-togethers. They're easy to ignore or procrastinate. We have scheduling conflicts. Sometimes, these are big disadvantages. An UnSync Meeting is a hybrid that delivers most of the benefits of both. The name is intended to suggest something that's NOT a traditional synchronous interaction, but that DOES sync people up. :-) How They Work

This file has been moved to a PR agains the DIDComm User Group repo

The purpose of this doc is to describe what we mean when we say "write a library that provides static peer DID support." Key Assumptions The peer DID method spec is relatively complete, but not all parts of it hang together well. I (Daniel) am the principal author of the method, and I can get changes to the method spec approved. So if we find ourselves stuck on a problem with the spec, I can solve it quickly. "Static peer DID support" means support for the features described as "Layer 2a" and "Layer 2b" by the peer DID spec. This includes the ability to create peer DIDs and to resolve peer DIDs received from others. It does NOT include the ability to update the state of a peer DID, or to receive and act upon updates from the peer DIDs of others. Peer DIDs support arbitrary key types. However, our libraries only need to support ed25519/curve25519 keys and secp256k1 keys. The authorization section of a peer DID doc is out of scope. Hence we do not need a dependency on SGL, and we do not need to support deltas. Whatever keys are declared under verificationMethod are the ones we use for DIDComm in this version of the libs. Libraries should be very lightweight and, beyond crypto, have as few dependencies as possible. Libraries will be published using standard package manager(s) for their respective languages: pypi, npmjs, maven, crates.io, etc.

The purpose of this doc is to provide a scratch space where we can wrestle with what we'd like to see in Project Gemini's efforts to provide libraries that offer support for DIDComm. We know that implementations have to conform to the spec; what we need to decide is what mental models, algorithms, and data structures we want our libraries to use to accomplish that goal. Will they be fancy or simple, high-level or low-level? Key Assumptions The libraries that support DIDComm in Python are not going to be identical in scope, named constructs, or usage patterns to the ones for Go, Rust, JavaScript, Java, or any other language. Each library will be idiomatic and will have slightly different needs. Some may be function-oriented, others object-oriented. They won't share a single source ancestry or common release schedules. However, the supported features should be similar. We want libraries with minimal dependencies. The form factor should be standalone libraries with DIDComm features only, not heavy frameworks. We are NOT trying (directly) to help build agents -- only to implement the DIDComm spec so anybody can use DIDComm easily. Libraries will be published using standard package manager(s) for their respective languages: pypi, npmjs, maven, crates.io, etc. DIDComm depends on DIDs -- but DID resolution is a complex topic unto itself. We will keep our libraries simple by providing a DID resolution interface in each library, plus two standard implementations of that interface -- one for peer DIDs, and one for the universal resolver. Fancier impls can be plugged in, but won't be provided by the libraries. The libraries are not responsible for transmitting messages over a transport, only for preparing them to be transmitted. It must be possible to use these libraries to carry on multiple simultaneous interactions between Alice and Bob in parallel. (We'd prefer that the libraries not encourage statefulness -- but if they do, the statefulness MUST NOT constrain interactions to an artificial behavior pattern that is drastically simpler than DIDComm's supported behavior scope.)

# RFC 0xxx: Protocol Test Suite ## Summary Explain how the Aries ecosystem proves interoperability of implementations of its RFCs. ## Motivation (explain difference between interop that's subjective, and interop that's objectively measured) ## Tutorial Things we need to explain: * What is the scope of the protocol test suite? (Does it exercise encryption envelope? decorators? which protocols? Does it test credential issuance and verification?) * How normative is the protocol test suite? (