Andor 

Review on Trust Registry -related topics from IIW.

• Reviewing Andor's overview on IIW:
  https://docs.google.com/document/d/1dYbTi-qNnx-7fJQM1BCPJ2vn2KtDCcqA7YjFE6SU2uk/edit
• 7 TR related sessions
• Agreement on the need of TR's, but varying viewpoints and differences in maturity of thinking
• Not all TR working groups are even naming themselves a trust registry. Similar goals and development points, but naming different.
• Chat (mathieu ): "One comment from someone from GS1 was “why can’t we simply use VCs instead of a TR”"
• Alex from Cheqd presented DID Resource linking.
• Marine corps reputation system seemed interesting.
• Michael Herman presented Web7.0 (also available here: https://youtu.be/214-aKNBCAU

Key takeaways regarding TR's:

• Much more presenting own solutions and discussions on engagement. Much networking focused
• Savita & Lucy spoke about hierarchical model built in UN, which would be interesting to go deeper in future sessions

  • Cosanna (chat): "This is the summary Lucy sent:

    Digital Trust Infrastructure for Discovery and Validation (Regi-TRUST https://www.sparkblue.org/Regi-TRUST) at UNDP built on the EU ESSIF TRAIN (https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft/) 

    This project evolved from the COVID project at the Linux Foundation. 

    An article from Lucy: https://www.lfph.io/2022/04/19/how-does-a-border-control-officer-know-if-a-covid-certificate-is-valid-gccn/"

• EU seems to be moving back toward X.509 (unconfirmed)

The current requirements document is becoming a bit hard to follow. We're creating a more structured document to guide TR Requirements work. 

https://docs.google.com/document/d/1p8rapJlVQ09CGR6vLeadQq-_sj_icfWfcyTPJMjC18Y/edit

We discussed approaches and experiences in how should we use requirements statements (MUST, SHOULD, MAY).

Darrell O'Donnell

"A MUST will get done.
A SHOULD may get done.
A MAY will likely not get done."

Sam Curren 
"We might consider reducing the scope of our work to eliminate MAYs and SHOULDs."

Neil Thomson 

"If there are sub markets which has variations where SHOULDs become MUSTs, then that is a separate standard/mechanism/protocol

Mirrors the Trust Spanning Protocol approach - there is a base (root Musts), which can be built on, for variations."