Time | Agenda Item | Lead | Notes |
5 min | | Chairs | |
5 mins | Review of Action Items from the previous meeting | Chairs | |
20 mins | Task Force Reports | TF Leads | Trust Registry TF — @Darrell O'Donnell @Drummond Reed notes that there have been an avalanche of comments on the draft ToIP Trust Registry Protocol Specification. @Darrell O'Donnell looked over the comments. We will cover that in more detail in the next agenda item.
ACDC TF — @Sam Smith @Philip Feairheller Last week the meeting had a presentation from @Kevin Dean from GS1. GS1 has many different needs for chained credentials: measurements, authorization, identifier delegation, etc. Part 2 of that meeting will be next week to map GS1's use cases into ACDC credential chaining. The GLEIF use case is now going into a public beta. They are starting to work on IETF specs. One of the first is SAIDs (Self-Addressing Identifiers): https://datatracker.ietf.org/doc/draft-ssmith-said/. Comments sought. Another is the CESR specification: https://github.com/WebOfTrust/ietf-cesr. CESR supports composability: concatenation of any type of cryptographic primitives in either binary or text format. It is truly a streaming protocol, so you can compose streams of any type and convert between text and binary, so you don't have to choose between "JSON or CBOR".
Darrell said it would be very helpful to have Sam present to the Technology Architecture TF so we can figure out where CESR and KERI fit in the stack. Sam also clarified that ACDC uses JSON Schema, so you can build anything on top of it. We then discussed privacy options. Selective disclosure can be built on top of ACDC credentials, however Sam has also developed a hidden attribute capability. This allows an ACDC credential to contain only hashes of data, which the holder can then selectively disclose only the hashes desired. For GLEIF, they have developed a transaction event log (TEL) for transactions that are fully public (the chain of GLEIF credentials). But GLEIF does have one type of credential containing personal data. So Sam has developed an XOR blinded registry to use for cryptographic accumulators.
Sam and Darrell agreed that the easier we can make it to adopt, the better. Sam agreed there are cases that need ZKP, but there are others where using blinded attributes is sufficient. Sam also pointed out that ZKPs are actually non-productive when a transaction needs to be non-repudiable, such as many regulatory use cases. AnonCreds is non-repudiable, but thus it is not true ZKP.
ACTION: @Darrell O'Donnell to attend the next ACDC Task Force meeting (Monday Dec 6th). ACTION: @Drummond Reed to send an invite to@Sam Smith to attend the Technology Architecture Task Force meeting this Thursday Dec 2 — either 8AM MT or 2PM MT.
Design Principles TF — @Drummond Reed Technology Architecture TF — @Drummond Reed |
25 mins | ToIP Trust Registry Protocol Specification comments | @Darrell O'Donnell @Drummond Reed | Review comments on the draft ToIP Trust Registry Protocol Specification. See the comment history of the Google doc (or the recording of this meeting) for the disposition of each comment. ACTION: @Drummond Reed to connect with @Antti Kettunen about populating the glossary with terms defined in the draft ToIP Trust Registry Protocol Specification. ACTION: @Darrell O'Donnell to create a GitHub repo under ToIP to begin tracking questions and issues for the draft ToIP Trust Registry Protocol Specification.
|
| | Chairs | |