| ToIP Technology Architecture Specification Review Topics |
| Discussion of progress on the working draft of the ToIP Technology Architecture Specification. Links to all the relevant documents and diagrams: APAC mtg discussion on Spec, and next steps - see the "Discussion, Next Steps" at the end of the meeting minutes, below. |
| 15 mins | Issue Capture & Resolution | Chairs (Darrell) | - Discuss how we will capture information.
- GitHub Issues - preferred method
- EMAIL - IPR Concerns (content only allows members only) - we have EXISTING METHODS
- GitHub - versioned PDFs?
"About not being able to accept contribution from non members - what's the end outcome desired from "public review" then?
Great Question - if we are at PUBLIC REVIEW (we are NOT). DUBLIN - this is an announcement of the need for a broader ToIP Community to review, add. Additional: - drive interest
- OUTCOME:
- Drive member and non-member input OR
- member and "just-joined members" in order to comment/submit issue.
- NON Member Agreement - protects on IPR issue.
- EasyCLA - https://github.com/communitybridge/easycla
PARKED FOR NOW - Non-verifiable credentials "We still don't have a use case for dealing with non-verifiable credentials (or an example of useful non-verifiable credentials)." Neil
|
| 15 mins | Next Steps (APAC Discussion) | See the APAC attendee list | Given that the content of the top-level Tech Arch Spec is approaching its "first complete draft" state, some discussion was held on the next steps, which may be pursued in parallel: - Tech Arch Spec - continued comments and refining in GitHub, with a small number of authors, with comments directed on completing the first full draft to be presented on Sept 14 in Dublin, plus identifying larger issues to be addressed in the second draft.
- Whilst having the "issue" in GitHub is useful, ideally the details would include the section wording, diagrams etc., so that the issue can be read independently and not have to go back to the spec. Is this going to be copied through into the placeholder issues?
- Use Cases - review the Tech Arch Spec use cases and identify gaps and use case topics which require that one or more specific use cases be created with an eye to addressing:
- 2 or 3 "80/20" use cases
- 7 + use cases to stress the architecture (e.g., unexpected revocations of VCsnotification of VC revocation, secure messaging, registries, etc.)
It is suggested that each Use Case be captured (in detail) in separate documents, which may contain variations or related sub-use cases. Discussion on the impact on the Tech Arch Spec will first be discussed in the Use Case document and any conclusions on the impact on the Arch Spec will be rolled up after closure on the Use Case definition. - Component and non-Component Detailed Specifications (Services, Features, Capabilities - e.g. commercial model and value exchange) - essentially the next level of details on the Tech Architecture will be to detail the components defined in the Tech Arch Spec and specific detailed topics that are identified from the Component and overall Arch Spec that need attention in some detail
- Additional roles in managing the Tech Arch "Document Set" to include:
- A Tech Arch Spec issue, comment screener and manager (mostly about GitHub) - details TBD, but to at least include asking for more details on unclear issues and comments, consolidating issues and comments and generally managing the resolution of issues and comments with the authors. It is expected that resolving the issues will be discussed with the entire Tech Arch contributors group on Thursday NA/EU and APAC meetings
- A document set project manager, with the role of coordinating cross-document feedback and coordinating reviews and release decision points (including managing the issues to be resolved to pass a given release date.
|