Summary:
| Excerpt |
|---|
|
...
(7AM Los Angeles, 10AM New York, 3PM London, 4PM CET, 18H Moscow)
| Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct.  |
|---|
Attendees
- Sam Curren (Indicio) <sam@indicio.tech>
- Warren Gallagher (AffinitiQuest) <warren@affinitiquest.io>
- Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>
Welcome / Introductions
Announcements
...
- 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:
Other Business
Future Topics
...