Meeting minutes
Introductions and announcements
laurens: 4 Topics - lets start with introductions
bart: Bart Beulens, from VITO, Belgium
… involved with Solid since 2019
… involved in a project as setting us up as a Solid Pod provider in Flanders
… organized the 2nd Solid Symposium in Leuven
… we have a lot of work going on in the Solid-related domains, so we joined!
laurens: Any announcements?
… if not, we can move on to the next agenda item
Action Items
laurens: Action Items!
… overview of closed issues? Any update hadrian?
hadrian: there is! #1 was closed as duplicate
<laurens> w3c/
<gb> CLOSED Action 1 reach out on LWS mailing list (on acoburn) due 2024-11-25
<gb> Pull Request 149 UC for portable storage and basic sharing (by hzbarcea)
hadrian: I did not want to close @@@ issues before the PR is merged
Use cases and requirements: presentation and Q&A
laurens: any further action items?
… lets move on
… @hardian, do you have a more extensive announcement here? e.g. about the note?
<gb> @hardian
laurens: I reviewed the issues and opened a PR on local data
hadrian: @@@1 discussion on algorithms that run in the server / close to the data
… many services, e.g. query, run close to the server - these may require to access data directly
… and in that case these services need to recognise ACLs etc
… I believe this is out of scope for the WG
… but this is relevant for the discussion around portability
… we had some previous conversations on running algorithms close to the data
… when I finish my PRs most of the related issues can be closed
… also related: Identity / identifier
<acoburn> gibsonf1: be sure to use q plus (rather than plus q) to add yourself to the queue
laurens: to summarise, you have been working on @@@2, and you raise question to direct access to data ...
… do we see a requirement on a query mechanism, e.g. SPARQL queries?
hadrian: yes, this fits into this category
laurens: there I think we should make a distinction between MUST and SHOULD - to distinguish between core elements and extensibility
hadrian: I could make an argument that nothing is really required (??)
<Zakim> gibsonf, you wanted to mention about how to handle query access control - triple-level uri's and to talk about Linked Data as an approach and query security - triple-level resources
gibsonf1: On the whole issue, how do you do access control with a query/algorithm.
… a though: are we doing actually Linked Data or only documents with triples as ACRs?
… if we do LD, then we need access control on a triple-level
… since its not a particular easy thing to do, triple-level access control, we maybe need two types of LWS, one for docs and one for LD.
… The thing I fear, if it is just files, you cannot do alot with the files at the end of the day compared to LD.
… what do you think about the idea of having both types?
hadrian: I can give my personal opinion: At same point, in your graph you will link videos or files. By necessity, there needs to be some form of a file/raw data storage.
… I'd argue that you can do a lot already with that
… what I see in industry, if you have data in database, you somehow have to make it accessible to other parties (including semantics), so I'd say that using LD is also a necessity
gibsonf1: So, one clarification on why would a necessary to use SQL database, when other technologies already solve the problems that these introduce
hadrian: The databases exist, and are massively adopted.
… at scale, when sharing data, the semantics of the stored data needs to be shared as well
… so, LD will be a necessity, I think
… I don't think that we would avoid LD
<Zakim> acoburn, you wanted to talk about how we start with use cases, then requirements, and then solutions
acoburn: I just wanted to mention that it is maybe not a binary question, and there is a lot of room between an S3 bucket and a full triple store
… what we need is not a discussion around the implementation details but about the use cases, requirements and what to do with that
laurens: I'd be interested in a use case for triple-level access control, so please add that
ryey: I am slightly confused: Is the question about any compute close to the data, or only about LD queries?
laurens: more general, I guess
ryey: I do have an issue open for something other than query, which could be implemented as an agent running on the data - but the agent is necessary for our usecase, and the question is where the agent runs (also in terms of trust where the agent runs)
<gibsonf1> w3c/
<gb> Issue 148 [UC] Triple Level Resource (State) (by gibsonf1) [triage] [usecase]
hadrian: Interesting topic, there is also an issue by csarven, to serve @@@3 from a Pod
… the Solid Server itself is an algorithm that sits next to the data to serve it
… question is: Is it the only one?
… do we want to consider plugins?
… I can see some Solid Servers that allow customers to configure plugins like in WordPress
… but that is maybe rather a feature of an implementation
… instead of to be demanded by spec
… I agree that there is a spectrum
laurens: I like the idea of plugins
… I am unsure about this in the spec
… but we would need a discovery mechnism for that
… in the spec if we want to go for that extensible model
<ryey> +1
hadrian: discovery, yes, but again portability!
<Zakim> gibsonf, you wanted to say - maybe instead of plugins, we consider server capabilities where various capabilities have an interoperable protocol
gibsonf1: If I am understanding that a plugin is that is code that someone runs on a server?
… if so, then I am 100% against it
… I could not imagine someone writing code and then putting it into a secure server
… I dont understand how this would work
hadrian: It is a Pod that can give you data in the form that you want (content-negotiation), which could be a plugin
… it is related to capability discovery
… it is more a terminology issue at this point
csarven: I dont follow the discussion: Look at the charter, we are supposed to come up with a protocol (or something like that) but that is not requiring to define the storing mechanisms and such
… we are to define the interfaces / interaction protocol
… if something is not going to be in particular relevant to the interaction between to entities to qualify as interoperable, then it is not to be defined by us
… I think we should focus the discussion around things that are measurable to be defined.
… example: should data at rest be encrypted?
… if we can answer this question, then we would know if this is inscope of the charter
<Zakim> acoburn, you wanted to clarify measurability in terms of testability
laurens: we should only look at verifiable/testable things as a MUST
csarven: yes
acoburn: Yes, I'd agree, we need to think about what goes into the test suite
… something that we cannot test, is out of scope (e.g. encryption at rest)
tallted: It is actually not a requirement for a spec that something is testable. Some things, specs just mandate.
… that aside, encryption at rest can be tested in a various ways
… if we are really defining a protocol, if we do that at all - not sure about that yet
… you could have a test suite that runs on the server, and see what happens on the storage/device
… so you can detect if the system/server really uses encryption-at-rest (EAR)
… it is important to note that we do not have to test everything that is in scope
csarven: Agreed, this is a more precise statement.
… that said, we cannot get away with that all the time
… at least there needs to be sufficient number of measurable / testable things to show that they are interop'ing
<acoburn> +1 to what csarven said
csarven: I think we should be careful here
Discussion: server-to-server authentication
laurens: last week, we discussed around authentication in the browser
… currently, if we look at the Solid OIDC, there is no real server-to-server mechanisms
<acoburn> ActivityPub and HTTP Signatures
laurens: and there are other mechanisms
… so I'd be interested in the groups opinions
acoburn: as a note: this link is a CG draft, it does show prior art. It is referencing a previous version of HTTP sigs
… it will give you an idea about the possiblities
<Zakim> bendm, you wanted to say CSS implemented clientside credentials out of (research) project necessity
<bendm> CSS implemented clientside credentials out of (research) project necessity
bendm: CSS implements clientside credentials
… just FYI
<laurens> uvdsl: In our internal systems we use WebID+TLS
<laurens> ... which was one of the first authn mechanisms for Solid
<laurens> ... basically mTLS authentication without using the certificate chain
<laurens> ... but based on the WebID profile document for validation.
<bendm> CSS reference: https://
<laurens> acoburn: You are not validating the certificate chain. Are you using some root CA with that?
<laurens> uvdsl: We do not and have not considered that.
<laurens> ... as far as I remember we have disabled the validation of the chain in Tomcat and introduced our own validation logic
<laurens> acoburn: An alternative could be JWK as the serialization of your public key, you can use the x5c property to add a certificate chain
<laurens> s?
<Zakim> gibsonf, you wanted to say what is being used now (TrinPod)
<dmitriz> (fwiw, I think HTTP Signatures RFC solves the server-to-server auth use case nicely)
gibsonf1: We have a strange approach: our servers ip address, serial number, encryption - all servers use the same encryption library
<Zakim> acoburn, you wanted to mention client credentials impl experience
acoburn: At Inrupt, we also implemented client credentials - it definitely works but it is cumbersome as it requires an additional pre-registration step
laurens: from our perspective is also that we were not happy with client credentials as a solution
<dmitriz> the other nice thing about HTTP Sig is that it plays nicely with DIDs
laurens: I'd be intersted in a keypair based solution
<Zakim> csarven, you wanted to ask about UCs re S2S
csarven: HTTP sigs are interesting
… I am interested in the actual use cases, that hint at why we need S2S authentication
… activityPub is one example, and it makes since there
… but it is not specified how that works
… it is more ad-hoc in reality
… but again, I am more interested in the use cases that really demand this
<dmitriz> @csarven -- you can think of Backup as a general S2S use case
<gb> @csarven
<laurens> uvdsl: I am not familiar with HttpSig as an authentication mechanism
<laurens> ... I would be interested to hear what it offers over mTLS
<csarven> dmitriz: good example. then again, client can back up too =)
acoburn: mTLS is a transport layer protocol
<laurens> acoburn: mTLS is a protocol that happens at transport layer
<dmitriz> @csarven - not really, not in batch/unattended mode
acoburn: HTTP sigs will happen at the application layer
… the two can happen at tandem
… but they are fundamentally at different layers
<laurens> uvdsl: Both do authentication one at transport and one at application level?
<csarven> dmitriz: Well, client can ask a backup to be created and send a notification to another server to go grab it. Not saying that S2S shouldn't happen in that case but if it demands that approach then I'd like ot hear something stronger.
acoburn: because mTLS validates the particular server endpoint
… with HTTP sigs you validate the message
<dmitriz> @csarven -- well so lets follow that use case. 'a client can send a notification to another server to go grab it' -- and how would the server grab it? It needs to authenticate itself, right. hence the need for S2S auth
<gb> @csarven
acoburn: and you exchange public keys and certificates
<Zakim> gibsonf, you wanted to say why server to server
acoburn: and not
<csarven> dmitriz: but that server that needs to grab it, is not acting as a "server"! It is acting as a "client"
gibsonf1: We have all our servers, and they syncronise
<acoburn> server-to-server use case
<gb> Issue 39 [UC] Server Side authentication and Data Access (by jeswr) [triage] [usecase]
gibsonf1: that is, re server-to-server use cases
<dmitriz> @csarven - ah, i see the confusion. we're mixing two different meanings of 'client'
<dmitriz> @csarven - feel free to substitute in your mind S2S auth -> "auth that does not involve a browser url redirect"
laurens: what we have seen as a use case: sometimes an entity wants to access some data (e.g. an organisation accessing a user's Solid Pod) and that is while the user is offline.
<Zakim> hadrian, you wanted to ask pchampin if the draft ucs is published on a regular basis, so that I could use links to <dfn>s in the draft in issues
hadrian: is the draft ucs is published regularly, so we could use links?
pchampin: I do not think we have a decision
hadrian: I'd like to link to definitions
laurens: lets put the resolution of that on the agenda of the next meeting
… thanks for joining, see you next week
<gibsonf1> +1