Talk slides template

## Stable LWS Locators ### Identity, Data, and Metadata Portability --- * [terms](https://w3c.github.io/lws-ucs/spec/#glossary): * **AAA** — [Authentication](https://w3c.github.io/lws-ucs/spec/#dfn-authentication), [Authorization](https://w3c.github.io/lws-ucs/spec/#dfn-authorization), and Accounting * [**Identity provider**](https://w3c.github.io/lws-ucs/spec/#dfn-identity-provider) — manages the subscriber’s primary authentication credentials * [**Storage provider**](https://w3c.github.io/lws-ucs/spec/#dfn-storage-provider) — serves, e.g., HTTP requests for (user's) resources * [**Owner**](https://w3c.github.io/lws-ucs/spec/#dfn-owner)/[**User**](https://w3c.github.io/lws-ucs/spec/#dfn-user) — rights to and responsibility for a resource \ provider agreement * **Portability** * Establishing identity or resources while using Provider A *   that can be used when *   the relationship with Provider A has been severed. * problem statement — litany of Identity and Storage Provider failure modes * what's portable? Identity, Resource, Resource Metadata * how do we make stuff portable: Tech, effort, and one-time vs. run-time costs  slides: https://hackmd.io/@ericP/SybL2qT6Jl#/ src: https://hackmd.io/udygiH3STieqHniB38h1ig?both#/1 --- ## Problem Statement * LWS has a general goal of "portability". * This means we can fire providers we don't like. * What does this mean concretely? ---- ## Fire a Provider Owner/User shifts to a new Provider with acceptable one-time and run-time inconvenience / cost. * commercial pressure on hosts to be good netizens. * mechanisms and protocols when: * Providers cooperate * Providers disappear * Providers turn evil ---- ## Providers might cooperate * In DNS-land, registrars are obligated to hand over transfered domain names. * Likewise, well-behaved providers would be expected to provide * hand-off handshakes * perpetual forwarding ---- ## Providers might disappear * Providers might fail to pay their electric bills purl.org was assumed too important to fail until it disappeared for 15 months. ---- ## Providers might turn evil * Without bonding or scary IANA police, a registrar could just re-sell all of their registered domains. * Likewise, malfeasant providers might engage in rapacious practices for their LWS customers. --- ## What's portable? * What can the user expect to move without hassle? * Identity * Resource * Resource Metadata ---- ## Identity * The resource used as a user's avatar or identifier for contacting or sharing. ``` turtle <#MyProfile> rdf:type solid:ProfileDocument . ``` ---- ## Resource * Regular data resources used by the owner of `<#MyProfile>`. ``` turtle <#MyClinicalRecord> rdf:type med:Record ; med:diagnosis med:craaaazy . ``` ---- ## Resource Metadata * Lists of folks with access to e.g. `<#MyId>`. ``` turtle <#MyAcl> rdf:type solid:ACL ; wac:resource <#MyClinicalRecord> ; wac:principle <#MyProfile> ; wac:permission wac:Write . ``` --- ## Technology vs. one-time/run-time costs? * How do we handle this "dereferencing" without introducing critical points of failure? * Adding a level of indirection doesn't help if the redirector (e.g., a registry) is fallible. * DNS * Shared ledger * Federation / Registries ---- ## DNS for LWS * Conventional SOLID uses DNS, e.g., `uu3.org` * Centralized — IANA and well-known root name servers. * Scale to 9B people ✕ *n* identities, permutations. * Most users do not control a DNS sub-domain and cannot therefore point it elsewhere * Constallations of people can share DNS but what happens when, e.g., People/Eric wants to leave uu3.org? ```turtle <http://uu3.org/People/Eric#MyId> rdf:type solid:Id . ``` ---- ## Shared ledger * Some DID tech leans on, e.g., Ethereum shared ledgers. ```turtle @@EXAMPLE!! ``` ---- ## Federations or shared registries * Resource URI is mapped to a service address by the federation metadata * URI authority acts like a name server <code>https://a.example.com/7e8f3d25-6c92-4a1b-8e5d-9f3a7c5b4d2e</code> <code>https://b.example.com/7e8f3d25-6c92-4a1b-8e5d-9f3a7c5b4d2e</code> <code>https://c.example.com/a1b2c3d4-e5f6-47g8-h9i0-j1k2l3m4n5o6</code> * the URI path determines the resource location * extra point of failure (PoF), e.g., `purl.org` ---           DNS | locators |   -- | -- | -- **IPs** | IP addrs in URLs | brittle **hosts** | `/etc/hosts` | manual **IANA** | DNS registrars | commercial | |           **LWS** | **locators** |   **DNS** | domain name IDs/resources | scaling issues **sovereign** | `.well-known/ids` | manual **LWS-ANA** | `w3id.org/ids` | new PoF **DID** | ledger/hashtable/digest | new PoF --- # Next steps * What tech provide reasonable solutions now? tomorrow? * Who do we trust to persist? * ... Analyze tech/trade-offs * How hard do **we** want to work?