https://w3ds-docs.github.io/w3ds-docs/docs/requirements/Recent content in Requirements on W3DS TRL7 DocumentationHugoen-ushttps://w3ds-docs.github.io/w3ds-docs/docs/requirements/technical-requirements/Mon, 01 Jan 0001 00:00:00 +0000https://w3ds-docs.github.io/w3ds-docs/docs/requirements/technical-requirements/<h1 id="technical-requirements">Technical Requirements<a class="anchor" href="#technical-requirements">#</a></h1> <blockquote class='book-hint '> <p>⚠️ This document is not a requirements specification.<br> It contains a mix of ideas, research topics, and design considerations.<br> It needs to be decomposed into requirements, architecture, and research artifacts.</p> </blockquote><h2 id="foundational">Foundational<a class="anchor" href="#foundational">#</a></h2> <ul> <li>Solidify our definitions of main terminology</li> <li>If we keep &ldquo;groups&rdquo; as first class citizen and not implementation detail, describe their mechanics</li> <li>Provide guidelines and best practices for creating post-platforms/w3-adapters, to encourage more interoperable ecosystem <ul> <li>the usage of eNames</li> <li>reusing and creating ontologies</li> <li>handling authorization</li> <li>aggregation and caching</li> </ul> </li> <li>Make all above documentation AI friendly. This way it can answer questions and check consistency with our codebase</li> <li>Describe methods for managing pseudonymous profiles</li> <li>Explain how anonymous transactions will work. And in general explain PET in the ecosystem.</li> <li>Explain the limits of security and privacy in currently deployed eVaults</li> <li>Capacity planning for eVaults and infrastructure services</li> </ul> <h2 id="functional">Functional<a class="anchor" href="#functional">#</a></h2> <h3 id="evault">eVault<a class="anchor" href="#evault">#</a></h3> <ul> <li>Carefully define and generalize the model of controlling eName (forms of binding)</li> <li>Support deduplication of eNames and eVaults, perhaps with eMover</li> <li>Evaluate the meta-envelopes model (flat) for complex topologies of data</li> <li>Strictly adhere to declared ontology within a single meta-envelope</li> <li>Explore dynamic GraphQL queries/mutation from schemas</li> <li>Research ways to map (without loss of performance) knowledge graph inference and formalisms such as SPARQL to meta-envelopes</li> <li>Provide rigorous authorization layer <ul> <li>Define levels of access to resource for users/groups/platforms. Roughly like <a href="https://solidproject.org/TR/wac">wac</a></li> <li>Would be nice to be able to inherit ACLs, but we don&rsquo;t have explicit hierarchies</li> <li>Consider opt-in vs. opt-out systems</li> <li>Can we support attribute based or fully semantic ACLs?</li> <li>If not, we should define useful categories: e.g., reputation driven authorization, authenticated users, certified platforms</li> </ul> </li> <li>Improve platform&rsquo;s authentication with eVaults <a href="https://w3ds-docs.github.io/w3ds-docs/docs/requirements/platform-auth/">details</a></li> <li>Involve linked data specialists to aid with ontology mapping (for adapters) and alignment in general</li> <li>Explain how two mostly similar ontologies can be reconciled at the schema and eVault level</li> <li>Add basic semantic transformation engine to eVault, allowing to have Big-Bang sweeps of semantic updates, e.g., after merging two popular ontologies.</li> <li>Consider encryption of data at rest: with external keys, keys on eVault, keys in hardware</li> <li>Initiate research for &ldquo;rootless&rdquo; provisioners &ndash; where eVault provider has no backdoor to eVault envelopes</li> <li>Rethink &ldquo;audit&rdquo; logs <ul> <li>recorded data (platform, user, timestamp, hash of payload)</li> <li>how is non repudiation guaranteed?</li> <li>how can we guarantee log integrity?</li> <li>how we are actually going to provide the logs to auditors?</li> <li>can audits preserve privacy?</li> </ul> </li> </ul> <h3 id="infrastructural-platforms">Infrastructural platforms<a class="anchor" href="#infrastructural-platforms">#</a></h3> <ul> <li>eVault provisioners <ul> <li>seemlessly support single eVault on VM (1st model) and shared tenancy (current model)</li> </ul> </li> <li>registries &ndash; resolvers of eNames to eVault protocol endpoints <ul> <li>ideally, the data is stored on platform&rsquo;s eVault and can be</li> </ul> </li> <li>ontology collections &ndash; resolvers of eNames to schemas</li> <li>awareness endpoints &ndash; fan-out for awareness messages <ul> <li>awareness must respect ACLs and any other authorization mechanisms we may have</li> </ul> </li> <li>caching layer (ora CDN-like) <ul> <li>must respect ACLs</li> </ul> </li> </ul> <p>Note: it is likely that big eVault providers are going to serve all above as well</p>https://w3ds-docs.github.io/w3ds-docs/docs/requirements/platform-auth/Mon, 01 Jan 0001 00:00:00 +0000https://w3ds-docs.github.io/w3ds-docs/docs/requirements/platform-auth/<h1 id="platformadapterpost-platform-authentication">Platform/Adapter/Post-Platform Authentication<a class="anchor" href="#platformadapterpost-platform-authentication">#</a></h1> <blockquote class='book-hint '> <p>⚠️ This document is not a requirements specification.<br> It contains a mix of ideas, research topics, and design considerations.<br> It needs to be decomposed into requirements, architecture, and research artifacts.</p> </blockquote><h2 id="problem-statement">Problem statement<a class="anchor" href="#problem-statement">#</a></h2> <p>We need to align the authentication model and expirience of a post-platform with that of a person. A method is required to allow a user &ldquo;broswing&rdquo; to the frontend of a platform to verify its authenticity; a system that provides correlation (if not identical) between that identity and the ename/evault of the paltform; a mechanism that allows platforms to prove to evaults they access their autenticity. For all the above cases we want to support both one-time transactions and long lived &ldquo;sessions&rdquo;.</p>