Meeting minutes
Introductions & Announcements
laurens: One small announcement from my side: April 27/28 FTF mtg coming up in London hosted by ODI - next week will be taking time for agenda - get items for agenda ready for next week.
jeswr: WIll send out an email about the FTF today
Issue triage
laurens: New issue #110?
<gb> Issue 110 Need for a deterministic mechanism to declare the Abstract State Infoset Type of a resource (by damooo)
acoburn: I think its out of scope. Could be important for spec build on top of LWS, but not our role to add this in.
PR #82 - Pagination
<laurens> w3c/
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
laurens: a few minor changes since last week. Pagination section has been moved. Now a SHOULD in general, and some wording changes.
<Zakim> bendm, you wanted to ask about total items: must be exact?
bendm: are totalItems an integer and MUST?
… It might be hard for servers to track changing content quantities
gibsonf1: about pagination, is the server in charge of how many items to put in a page?
laurens: yes, the text says the server defines page boundary
gibsonf1: could we take that out?
laurens: we could, but note that no text specifies how the client would specify page boundary
gibsonf1: agreed, but let's not prevent that
pchampin: I think we can remove that server decides page counts - support removing that constraint. I think total-items can be absent
<Zakim> acoburn, you wanted to ask about totalItems
gibsonf1: it would be really difficult for an application to provide good UX without knowing the total number of items
… yes, it can change, but at a given time, I don't see why the server could not provide it
acoburn: I agree with pchampin just said. Could be difficult to determine total items. Maybe not have total items
bendm: I'm happy to change the MUST to a SHOULD
<acoburn> +1 for SHOULD on totalItems
<eBremer> +1 for SHOULD on totalItems
laurens: fine by me to change total items to Should
<laurens> PROPOSAL: to accept the pull request #82 as proposed.
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
laurens: would like to vote on proposal
<gibsonf1> +1
<pchampin> +1
<eBremer> +1
<laurens> +1
<TallTed> +0
<acoburn> +1
<uvdsl> +0
<jeswr> +1
<AZ> +0 (need more careful reading)
<bendm> +1
laurens: looks like consensus to merge
RESOLUTION: to accept the pull request #82 as proposed.
<gb> Pull Request 82 Pagination for LWS Containers (by laurensdeb)
<Zakim> bendm, you wanted to ask about modifications
bendm: Just adding a new issue is fine for follow up?
laurens: issue or pull request is fine for modifications
PR #96 - Propose Web-CID Profile for Agent Identification
<laurens> w3c/
<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)
laurens: Quite a bit of back and forth on #96 - want to keep it to 15 minutes for the agenda.
<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)
<laurens> w3c/
<gb> Issue 57 Agent Identification (by uvdsl) [ready-for-pr]
uvdsl: To keep everything modular, came up with web based profile that LWS might employ. Have been extensive technical discussions - add to PR if needed. SHould it be recommendation track or working group note, or is this in scope.
laurens: My concerns at this point: most pressing are conflicts with auth suite, the subject plane (how to fix), extra effort needed by implementors to take into account (range 14 concerns), Structure of LWS protocol - I don't see a good fit how this spec ties into the other documents - not sure its best for implentors
<uvdsl> w3c/
<gb> Issue 164 Base identifier including a fragment (by pchampin)
uvdsl: On tech aspects, proposal not set in stone. pchampin has locked issues upstream, has been discussion with verifiable identity group - can update as needed. We can drop the workaround if there is a more elegant solution for the agent vs subject. Current proposal is best way right now I could solve the various issues. This does not adhere
… to one protocol construct with LWS, but LWS could still potentially use it. Verifiable Credential group uses a modular spec that might work for us too.
pchampin: I'm abivalent to pushing this as a separate track document, my main reason is that apart from reconciliation, a smoother alignment is needed and already possible. My impression is just do what is in the other spec - not sure about that. Maybe is should be guidance instead
<Zakim> uvdsl, you wanted to answer PAC
<pchampin> my point was: if you want to use https: CIDs, do whatever the CID spec says *and* what the HTTP spec says
uvdsl: I do agree with a smoother reconciliation. The CID spec does not require http scheme, as such, don't define conformance statements about how to serve the control document. There is an unspecified implementation gap, so I propose the LWS will provide the implementation spec in addition to the CID requirements that don't include
… implementation. We need a normative document to specify servers/consumers for this conformance profile of CID
<Zakim> acoburn, you wanted to describe current technical conflicts and outline possible paths forward
acoburn: I object to this beacause of specific technical conflicts between CID spec and LWS spec. THis make it a bit of a non-starter. CID specifies a particular id field as being subject being described (in oauth etc) and that the subject is not the agent but the document id. We could take an alternative approach: lets us adhere to CID and stay
… consistent to LWS/oauth subject, simply describe how an implementation would differentate between agent and document url.
<pchampin> +1 303 redirect is the "currently available smoother reconciliation" that I was talking about earlier
<Zakim> uvdsl, you wanted to respond to acoburn
acoburn: I'm pretty strongly -1 on this proposal, but there are ways to achieve the CID goals in a different way
<uvdsl> w3c/
<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)
<uvdsl> w3c/
<gb> Issue 163 Clarification about canonical URL dereferencing (by pchampin)
uvdsl: my proposal does not diverge from CID - usage of terms in different context is not indicative of the entire proposal - it is acceptable to clearly define the semantic differences in different speciations with the terminology section. I suggest pchampin's path to reconcile differences, redirect might cause a problem, but might be issues
… between canonical url of document and redirect does not resolve the underlying problem of fragment identifier. 303 has faced quite a resistance in the past so careful to recommend that as a solution. I would prefer pchampins approach
<Zakim> pchampin, you wanted to agree with both uvdsl and acoburn
pchampin: I agree with both uvdsl and acoburn. Yes a CID can have itself as a subject, but then the expectation in rest of auth suite is that the subject is the agent. Proposal conflicts with general approach to oauth. But I see that you want a smoother approach. As for 303, its not to require 303, I would argue that its not the easiest way to
comply (given the discomfort), but its the only way to comply at the moment. I think its viable to use this now.
gibsonf1: at Twinpod, we do 303 redirect, it is a little ackward but it works
… we don't use fragments in WebID
<Zakim> acoburn, you wanted to say that http14 should be possible, not required
acoburn: It should be possible to satisfy range 14, but it should not be required
<uvdsl> Using other CID profiles is always possible :)
<pchampin> I would consider that they conflict with how other specifications are typically articulated with each other
laurens: To summarize: proposal has some conflicts both inside and outside this working group. On the other hand, there are range 14 concerns, with 303 redirect a possible solution, and possible CID 1.1 which might support fragment identifiers. Does that summarize it for you and do you see a path forward?
uvdsl: I would propose to adopt WEB-CID as a work item
laurens: any text to propose a vote on that
<uvdsl> I thus propose Web-CID, an HTTP-based conformance profile for agent identification on the Web, for adoption by the WG as FPWD. This delivers on the task I was already assigned by the chairs to contribute to clearing issue #57 .
<gb> Issue 57 Agent Identification (by uvdsl) [ready-for-pr]
laurens: any objections?
<laurens> PROPOSAL: To adopt Web-CID, an HTTP-based conformance profile for agent identification on the Web, as proposed in PR #96
<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)
<pchampin> +0
<uvdsl> +1
<laurens> -1
<acoburn> -1 (for the reasons outlined in the meeting)
<kaefer3000> +1
<bendm> +0
<TallTed> -0
<gibsonf1> +0
<ryey> +0 (have no enough knowledge to determine)
<eBremer> +0
<jeswr> +0
laurens: Because of the -1's, we need to remove the conflicts with LWS first. We are running low on time to finish our charter
<Zakim> uvdsl, you wanted to ask about the specific conflicts
laurens: There is relevance to this proposal and the discussion, would like to remove conflicts prior to merge.
uvdsl: Could you summarize the conflicts so I can address them?
laurens: Most important is validation of authentication credentials.
uvdsl: Would have been good to get this feedback earlier
PR #106 - Add editors draft for LWS Access Requests and Access Grants
laurens: Recommend all go through this PR so we can make progress.
acoburn: Very briefly: PR #106 some comments, no changes yet but will soon, but looking at making target attributes more flexible. Would like more feedback and ideally vote on merge next Monday
<gb> Pull Request 106 Add editors draft for LWS Access Requests and Access Grants (by acoburn)
laurens: Would be good to have PR for type index for next week
ebremer: will do that