W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • elf Pavlik

Introductions

  • [name]

Topics

Ownership of hackmd/@solid

  • HZ: It looks like I was removed too. Would going with private notes do?
  • HZ: Pavlik is the owner and two other chairs are admins. We discussed usefulness of it, if the content is removed after having PR.

LWS Use Cases

  • HZ: many community members submitted use cases. Much appreciated! Please start reviewing, as the LWS group is moving into a second phase of compiling requirements.
  • HZ: Last weekend I mad a push, the use cases are ready for review. The WG will start working on requirements. Everybody here, maybe except Theo, raised issues with use case.
  • eP: there are over 100 issues, what's the editor's strategy to process them.
  • HZ: That is a challenge. All use cases are qute general and similar in a sense. The difference is often related to the type of content mentioned. I created issues from 107 to 115, they are fine grained and deal with identity and authentication. I created another issue that links them all together and defines a common context. If submitted issue brings something in addition to that base contexct, only that additional part needs to be discussed. https://github.com/w3c/lws-ucs/issues/117
  • HZ: We mostly focus on identity. If you want it to be portable, the id can't be dependent on the provider.
  • CB: To which extent do you mean it shouldn't be dependent on the provider. Is it the domain name or a different sense?
  • HZ: Mostly yes. I discussed it with a couple of people already. LDP for convinience, conflates the idea of id representing identity with the address. Identity is a collection of attributes saying something about an entity. SAML, WebID profile document etc. Identifier allows to search the record and address allows you to address the record. An address is usually an ordered list of identifiers.
  • CB: How do you see the dereferencibility of identifiers? With URL you can just dereference it and get the description.
  • HZ: There are multiple levels of dereferencing things.
  • CB: I'm coming from Linked Data background. Are you advocating no to use URIs?
  • HZ: I don't want to highjack the conversation. For now we are gathering the requirements. Tim is very strong proponent of using DNS and everyone having their own domain. Personally I favor bringing your own id. For example a public key. If I attach the public key to the profile I can prove its mine. There is dereferencing… Now we are using HTTP, it depends on the domain names. What happens if you change your storage?
  • eP: If you bring your own domain you can change DNS and point it to new provider.
  • HZ: It solves portability but not transferability. If I don't depend on addresses, we can infer address from identities. Imagine that every github repository has a unique public key. It is provable no matter where it is hosted. (further comapring it to git)
  • CB: I understand that you advocate for persistent identifier. Which entity is resolving the identifier? Where is the lookup table? DNS is a similar way of looking up the address.
  • HZ: I did an experiment with Jesse with CSS. We coded the John Postel solution. DNS worked this way before. Everybody was synchronising /etc/hosts over night. I just want to stop conflating the identity with an address. We can introduce resolution process without specifying what it is.
  • eP: I want to understand what DID doesn't provide as already existing standard.
  • HZ: LWS will adopt DIDs, given status of WebID draft. I don't know if any DID method will work. DID key for example doesn't specify how to get the key. We should not use HTTP but another type of URL.
  • HZ: The reason is portability and transferability.
  • CB: To the notion of portability. Has there been already a consensus of what the portability should be? Does the portability of data includes the identifiers or the dataset itself. I recall one comment, where you ask how URIs would be redirected between storage providers. For that reason I'm not sure if portability is expected to include identifiers.
  • HZ: Jesse already implemented John Postel's stuff with CSS. We defined our own URI scheme solid:. Redirection didn't depend on the previous storage provider. There has to be infrastructure for that, equivalent of /etc/hosts doesn't scale.
  • HZ: Tim is a advocate of slim servers and fat clients. What if we remove something in the middle and talk about infrastructure serfices. Besides IdP, DNS what else would be needed? How do we make Solid future proof. To in the future allow plugging in other mechanisms.
  • HZ: I see git as a very good examples. If git owner is deciding where the repo is hosted… To me it is the model I have in mind.
  • MdJ: Are we still talking about use cases or specific solutions for the portability. Regarding migrating pods, there is a contradiction in the premise of using linked data and migrate pods. One of the possible solutions is solid migrator developed by MUSE as a proposal.
  • HZ: The idea is not to migrate but how to preserve addresses.
  • MdJ: Yes, not just getting a new pod but how to preserve links. We chose URLs which might be a wrong starting point.
  • MdJ: Going back to use cases list. We were talking about identity, applications and storage. 5 years ago there was a lot talk about portability on the solid website. There was a promise of migrating between apps and using the same data. It is only possible if we can identify applications.
  • HZ: I agree
  • MdJ: So the 117 list is incomplete.
  • HZ: The second set of batches, refer to may use cases which refer to having service together with data and local-first. We will need to discuss it how to access storage locally.
  • HZ: The
  • eP: …
  • HZ: There are not use cases. I think there should be use cases. Would it be 'as a spec author'
  • eP: I would see it 'as a standard body'
  • HZ: Infrastructure should hide all that evolution.
  • eP: … about avareage users managing private keys
  • HZ: … there are innovations with hardware and private keys.

Wallet API

  • MdJ: I would like to learn more about the Wallet API, how it interacts with access grants, and whether we see the wallet API as potentially compatible with SAI and maybe even ACP
  • HZ: We think it will evolve. We moved to OWF to make it better. It was done initially in Inrupt but we have not interest in releasing a product. Let's bring it up again.
  • HZ: There are two schools of tought. One to have data locally on the phone. Other one is to have it backed up in the cloud. We think Solid is an ideal candidate to have that data safe in the cloud.
  • MdJ: I'm working with Dutch universities on combining wallets with Solid.

Clarifying acl:origin

Select a repo