...
(7AM Los Angeles, 10AM New York, 3PM London, 4PM CET, 18H Moscow)
Recording: 20230329 Aries Working Group Call Recording.mp4
Nessus Demo: 20230324 DIDCommv2 Nessus Demo.mp4
Warren Gallagher wanted to see messages with their respective direction
Here an attempt for this: youtube.com/watch?v=6CBAf29-HQY
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
...
- Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>
- Alexandra Walker (Indicio, PBC) <alex.walker@indicio.tech>
- Warren Gallagher (AffinitiQuest)<warren@affinitiquest.io>
- Lance Byrd (RootsID) <lance.byrd@rootsid.com>
- Bruce Conrad (Pico Labs) <bruce_conrad@byu.edu>
- Thomas Diesler (RedHat) <tdiesler@redhat.com>
- Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>
- Steve McCown (Anonyome Labs) <smccown@anonyome.com>
- Alex Andrei (RootsID) <alex.andrei@rootsid.com>
Welcome / Introductions
Announcements
- IIW - April 18-20, 2023, Mountain View, California.
- Community Plans:
- DIDComm v2 Connect-a-thon - HackMD lists the participants and live connections.
- Hyperledger AnonCreds Update and V2.0 Progress
- Community Plans:
...
- Pending Items awaiting further action
- did:peer:3
- Issue Credential Short Circuit PR
- Issue Credential 2.1 learning
- PR Review
- Issues
- 779 - cred attribute for images
- Nessus DIDComm demo - Thomas Diesler (Red Hat) - recording of the presentation, demo and discussion
- DIDComm v2.0 Playground Server: http://nessus-tech.io:9100/
- Nessus Repository: https://github.com/tdiesler/nessus-didcomm/
- Sample CLI Script:
- Example of a named object in the CLI – in this case "Airport.DID", but also used for VCs
Not Discussed, but left in the notes just because...
- DID Peer 2/3 – processing approach – is this the plan:
- Identifiers:
- Long Identifier – as defined today, entire encoded DIDDoc in identifier
- Short identifier is the first 22(?) characters of 64 character string sha256 of long identifier (or something else?)
- On receipt of a did:peer:2<identifier>, process as follows:
- Detect length of identifier — short or long (assumption: long peer:did:2 will never be less than 23(?) bytes)
- If short - resolve DID locally to get DIDDoc - on success, exit
- If short and resolution failed — error, exit
- If long
- Convert long DID to short DID - resolve DID locally to get DIDDoc - on success, exit
- If long and short DID resolution failed
- Resolve long DID locally to get DIDDoc — on success, exit
- if both short and long DID resolution fails
- If on a “create DID” step (e.g. receiving DID Exchange “request” or “response” or DIDComm 2 new protocol step)
- Extract DIDDoc from long DID, store short DID and DIDDoc, get DIDDoc — on success, exit
- If on a “create DID” step (e.g. receiving DID Exchange “request” or “response” or DIDComm 2 new protocol step)
- Otherwise — error
- Identifiers:
...