Meeting minutes
laurens: admin charter extension process is still onging
pchampin: we are getting it extended for few months to have time to write a re-charter
… even if it expires there is not auto closing, but we better do it in due time
… we need to continue the work on new charter, and AC will need to vote on that new charter
laurens: our current recurring meeting is set to expire on Sep 8th, once admin re-charter goes through you should see and updated invite, sometimes in next few days
… we plan to keep the existing slot unless there are objections
… Sep 7th meeting has been canceled due to holidays in US
Vote: Discontinue the SSI DID Key document PR#229
<jeremycaine> for UK teammates, Aug 31st is a public holiday
laurens: this PR removes the references to that authn suite
<Zakim> acoburn, you wanted to talk about relationship with ssi-cid
acoburn: one consideration is that there is an overlap with ssi-cid suite
… currently the cid suite doesn't say anything particular about did methods and did URIs
… I would like to see, is to adjust ssi-cid to clarify how did method would work using this suite
… we may change dereference to resolve in few places, minor adjustments may be needed
<pchampin> +1, some adjustment to lws-authn-ssi-cid will be needed
<laurens> PROPOSAL: Merge the PR discontinuing the SSI DID Key document at w3c/
<gb> PR 229 Dicontinue authn-ssi-did-key (by pchampin)
<elf-pavlik> +1
<pchampin> +1
<laurens> +1
<termontwouter> +1
<jeremycaine> 0 - apologies, did not review
<eBremer> +1
<acoburn> +1
<TallTed> +1
<gibsonf1> +1
RESOLUTION: Merge the PR discontinuing the SSI DID Key document at w3c/
<Zakim> acoburn, you wanted to add an action to adjust ssi-cid suite
acoburn: i will add an action, i'm willing to do it myself, regarding discussed adjustments to ssi-cid
ACTION: acoburn to adjust the SSI-CID suite to be more clearly compatible with DID methods
<gb> Created action #231
Discussion: Remove the specific ETag requirements and defer to RFC 9110 PR#228
laurens: we had some discussions in the past we pivoted from not having anything to introduce ETags as a baseline
acoburn: from last week conversation, i reworked it from removing ETag requirement to having ETag a MUST
… it is applied across various resource types, data resources, containers, aux resources
… elf-pavlik mentioned formatting changes, there were touched since the lines were there before
<Zakim> elf-pavlik, you wanted to say no need this time
elf-pavlik: mostly for future PRs
acoburn: I agree PRs should be targeted, it's mostly due to history of this PR
Discussion: Add subject_uri_schemes_supported to AS metadata PR#227
laurens: we want to be able to communicate in authz server metadata which types / schemes of identifiers are supported
acoburn: we discussed it last week and approved, subject to modification to terminology
… we had uri_scheme but in our examples we had DID scheme and method
… prefix seamed not fitting, i had suggested resolver
… in the discussion Christoph suggested subject_identifier_types
acoburn: I like it better than resolver, i would be inclined to use types
<laurens> +1 to subject_identifier_types_supported
acoburn: please weigh in the PR unless you have opinion now
<elf-pavlik> +1 types
laurens: I see some emoji reactions in the PR
<Zakim> elf-pavlik, you wanted to ask if old vote is still valid?
elf-pavlik: can you just merge it based on older vote?
elf-pavlik: do we have to vote again or is rough-consensus in the PR enough for a merge?
acoburn: since we change terminology, i migh suggest that we have pro forma vote next week
laurens: i agree since we change some requirements
Discussion: Decide on resolution for StorageResource definition issue#220
laurens: there is discussion on terminology
… is it relevant beyound access requests and access grants
acoburn: as far as i know it is for acces requests and access grants
laurens: eBremer is there anything specific you would like to discuss today?
<Zakim> elf-pavlik, you wanted to mention LWS resource definition
eBremer: I think is clear and do the draft to discuss it
elf-pavlik: i think we want to align the LWS resource alternative names but we can do it after the PR
laurens: I would be inclined to support existing LWS Resource and don't introduce new terminology
laurens: +1 to doing that after merging
Discussion: Extracting the move of resources between containers issue#148
laurens: in the proposal for containers, there was a notion for multiple containment, which we didn't keep
… it had possibility of moving resources between containers in atomic matter
… my main question would be to extract that aspect
laurens: are there any considerations or issues that need to be fixed
<pchampin> +1 to pursue the direction just described
<Zakim> elf-pavlik, you wanted to mention that it's not possible now with even two requests
elf-pavlik: i don't think we can re-parent this using the same identifier
laurens: we don't specify how identifiers can be controlled by the cilent
laurens: true, because we don't specify how to for identifiers
… we removed the Slug: header
… we need to introduce new operation for that
<gibsonf1> +1 to operations to move resources between containers
<termontwouter> +1 for the proposed approach
<Zakim> elf-pavlik, you wanted to mention authz
laurens: we should add consideration on authorization
elf-pavlik: while we are staying away from authn as much as possible, but we could point out that it's like a DELETE and a POST
laurens: I think it should be optional and not a MUST
… there should be some authorization check, possibly equivalent to DELETE and CREATE
<Zakim> acoburn, you wanted to ask about moving entire container hierarchies
acoburn: what I'm reading in, was about moving data resource
… what I'm wondering about, would this proposal allow to move an entire hierarchy of containers
<gibsonf1> +1 on moving entire hierarchies permissions allowing
acoburn: if you were able to move a parent container would you move the whole subtree
laurens: i would take it into consideration
laurens: it may be up to implementers
laurens: method not allowed could be returned
… it could be indicated
… otherwise we are going to go into a rabbit hole if we specify it
<acoburn> This will be something for which implementation feedback will be very important
<Zakim> elf-pavlik, you wanted to request storage capability for the feature
elf-pavlik: it should be discoverable
… low-hanging fruit to change the URI
… so we should add this to the StorageDescription
<termontwouter> +1 for clear capability discovery
laurens: this capability is part of proposal i'm going to write
… we need to indicate what user can update
… possibly under certain condition
pchampin: +1 on making it optional and discoverable
… moving containers is tricky since it can cerate cycles
… we should have informative text warning implementers
… also talking about authorization, it should be the same on delete and create
… many authorization policies and rules are based on where it is, moving it can have impact on applied policies
… some non normative text should could help to point it out
… maybe even recommending it to warn the users about impact on access
eBremer: I agree with everything, keep it optional, we should specify how exactly it should work when supported
laurens: I'll try writing a PR and put it on next week agenda
Discussion: Test suite
langsamu: i will explain what i've been workin on, and even show something
… the test suite part and software for data driven test suite
… it will take some data in the test manifest format that ericP starte working on
… data and assertions on responses to those requests
… once it has been loaded and executed, we get EARL report
… report will be based on how responses meet the criteria
laurens: is that work is in a public repo or not yet?
langsamu: not yet but i'm getting there
laurens: can other people chime in or contribute?
<Zakim> elf-pavlik, you wanted to ask about sequence of requests
langsamu: i don't ask for anything right now but will publish it
elf-pavlik: i made some comments on the closed PR: sometimes we need to test a sequence of tests
… what's your plan for sequences?
langsamu: these tests are generated from the examples so there's a lot more work. right now 1 req, 1 resp
elf-pavlik: ericP's tests were single req/resp but the SoLID test suites are sequences
langsamu: we can stack the antecedents in prereqs for a test
elf-pavlik: so we have some duplication
langsamu: the software will need to meet the prereqs (the same way it runs a test)
elf-pavlik: most servers will only offer a public LWS interface
langsamu: agreed, we don't want unit-test style that invades the server
… if this is too much duplication, i may propose changes
ericP: I find myself frequently facing it
… having orthogonal tests
… if somethign in the sequence fails the whole seq is marked as broken
… and you also don't want to duplicate things in the surface of the test suite
… the best i've come up with, is to have lanugage for the post and gets and verifies
… then embedd it into prereqisites
… other expresivity that is required, you need to capture URLs and media types
… i have a sketch proposal for that
<Zakim> elf-pavlik, you wanted to ask about idea of test suite task force
elf-pavlik: i think jessie suggested a task force for testing
langsamu: eBremer and i had a meeting already.
langsamu: Jesse have setup on meeting and we made some progress
laurens: +1 to a task force
laurens: i support and idea of the task force
laurens: if ericP or elf-pavlik are able to lead the effort on the task force?
… should we have more frequent deep drives
jeswr: I will add recurring meeting and make available to the group
laurens: once we get implementers involved they may want to join as well
ACTION: jeswr to plan recurring test suite task force meetings
<gb> Created action #232
ericP: I'm not at all married to the current approach, we can make changes to it, feel free to propose ideas
langsamu: thank you, it's good to know, i created some issues on that repo already
… i will probably stop doing issues and PRs and start making chanes
… it is intuitive and standard
ericP: do you have gh permissions to go nuts?
langsamu: i do have
langsamu: you can see my CLI
… i'm running a test
… this is .NET cross platofrm, can be in a container
… a skeleton is running, each test is a no-op no assertions yet
… you may want to run suite as test
langsamu: another command puts out Turtle with EARL assertion graph
… we have a test case for each entry in ericP's manifest
… I will add more data how it links to the specs
… I will also need to link test cases to one another
… leaf nodes represent specific assertions
… for example a 201 response
… each one would be a seprate test
ericP: EARL is the standard way people in SPARQL and RDF are reporting their results
… we can catalogue which features are supported by who
<Zakim> elf-pavlik, you wanted to make it easy to run by implementers
ericP: anyone who runs suite learns earl
langsamu: i've chose it exactly for that reason
… i've done it for SHACL
… there is an test suite, impl report and submission process
langsamu: implemeters should be able to produce a standard EARL report
elf-pavlik: i have code to run the local tests as CI tests
… so it's available for both
Discussion: Implementation feedback
laurens: we may keep some discussion for the next week
… mostly checking who is working on implementations
… anyone is actively implementing, will it be open source, more of a hobby, PoC?
… are we intending to go beyond simple implementations
… not a formal pledge, mostly getting a feel
<langsamu> I'm working on a server implementation as part the test suite work. Will be OS. No progress to report.
jeremycaine: I haven't started on LWS
… I'm doing AI assisted Solid server in Rust
… I'm hoping some things can be carried over to LWS implementation
<gibsonf1> Will be starting soon on initial LWS commercial/proprietary implementation (TwinPod - Commonlisp)
jeremycaine: probably will get to doing LWS in October, will decide then if I will open source it
eBremer: I have LWS implemetation, is open source and critical to my work
<acoburn> Inrupt will be starting soon on an LWS implementation (commercial/closed-source)
jeswr: I have a third implementation
jeswr: elf-pavlik had a PR where I listed mine
<jeswr> w3c/
<gb> PR 171 LWS Implementation tracking (by elf-pavlik)
laurens: we may want to start tacking it in implementations reports style repo
<jeswr> +1 to implementation report
<Zakim> elf-pavlik, you wanted to mention access grants
elf-pavlik: i'm trying to align SoLID SAI with our access requests and grants in LWS
… it's still SoLID-based but should be re-usable in LWS
<jeremycaine> quit