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.

Federations or shared registries

• Resource URI is mapped to a service address by the federation metadata

  • URI authority acts like a name server
    
    https://a.example.com/7e8f3d25-6c92-4a1b-8e5d-9f3a7c5b4d2e

https://b.example.com/7e8f3d25-6c92-4a1b-8e5d-9f3a7c5b4d2e

https://c.example.com/a1b2c3d4-e5f6-47g8-h9i0-j1k2l3m4n5o6
    

  • the URI path determines the resource location

  • extra point of failure (PoF), e.g., purl.org

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?