Meeting minutes
laurens: Sent out information on f2f meeting and put items on W3C calendar - also indicate attendance there would be great
Introductions & Announcements
pchampin: TPAC open to demos to all WGs - maybe someone has ideas
Action items
Prioritization of use cases
laurens: closed action item for w3c/
<gb> Issue 215 [UC] Mechanism to access a resource identifier in a storage with identifier that points to a different storage (by gibsonf1) [triage] [usecase]
acoburn: LWS requirements survey. Gives a sense of where people stand. Want to set up a must have requirments bucket, and secondly a nice to have bucket, and finally, a set these aside for now bucket
… This is just an initial cut to start focus on most important for f2f meeting next month.
bendm: Was hard to decide on difference between 3 and 5 rating for survey.
acoburn: +1 = focus -1 = out of scope
STRAWPOLL: Globally unique identifiers
<gibsonf1> +1
<acoburn> Globally Unique IDs
<bartb> +1
<bendm> +1
<eBremer> +1
<laurens> +1
<pchampin> +1
acoburn: If you think spec should include Globally unique identifiers, please vote now
<acoburn> +1
<gibsonf1> +1
<ryey> +1
<dmitriz> +0.5
pchampin: start with strawpoll: for voting
<acoburn> Use of Service Providers
STRAWPOLL: Use of Service Providers
<ryey> +1
<gibsonf1> +1
<bendm> +1
<eBremer> +1
<acoburn> +1
<dmitriz> -0 (I don't understand this requirement at all)
<laurens> +1
<bartb> +1
acoburn: has to do with trust relationships between different entities. What normative text do we agree on in spec. To focus on priorities
<pchampin> +0
<acoburn> Control of Storages
STRAWPOLL: Control of Storages
<gibsonf1> +1
<ryey> +1
<acoburn> +1
<bartb> +1
<eBremer> +1
<pchampin> +1
<bendm> +1
<dmitriz> -1 (for the 'Exactly 1 controller' part)
<dmitriz> but seems like a fine feature otherwise.
<RazaN> +1
<laurens> +1
<acoburn> Delegation of Control
STRAWPOLL: Delegation of Control
<bendm> dmitriz it's mentioned that there could be a group of controllers too, so I'm giving it a benefit of a doubt :)
<dmitriz> +1
<pchampin> +1
<eBremer> +1
<gibsonf1> +1
<ryey> +1
<acoburn> +1
<bendm> -0
<bartb> +1
<laurens> +1
<RazaN> +1
<acoburn> Transfer of Control
STRAWPOLL: Transfer of Control
<acoburn> +0
<ryey> +0
<laurens> -1
<dmitriz> +1
<bartb> +1
<eBremer> +1
<bendm> The difference between the two is very vague to me
<pchampin> +0
<bendm> -0
<acoburn> Storage Portability
STRAWPOLL: Storage Portability
<dmitriz> +1
<gibsonf1> +1
<RazaN> +1
<eBremer> +1
<bartb> -1
<bendm> +1
<laurens> +1 (but needs proper scoping)
<acoburn> +1
<ryey> +1 (more scoping, but itself is needed)
<acoburn> Adding Updating Deleting Resources in Storage
STRAWPOLL: Adding, Updating, Deleting Resources in Storage
<gibsonf1> +1
<eBremer> +1
<bendm> +1
<acoburn> +1
<bartb> +1
<RazaN> +1
<ryey> +1
<laurens> +1
<dmitriz> +1 (tho this seems like an odd one - maybe too obvious?)
<pchampin> +1
<acoburn> Data Sharing
STRAWPOLL: Data Sharing
<acoburn> +1
<laurens> +1
<bendm> +1
<dmitriz> +1
<eBremer> +1
<ryey> +1
<bartb> +1
<pchampin> +1
<gibsonf1> +1
<acoburn> Auditable Trail
STRAWPOLL: Auditable Trail
<laurens> -1
<acoburn> +0
<pchampin> +0
<bendm> -1
<eBremer> +0
<bartb> -1
<gibsonf1> +1
<RazaN> -1
<dmitriz> +0 (I think the main spec needs to provide hook/affordance, but not specify)
<ryey> -1 (some part may be useful, but this thing as a whole is not for now)
STRAWPOLL: Serialization Format
<acoburn> Serialization Format
<gibsonf1> +1
<laurens> +1
<bartb> +1
<acoburn> +1
<eBremer> +1
<RazaN> +1
<ryey> +1
<dmitriz> -0 (don't quite understand this one..)
<Zakim> bendm, you wanted to ask about number 3 vs 5 and to
bendm: Not clear whether this implies content negotiation or just serialize data in any way
acoburn: doubtful that any data any way (too broad), but some clear expectation around how certain resources are serialized. For example, containers require at least one required serialization format.
<pchampin> FTR, the discussion we had about this req https://
<acoburn> Offline Access and Synchronization
STRAWPOLL: Offline Access and Synchronization
<gibsonf1> -0
<bartb> -1
<bendm> -1
<dmitriz> +0.5 (I think spec should provide hooks/affordance, but we likely won't get enough time to standardize this. but it IS important.)
<acoburn> -0
<ryey> +0 (good to have something prepared for that, but not as core spec)
<laurens> -1
<RazaN> +0
<eBremer> +0
<pchampin> -1
<acoburn> Resumable Large Data Transfers
STRAWPOLL: Resumable Large Data Transfers
<gibsonf1> +1
<eBremer> +1
<bendm> -0
<ryey> +1
<pchampin> +0
<acoburn> +0
<bartb> -1
<laurens> +0
<acoburn> Resource Versioning
STRAWPOLL: Resource Versioning
<gibsonf1> +1
<RazaN> +1
<pchampin> +0
<eBremer> +0
<dmitriz> +0.5 (hooks/affordance)
<acoburn> -1 (memento already does this)
<bartb> +0
<bendm> -1
<laurens> -1
<ryey> -1 (good to have hooks; but not as a whole)
<acoburn> Subscribing to resource changes
STRAWPOLL: Subscribing to Resource Changes
<gibsonf1> +1
<pchampin> +1
<ryey> +1
<bartb> +1
<bendm> +1
<RazaN> +1
<laurens> +1
<eBremer> +0
<dmitriz> +1
<acoburn> +1
<acoburn> Access Request Handling
STRAWPOLL: Access Request Handling
<gibsonf1> +1
<eBremer> +1
<acoburn> +1
<RazaN> +1
<dmitriz> +0
<bendm> +0.5
<bartb> +0
<ryey> +0
<pchampin> +0.5
<laurens> +1
<acoburn> Delegation of Access Rights
STRAWPOLL: Delegation of Access Rights
<gibsonf1> +0
<eBremer> +1
<acoburn> +1
<dmitriz> +1 (though this is a repeat of earlier items)
<bartb> +1
<pchampin> +1
<ryey> +0
<RazaN> +1
<laurens> +1
<acoburn> Contextual Access Control
STRAWPOLL: Contextual Access Control
<eBremer> -1
<dmitriz> +1
<bendm> -0 (dynamic group access affordance might be sufficient for now)
<gibsonf1> +1
<acoburn> +1
<ryey> +1
<laurens> -1
<bartb> +0
<RazaN> +1
<pchampin> +0
STRAWPOLL: Inbox (notifications)
<acoburn> Inbox Notifications
<gibsonf1> +1
<acoburn> +0
<bendm> -1
<eBremer> +0
<bartb> -1
<laurens> -1
<dmitriz> -1 (seems like duplicating ActivityPub)
<ryey> +0.5 (either this, or some similar mechanisms)
<pchampin> +0.5
<acoburn> Search and Query
STRAWPOLL: Search and Query
<gibsonf1> +1
<dmitriz> +1
<pchampin> +0
<bartb> +1
<acoburn> +1 (but we will need to scope this carefully)
<bendm> +0
<eBremer> +1 (agree with acoburn)
<ryey> +1 (needs more scoping, but yes in general)
<laurens> +0.5 (this could be very complex if not scoped well)
<RazaN> +1
<acoburn> Self-descriptive APIs
STRAWPOLL: Self-Descriptive and Discoverable APIs
<laurens> +1
<eBremer> +1
<bendm> +1
<gibsonf1> +1
<ryey> +1
<acoburn> +1
<dmitriz> -1
<bartb> +1
<RazaN> +1
<pchampin> +1
<acoburn> End-to-End Encryption
STRAWPOLL: End-to-end Encryption
<dmitriz> +1
<gibsonf1> +1
<bendm> -1
<bartb> +0
<ryey> +0 (too many details to consider; doesn't have to be core spec if proven difficult)
<acoburn> +0 (really important but not a core requirement)
<uvdsl> -1
<eBremer> +0
<pchampin> +0
<laurens> -1
<RazaN> +1
<acoburn> Data Integrity Verification
STRAWPOLL: Data Integrity Verification
<dmitriz> the problem is, E2EE _affects_ the core spec
<gibsonf1> +1
<laurens> -1
<dmitriz> +1
<pchampin> +0
<bartb> +0
<RazaN> +1
<eBremer> +0 (perhaps digest headers minimally)
<acoburn> +0 (Important but possibly handled by existing IETF specs)
bendm: more info on key management Dimitry please?
dmitriz: Pattern with Storage projects is leave out of scope because its hard, but need affordance for it in core spec so its not impossible down the road.
… a flexible affordance like auxiliary resources (read about encrypted data vaults) to keep in mind whats involved
<eBremer> Encrypted Data Vaults : https://
ryey: I see 2 interpretations: 1. Verify data retrieved is same as one in storage (data transfer is correct), or 2. Verify data stored in storage is same as data originally stored in storage. Which one?
<eBremer> Digest Fields (Headers): https://
acoburn: I think existing IETF specs around digest header which allows read and write verification - using a checksum. On read client can verify checksum matches server checksum for resource
<dmitriz> this is fairly easily solved by including the digest hash in the original URL, and passing to Charlie
ryey: That answers 1, but for 2. - can I get a proof of this. Alice stores data in Bob's storage, Charlie reads that data, Charlie needs proof that data was originally stored and is same as put in by Alice
ryey: Voting to include or make new invention on this?
laurens: Its to incorporate existing work or not in the LWS spec, not new inventions
pchampin: +1 is to require a requirement in LWS, not necessarily something new. Providing affordances to make possible = +0
laurens: It might be in the wording of requirement causing interpretation issues
pchampin: The work required by implentors is another dimension
<ryey> +1
<acoburn> Consent-based data sharing
STRAWPOLL: Consent-Based Data Sharing
<bendm> I was doing the same as pchampin
<acoburn> +1
<laurens> -1
<bartb> +1
<bendm> +0
<dmitriz> +0.5 (I suspect this is a layer above LWS, application-level)
<eBremer> +0
<gibsonf1> +1
<RazaN> +1
<pchampin> +0
<ryey> -0 (not necessarily, as consent can be a complicated legal thing; do in application.)
<acoburn> Legal Basis Enforcement
STRAWPOLL: Legal Basis Enforcement
<laurens> -1
<eBremer> -1
<bartb> -1
<dmitriz> -1
<gibsonf1> -1
<RazaN> -1
<ryey> -0 (similar to above)
<acoburn> -1 (Important implementation consideration, but out of scope for the spec)
<bendm> -1 (this kind of all depends on whether we do audit trail)
<pchampin> -1
STRAWPOLL: Authentication Mechanisms
<acoburn> Authentication Mechanisms
<eBremer> +1
<acoburn> +1
<gibsonf1> +1
<laurens> +1
<bartb> +1
<dmitriz> +1
<pchampin> +1
ryey: I would vote +1 but not sure exact requirement
<bendm> +1
<ryey> +1
acoburn: Actual text in requirement we can debate and decide and scope - whether self-soverign is part we can all agree later
<acoburn> Trusted Identity Providers
STRAWPOLL: Trusted Identity Providers
<acoburn> +0
<gibsonf1> +1
<bartb> +0
<eBremer> +0
<RazaN> +0
<bendm> +0 (we should enable, but not work on that imo)
<pchampin> +1
<ryey> +0.5 ("transitive" part may need further thoughts, but it should be included)
<laurens> +0
<acoburn> Loose Coupling of Underlying Protocols
STRAWPOLL: Loose Coupling of Underlying Protocols
<dmitriz> +1 (seems reasonable)
<ryey> +1
<laurens> -1
<gibsonf1> +0
<pchampin> +0
<RazaN> +1
<acoburn> -1
<bartb> -1
<eBremer> +0
<bendm> +0.5 (to see which we can focus on)
acoburn: That as far as we can get to today - pretty far. A lot of good material for establishing focus.
Face-to-face meeting agenda
laurens: Call to action to everyone on how to approach f2f meeting. WHere do we see disagreements etc, lets include this again next week. LWS mailing list - please confirm attendance W3C calendar