Meeting minutes
Introductions and announcements
acoburn: any announcements?
(crickets)
Action Items
acoburn: previous hour, chairs and editors were chatting
… we went through the open issues
…
… pending pull requests have been merged
… we're moving these PRs through
… to make the repositories more manageable
… any other open action items before we go to agendum 3?
… there was some open tasks on clarifying use cases and requirements
Continued clarification of requirements
acoburn: we started with 44 reqs
… we now have 41, that's good
Requirement Service integration authentication
acoburn: we're at #29
… we're basically halfway there
jeswr: to get to something more workable, to a wide range of stakeholders, I propose we start next week forward from one part of the spec, and bring that tot the stakeholders
… reasonable place to start is personal cloud storage
… I started to reach out to stakeholders
… to see who the right other group to engage with are
… my proposal: next week, focus on access grant and access control, starting from user interfaces (?)
… today, finish on prioritization
<dmitriz> I think it might be most helpful for this group to specifically focus on the _data model_ of the access control and grant requests.
<dmitriz> because the protocols for those are already decently defined (like IETF's GNAP, w3c's VP Request, etc)
acoburn: 29 items to get through is a lot for today, we should go through as much as possible
… we want to set up jesse and eric to move on the actual protocol work
… #29 service integration authentication
… a lot on browser level, this is about auth for everything else
… bots, server-to-server, scripts
… (not issue 29, but requirement 29)
jeswr: I suggest to reframe this as serverside authentication, not have requirements for specific authentication
<Zakim> gibsonf, you wanted to ask, would definitely like this one in scope
gibsonf1: it would be great to have guidance on this, to have interop between servers
acoburn: we don't want to invent a new protocol here, but reuse existing
tallted: the title is unclear for me, phrasing should be better
acoburn: I agree
<dmitriz> the good news with this one is that it's a fairly solved space - mtls and http signatures.
eBremer: I have a PR open
Requirement Protocol binding independence
acoburn: req 28: protocol binding independence
<jeswr> +1 out of scope
acoburn: I suspect this is out of scope of this, but in scope of a separate layer that uses LWS
<kaefer3000> +1 out of scope
<uvdsl> +1
<gibsonf1> +1
acoburn: folks are broadly in consensus of that
<TallTed> perhaps "Loose Coupling of Underlying Protocols"
Requirement Trusted identity providers
acoburn: req 27 Trusted Identity Providers
… this is about a governance model
… I suspect many deployments will have this
… e.g. I have service Y, IdP Z is not allowed by Y
<dmitriz> 27 seems out of scope for the spec.
<dmitriz> +1 to leaving it to implementations.
acoburn: suspect implementations will do this any way, and we don't need to specify everything about this
jeswr: governance is a huge challenge by a lot of different people, also outside Solid, so for me, completely out of scope (although very useful)
uvdsl: I would this req 27 as follows: not about defining trust, but the requirement to support the definition of trusted identity providers
… i.e. restricting IdPs is possible at all
<dmitriz> also Identity Providers is both a vague term, and specific to individual authentication methods.
<ryey> +1 for uvdsl
acoburn: so, there needs to be a mechanism to limit the scope of systems that it trusts?
<dmitriz> for example, in Server to Server authentication, who is the identity provider? etc.
uvdsl: exact, otherwise a governance model is not possible at all, so that we technically provide the option to do it
acoburn: enterprise and commercially, that will happen regardless
<Zakim> TallTed, you wanted to note that trust is a moving target
tallted: 'that will happen regardless' is a dangerous phrasing
… trust is a moving target, changes over time
… e.g. certificate structure: root certificate compromised required a lot of reconfiguration
… at some point, you need to be able to say 'do not trust anything from this location'
… the spec should give a way to administrators to do that
ryey: I agree with Ted and Christoph
… my comment: who should be able to configure that?
acoburn: relates to layers of trust: trust at the level of the pod owner is different from the level of an operator
<Zakim> gibsonf, you wanted to ask about how an identity provider would not be trusted if identiny protocol used is sound
acoburn: if we go into this issue, we need to consider all layers
gibsonf: This could easily be abused
…
… ideally, the IdP spec is so good that we could trust everyone, but these things could be circumvented
dmitriz: I don't think this item makes sense
… IdP is only relevant in OpenID-Connect
… in other specs, there's no such notion
… this req presumes a specific authentication method
… so I think this should be out of scope
<Zakim> TallTed, you wanted to say that IdP is a term of use in current SWICG discussion of FedID and related (i.e., it's not just in OpenID)
tallted: IdP is a term of use in current SWICG discussion of FedID and related (i.e., it's not just in OpenID)
… it makes a lot of sense to have 'an identity provider'
dmitriz: It happens that FedID also comes from the context of OpenID
tallted: FedID is broader than OpenID
acoburn: maybe we can rename this? to 'trusted identity mechanisms'? something more generic
Requirements Modern authentication methods & User-centric identity management
acoburn: req 26: modern authentication methods
… this is even more related to OIDC
<dmitriz> so the challenge with this list, is that we're grouping together requirements for at least 3 specs (possibly more). 1) authentication spec, 2) authorization/access control, and 3) read/write protocol
jeswr: 26 assumes centralized identity mechanisms, 25 says we should also support self-sovereign identity mechanisms
<TallTed> links please?
<dmitriz> at _very_ least, we should tag which specs the requirement belongs to
jeswr: suggestions: support more types of authentication mechanisms, without specifying what form in the requirement
acoburn: grouping 25 and 26 makes sense
<TallTed> oh, you don't mean "merge PR #"; you mean "combine requirements # and #" (I still want links) *and titles*
acoburn: there's a similar req that has sub-options, so we could talk about the 'authentication requirement' and have centralized/self-sovereign/... options
ebremer: will try to do a PR in the background to merge
tallted: let's use titles and ids
acoburn: yes, respec is using a consistent numbering, but we shouldn't refer to the numbers
Requirement Legal basis enforcement
acoburn: that said, now, we're talking about 'Legal Basis Enforcement'
… tag access rules with legal grounds (e.g. GDPR)
jeswr: sounds like out of scope for LWS, since we see usage control out of scope
<ryey> +1 for jesse
ryey: I agree with Jesse, and - there might be different ways to specify this, not mature yet, so hard to do at this stage
dmitriz: it seems like we're dealing with different specs: authentication, authorization, ReadWrite protocol
… can we tag/group requirements?
acoburn: that's a great a suggestion
… would that help the editors? does it make sense to do?
jeswr: it makes sense, Erich and I could do that asynchronously
Requirement Consent-based data sharing
acoburn: let's move to 'consent-based data sharing'
… this is a little bit different than access control
… WAC/ACP just gives access
… consent-based model involves explicit interactions, usually has purpose and receipts, and is revokable
uvdsl: I want to highlight there are two parts: (i) having the ability to give consent, and (ii) being able to verify the consent
<TallTed> change "duration" to (or add option for) "start/end datetime"
uvdsl: you can support the former without the latter
… the first is like the cookie banner, the second is about cryptographic verification
ebremer: I thought we discussed something about logging last time?
… that we discussed that it wasn't in scope?
<eBremer> uvdsl - I haven't forgotten. I will be adding it as a linked glossary term to define it as cryptographic
acoburn: did you mean 'Auditable Trail?' it was merged with one in the thirties
<uvdsl> eBremer, no worries :) just wanted to highlight it to the group as well!
<eBremer> uvdsl, absolutely! :-)
kaefer3000: so the second part of 'consent-based data sharing' is actually a point of current req 9
tallted: 'duration' is a broad term, but usually you mean start datetime / end datetime
… the way these are being edited right now makes it hard to keep track of all terminology
… caution: I suggest to just put things together, and do editing later
<Zakim> ryey, you wanted to ask difference between explicitly having the notion of "consent" vs using inbox and then an app to handle it
ryey: how is consent different from this being a message to an inbox and a consent handling app?
… is there a need for a different concept?
acoburn: so, would this happen at a different layer than LWS?
uvdsl: I think I agree with Aaron, at ryey: inbox is _an_ implementation
acoburn: this is basically about interoperability
<TallTed> "consent" is a loaded term. "permission to see, read, update, delete" are better.
acoburn: so something to debate
<Zakim> bendm, you wanted to say that conflating data interactions with authentication/authorization interactions (i.e. conflating them in the same level) was a bad thing in our dev experience
bendm: to say that conflating data interactions with authentication/authorization interactions (i.e. conflating them in the same level) was a bad thing in our dev experience
bendm: putting this into the storage layer can add complexities
tallted: "consent" is a loaded term. it has legal things making it problematic, "permission to see, read, update, delete" are better.
acoburn: access grants and permissions are going to be a better terminology
kaefer3000: I agree that part of consent should be part of another layer, but I wonder what is the minimum needed in the protocol to handle that
… the question is: how do we facilitate the discovery of the resource that such requests should be sent to?
… and so that consent modeling is not part of the spec
… so can we specify a small thing to facilitate the rest
Requirement Data integrity verification
acoburn: next: "Data Integrity Verification"
… there are a number of IETF specifications to address this
… maybe we can just point people to best practice references?
… eg message signatures
… basically: hash or signature-based mechanisms
<ericP> there's always TLS
tallted: appropriate mechanism is going to vary with the data, how it's stored, how it's accessed
… i.e. encrypted at rest, in transit, etc., will impact the mechanism
… we probably don't have to reinvent the wheel, we should need more loose coupling
bengo: this is an important UC for our work, specifically on the write side
… what's not as obvious, is how a reader can later on know later on what the digest of the writer was
… I'd like to have affordances on how a server must preserve a digest, so a reader can have assurance
<Zakim> uvdsl, you wanted to ask what the specific use cases are for Data Integrity Verification
uvdsl: what are the specific use cases for Data Integrity Verification?
bengo: a lot is about activitypub data in and LWS server
… eg if I put photos in my LWS, how can I be sure that the server isn't tampering with it?
… eg news publishing: what is read from the server is guaranteed to be what was put by the writer, independent of the lws server
<TallTed> creator has to sign everything ... with reliable tools ... and write with reliable tools ... etc.
bengo: another one is about the referent of your DID document: it would be a big deal if a service provider could add their public key to your verification methods
<TallTed> "This is my descriptor document, which I have signed with my private key, and which contains my public key.."
uvdsl: what are the mechanisms that you need in the server?
… compared to what the application would need to do
… i.e. if the storage server has no access to my private key, isn't it solved?
dmitriz: just want to add: yes, some of this can be handled on http requet level, some on data model and application level
… there's a bit that LWS must handle
… eg if I'm reading and writing JSON document, I can use JWS to sign, we have the digest header to make sure that the http request is handled correctly
… what we need on LWS level:
… non-text, non-structured data documents
… e.g. JPG
… these not have native support for provenance or don't have digest spec
<bengo> I'd also answer: we need some assurances from the LWS spec/server that the server SHOULD or MUST actually persist and then offer reads for the Digest, not just throw it away or tamper with it after the application/client writes it.
dmitriz: eg via a link to an auxiliary resource
acoburn: concerning the F2F scheduling: there's no news yet
<dmitriz> @bengo: +1, yeah
<gb> @bengo
acoburn: adjourning, have a good week!
<bengo> gb haha ya https://
<dmitriz> @gb - I think that's the wrong bengo
<gb> @gb