owned this note   changed 2 months ago  
Published Linked with GitHub

Stable LWS Locators

Identity, Data, and Metadata Portability

  • terms:

    • AAA — Authentication, Authorization, and Accounting
    • Identity provider — manages the subscriber’s primary authentication credentials
    • Storage provider — serves, e.g., HTTP requests for (user's) resources
    • Owner/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.
<#MyProfile> rdf:type solid:ProfileDocument .

Resource

  • Regular data resources used by the owner of <#MyProfile>.
<#MyClinicalRecord> rdf:type med:Record ;
   med:diagnosis med:craaaazy .

Resource Metadata

  • Lists of folks with access to e.g. <#MyId>.
<#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?
    ​​<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

          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?
Select a repo