Building Universal Manifest Together: Presentations, Questions and Progress
Working-group presentations are sharpening Universal Manifest's use cases and requirements. Bring a use case from your work to help shape what comes next.
Questions from working-group presentations are making Universal Manifest’s use cases and requirements more precise. Since our June video-library update, discussions across MSF and OMA3 have examined what people need to share, what they should be able to keep private, and what permission an exchange requires.
Universal Manifest proposes a shared way for people, software and services to exchange the context and permissions an interaction needs. Bringing that proposal to different groups helps reveal the requirements it must meet.
Different groups, practical questions
At the MSF 3D Assets Working Group on June 23, we presented Universal Manifest in the context of trust and provenance. The discussion examined what information should accompany an asset and how provenance relates to the tools and formats that create, change and carry it.
The MSF Infrastructure discussion on August 21 brought attention to permissions and handshaking: what a service needs to ask for, what someone chooses to share, and how to protect information outside that exchange.
On September 24, the MSF Ecosystem discussion considered identity and permissions through everyday situations, including an agent acting for someone and a service requesting personal information. Questions about purpose, retention and changing choices brought the discussion back to the people using these systems.
Alongside these presentations, the OMA3 Technical Working Group has continued reviewing Universal Manifest use cases. That detailed work asks what each participant needs to achieve and how clearly the requirements express it.
Turning discussion into progress
Consider a visitor entering an exhibition. Evidence that the visitor meets an age requirement does not, by itself, grant permission for marketing contact. The working use case states those purposes separately, along with how long information may be kept.
These distinctions give implementers concrete requirements to examine. Reviewing who needs what, for which purpose, and under whose authority helps us identify gaps before settling technical choices. The presentations introduce the proposal; the questions and detailed reviews help improve it.
Bring a use case from your work
Bring one encounter your system needs to support: a person visiting a service, an agent acting for someone, or an asset moving between tools. Describe who takes part, what each side needs to know, what permission is required, and where today’s process falls short.
Your constraints can help shape the requirements while they are still developing. Read the existing use cases and check OMA3’s participation details to bring your experience into the review.