Define Audience for TRTF v2

[andorsk]

The goal of this issue is to define the audience for trtf v2 w.r.t. the #48 . My STRAWMAN suggestion here is the the following:

• Specification: Should be technical in nature and very specific.
  • Developers and Architects
  • Standards Bodies
• Companion Guide: Should focus on readability and clarity.
  • Developers and Architects
  • Governance bodies
  • People that want to learn more about trust registries at an ecosystem level

We can discuss more over the call.

Proposal to close this issue: A section in the README of the v2 section defining the intended audience of the deliverables, and possibly additional section within the deliverables themselves.

[andorsk]

Jan 12 Meeting:

@tim: Interested in the what's not the hows. Needs to be simple.
@darrellodonnell : Companion guide(s) <- multiple guides for different personas.
@neil: Trust Registry is an example verifiable data. What does authentication mean in context of the TR. Authentic entities and authentic data.

• who are the Persona's who a) use, b) update/create and c) are beneficiaries of TRs
  @a-fox: Pan Canadian Trust Framework: Assurance model. Bridges gap between policy makers and tech people.
  @mike: target the people who have to build ecosystems--companies (esp. large companies), organizations, and governments.
  @darrellodonnell: Personas - at minimum we have TWO - the Technical and Governance (includes Business). I think we can start there and refine over time. Answering the question: who's the authoritative issuers of the governance framework. Start with the STRAWMAN.
  @dan: two personas: (1) comments about what the code does, (2) actual code
  @tim: Government bodies. Needs to be crystal clear. Will eventually move to legislation so needs to consider policy makers.
  @Sandy: Audience should include the metaverse. Might have implications to the governance of the metaverse.
  @andorsk : need to care about unknown contexts.
  @jacques: DIACC PCF is well timed.

Action Items:

• Tim to help build the personas for governance.
• @andorsk technical personas.

[andorsk]

Early and rough STRAWMAN for technical personas

• Security teams : Need to understand how TR's impact security. They care about making a TR safe.
• Dev Ops teams : These personas care about the feature advantages of a TR.
• Process teams : Care about having clear guidelines onto how to adopt a trust registry into a flow. They care about cost/benefit.
• Support teams : Are omitted b/c support will be driven by a particular implementation
• QA Testing Teams : Are omitted b/c QA will be focused on a particular implementation
• Compliance Testing : Care that the TR fits a test suite that is repeatable and accepted.
• Application Developers: Most likely not our target, as this would add additional cognitive overhead.
• Infrastructure Developers~: They will want to implement the specifications provided.
• Engineering architects : Care about scalability of the
• Network engineers : They care about the routing and networking requirements of the TR. They want to make sure that the TR supports various network requirements, and that it is safe. They share many similar concerns with security teams.
• Solution architects : They care about understanding the entire system, and how to deploy it.

[andorsk]

From the call today: Dan: Process teams: business architects and solution architects are technical architects.

• Discussion for next week: There will be an audience section in the specification deliverable.

[andorsk]

michael: found intended audience was too broad. has to be directive in terms of which audience you are addressing and what you are trying to do for them. michael: offered to give some good examples. can help
@darrellodonnell careful about IPR issues.

[jacqueslatour]

quickly before I forget ;) a Trust Registry TR would have multiple actors and personas and tasks all working as per governance model.

Registry tasks: Create/update/delete/read registration(s)

• The goal of a registry is to manage the registrations process.

Create/update/delete: Governance model to dictate who can create/update/delete registrations.

• The TR operator could create new registrations on behalf of a registrant via ...
• A trusted third party (registrar) could create new registrations via ...
• A trusted registrant could create a new registration via ...

Read:

• TR Operator, registrars, registrants may view full/partial registrations via...
• The public may see certain attributes of the registration via ... (like whois or RDAP)

So, the actors/persona are:

• TR Operator
• Registrar (actor that is trusted by many registrants to do the registration function)
• Registrant (could be an issuer, verifier, wallet provider, another trust registry, etc... The registrant is not the entity behind a wallet)
• Public (general public to query a trust registry to enquire on status of a registration)

The spec should address the audience by these actors/personal. As a TR operator I want to... As a registrant I want to ...

[talltree]

I suggest the audience statement for the ToIP Trust Registry Protocol Specification V2 could be patterned after the one in section 4 of the ToIP Technology Architecture V1.0 Specification. I know some have said that audience statement is too broad, but I disagree, given that the usage of a protocol specification like this is potentially very, very broad.

Here's a strawman:

The audience for this specification is system architects, software developers, and registry operators who wish to design and implement a trust registry — or applications and systems that incorporate trust registry services.

The purpose of is specification is to define a trust task protocol that provides a standard mechanism for querying a trust registry in order to obtain data and/or metadata that can assist in making a trust decision.