The Glossary Group has decided to focus on the meaning of service endpoints for DIDs. We are looking for community input on our current definitions of 5 different endpoints and

I sent an email to this group a while back where I was discussing how to link PIURIs in DIDComm (the special URIs used to identify protocols and message types) with a URL namespace under

Today we discussed whether we can use an initial-state matrix parameter on DIDs to pass info in a DIDComm message in the JSON field where a recipient is identified (where a simple DID would sometimes

Oops, missed to notice the daylight savings change. Thanks

Yes, but it shifted due to daylight savings changes over the weekend in the US.

Is there a meeting today?

Daniel Hardman has submitted our first content PR related to Routing. Here is the link to read the PR

That's an excellent question. My opinion is that DIDComm TLS should be part of *a* spec produced by this WG, but I think it would be a different spec than the one about DIDComm Messaging that's

Hi, I am looking into the transports section of the spec. For the case of transmitting the message using TLS based protocols, is the definition of DID-TLS part of this spec?

As discussed on today's call...

Daniel Hardman has written up a suggested outline, and we'll be discussing that on Monday's call. Please read it prior to the

I won't die on this hill, but given we are currently calling DID Messaging, DIDComm, I'm predicting our tendency is going to be to continue with that :) which will make clarification of what DIDComm

+1 to both of Sam's notes from me. For sure on the DIDComm, and starting with a single repo for now and we can evolve if it becomes obvious that was a bad choice.

On including the -comm suffix: I ack the worry, but I think we can manage it by preferring it always, such as DIDComm-TLS or DIDComm Multicast. Calling it DIDComm also cleanly differentiates it from

Hi, The rationale for potentially dropping the comm part and calling it DID messaging, mainly came from the thought of what we as a working group will tend to shorten the name of this work to? If it

I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging. I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept). Not every project

I'd like to offer this doc as a starting place for an outline for a DIDComm messaging spec. https://docs.google.com/document/d/1Hn4ofl7ubRy22Xv1Yj1g77OkJWlWkDh88O3Od-yp8Cg/edit I put sample content in

Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am

+1 for DIDComm-messaging +1 for separate repos — they can be associated to each other with GitHub Topics (tags) ________________________________ Sent: Wednesday, January 15, 2020 11:46 To:

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue didcomm-messaging is the frontrunner then. Orie proposed the monorepo alternative. Any last opinions