Trust Registry Requirements Document

[andorsk]

Deliverable: A tightly scoped requirements document to lead to proposals for Trust Registry work. The scope of this document is limited, to "what are the questions I need to ask the trust registry" and "what are the responses of the trust registry". There are other exploratory questions that are out of scope for this requirements document.

At the end of this deliverable, we expect to move to proposals stage where proposals will be presented to address the requirements.

[andorsk]

Started a document here: https://hackmd.io/@andorsk/BkZ0zY6Ao

[a-fox]

@andorsk I wanted to continue the discussion after today's EU meeting. This has to do with your PR, so I'm tagging it here for reference: #80

IMO, in the TR Spec work, we don't need to gather proposals of different Trust Registries. The TSPL proposals are vastly different, because in it we're dealing with very different models and more complexity. Decisions in TSPL significantly impact any ToIP implementations. Also, TSPL has already had their requirements gathered earlier, so they are now proposing different implementation models based on those requirements.

With Trust registry, we need to do different. Whereas there will be only one Trust spanning protocol that everyone uses, there will be multiple trust registries, implemented by multiple EGF's. So, our work is not about creating that single solution, but the spec for others to create that solution for themselves.

That being said, I think the proposals you speak of, can be about the requirements, scoping, or capabilities, i.e. the FEATURES of the Trust Registry. This is highly related to Neil's Trust checkpoint -thinking. TRTF is about creating a common TR spec that answers key trust questions for Ecosystems implementing ToIP stack that are common to all.

So, my proposal is that we focus on getting the proposal content (requirements) from the other work items like Trust models (e.g. PCTF Trust Registry paper), Neils' trust checkpoint work, etc.

Thoughts?

[andorsk]

@a-fox I think we are using the word "proposal" different here. The "proposal" I'm describe is basically a position around how to build a specification accordant to the requirements. There may be many ways to do this, at very fundamental levels. I.e someone may say we need a DNSSec approach whereas others may argue a swagger approach ( as has been done ). To me, ironing out the kinks can be worked out later, but the overall approach decision and how we attack the spec to meet the requirements, has a lot of room for debate.