Meeting minutes
Introductions & Announcements
laurens: seeing no announcements, moving along
Issue Triage
laurens: sharing screen from https://
… eBremer, as I understand, will create a PR to address #24
<gb> Issue 24 Reasons for separate rest bindings (by jeswr) [ready-for-pr]
laurens: eBremer assigned to the issue and marked as "ready for pr"
… no new issues in the last week
Agent Identification #57
laurens: opened by uvdsl about use of CID documents in the current LWS protocol
… room for collaboration with Solid CG
… some consensus about how to bring WebID-based AuthN in line with current proposal
… might also warrant further discussion
uvdsl: the issue is a bit broader than just discussion CID and how to make it work with WebID
… as proposed in the comments, concern about the requirement to use a URI for an agent identifier
laurens: there are two parts: (1) identity requirements, as currently formulated and (2) compatability problem with WebIDs
… what are the reservations about agents being identified as URIs?
uvdsl: mostly concerned about dereferencing of URIs
… worried about interop aspects
<Zakim> acoburn, you wanted to talk about dids
<laurens> acoburn: The minimum requirements for agent identification indeed involves URIs, not necessarily even HTTP URIs
<laurens> ... we want both compatibility with what was used in Solid, but also provide interop with DID.
<laurens> ... If we constrained to HTTP URIs that would explicitly exclude DID.
<laurens> ... Now we do allow both forms.
<laurens> ... An authentication suite can provide any kind of constraints on top of this.
<laurens> ... Note that there is both the identification of the agent as well as the identification of the suite.
<laurens> ... If you were to send a token (e.g. a JWT derived using a WebID based authn method), then the AS, which indicated support for the suite, can validate the identification of the agent being e.g. HTTPS.
<Zakim> uvdsl, you wanted to say that the proposal in the Issue says: Not limiting generality, HTTP(S)/REST is the baseline implementation requirement.
uvdsl: I did not comment on the PR for the AuthN proposal
… the general approach is fine, and I agree for the general perspective to have a discovery part
… not arguing against that in particular. Worried about incompatible, non-interoperable systems
… worried about the interoperability of the spec, would like to have a minimum baseline, such as HTTP CIDs
<gibsonf1> +1 on minimum baseline http cids
<pchampin> +1 uvdsl
<gb> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
laurens: to resolve this, would a minimum HTTPS authN suite resolve this?
uvdsl: two parts: one is to have an HTTP-based CID authentication suite as a minimum baseline
<Zakim> acoburn, you wanted to talk about federations/non-open ecosystems
acoburn: I wanted to mention that in an open ecosystem this is fine.
… There will be many ecosystems that don't exist in an open ecosystem.
… Those implementations may choose not to support an HTTPS baseline.
<Zakim> uvdsl, you wanted to ask why the spec should be catering towards silos?
uvdsl: why do we consider closed ecosystems that create silos as a first class audience?
acoburn: One of the things we want is broad adoption.
… This includes various types of architectures.
… One of these architectures is an open ecosystem & distributed model.
… Another widely supported architecture is a federation.
… Federation requires a different kind of model.
… We don't want to choose one over another.
… We're not trying to say everything must follow a single model.
gibsonf: on open vs closed, if you're closed, you can do whatever you want
<uvdsl> +1 to gibsonf1
<Zakim> uvdsl, you wanted to confim whether the chairs deem adoption more important than interoperability?
gibsonf: if it's not open, I wouldn't call that LWS
uvdsl: I want to confirm that adoption is more important than interop?
laurens: I think both are important
… federated ecosystems require just as much interop as open ecosystems
<Zakim> acoburn, you wanted to talk about regulated industries
laurens: federated ecosystems should not be precluded from our work here
acoburn: I want to bring up areas Inrupt has experience in for highly regulated industries which require very strict controls over who can and cannot login and what the trust chain is.
… Limiting access is vital here.
… Requiring all LWS implementations support an open ecosystem is not going to happen
pchampin: we should not frame the discussion as open vs. closed
… federated systems are somewhere in between
… as for adoption is more important than interop -- this is not black and white
… having non-open systems use open technologies is beneficial
… I supported uvdsl's original point, but am convinced by laurens' and acoburn's points
… I would be in favor of defining a compliance level or profile where certain baseline requirements are present
laurens: describing a conformance class seems like a good idea, as long as it's not a requriement for the baseline spec
gibsonf: by federated, is this on the internet?
laurens: yes, on the internet/web
gibsonf: this can be constrained any way you like, though
… if you use a different authentication method but no one uses it, it would pass the test
laurens: we have tried allow/deny lists, it is detrimental to interop
… introduces greater complexity
… not opposed to a baseline profile
<Zakim> uvdsl, you wanted to contradict the notion that a technical requirement such as supporting http-based authentication has implications on the governance-level on restricting trusted issuers
uvdsl: I don't think gibsonf is suggesting that everything can be solved by http
… there is a difference between technical interop and governance
laurens: schemes that restrict trusted issuers do work
uvdsl: we have a federation for research institutions
… in Germany
<Zakim> acoburn, you wanted to talk about the existing authn discovery mechanism
acoburn: A couple of things were mentioned here
… gibsonf brought up that the authorization server should claim to support a authn scheme which it does not fully support.
<uvdsl> That is not what gibsonf1 said. He said that it does support it, but the governance prevents any agent to authenticate it.
acoburn: We have a resource server that stores the LWS resources which points to the authz server which has references to supported mechanisms in its discovery.
… We want to determine which mechanisms must be present in the discovery of the authorization server.
… If you claim to support something you should actually do that properly.
… Different organizations have different needs.
… Let's imagine you have an authentication suite "Open Ecosystem WebID", in that case the authz server advertises support.
… All of the components are already there.
<Zakim> uvdsl, you wanted to clarify that I propose a baseline that MUST be supported. I did not propose a mechansim to advertise what is supported.
uvdsl: would like to clarify that my proposal is not a mechanism to discover the authentication scheme a server supports
… I would like a baseline for what servers must support
… the argument that certain federations don't want to use that baseline isn't a sufficient argument, IMO
laurens: there are two ways we can approach this: 1. work with a conformance profile
… 2. requiring a MUST have for all servers based on HTTP is something I would oppose
… would be in favor of introducing as a profile
acoburn: inrupt would also oppose a required baseline
Luke: IBM/Redhat would also oppose a required baseline
gibsonf: the dangerous part is that, if nothing is required, then it's just wild-west, that would not encourage adoption
… it makes a mess of things
laurens: what is the difference between that approach and introducing a profile?
gibsonf: if it's optional, then it will only work in some places
<laurens> ach pchampin
pchampin: to +1 what laurens suggested, we must be clear about the scope of a profile
… if we define profiles, then we need to define the scope of the profile
<Zakim> uvdsl, you wanted to support the creation of the HTTP-based CID (e.g. via then OIDC). I believe that we should provide at least one tangible example that can directly be implemented.
pchampin: that should be a strong signal for what profile should be used on the open web
uvdsl: we would still prefer an HTTP baseline mandated, we acknowledge that others oppose this
… In that case, I would create a tangible example that can be implemented, I do not want a hollow spec
… I would like a guideline for one authentication spec
<pchampin> uvdsl "implementability" is a requirement to move to Recommendation, per the W3C process :) no "hollow spec" allowed
laurens: we seem to be converging on a profile
<Zakim> acoburn, you wanted to talk (again) about regulated industries
<uvdsl> pchampin, yes! thank you :)
acoburn: For regulated industries you cannot assume any authentication scheme is going to be accepted.
… Choosing your own health application or banking app is going to be different from a chat application.
<uvdsl> I
laurens: for resolution of issue #57, we can draft an authentication suite that is HTTP based. Do we have any volunteers?
<gb> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
uvdsl: I would be willing to co-edit this
<gb> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
laurens: if you can do a first draft and then bring it back to the WG
uvdsl: do you have an indication of timeline? FPWD/CR/etc
laurens: one of the agenda points is about FPWD
… ideally this would be end of March
… would that timing work for you, uvdsl?
uvdsl: that timeframe may work, we will see
LWS Media-type
laurens: issue #61 is about the LWS media type
<gb> Issue 61 LWS Container Media Type (by acoburn) [needs-discussion]
laurens: we want to determine the media type used for containers and storage description metadata documents
… we got some feedback from the JSON-LD community that application/lws+json media type makes the most sense
… would like to hear if there is any opposition to using that media type
<acoburn> +1 supportive of that media type
uvdsl: is this defining a new media type?
laurens: this would not define a new media type with IANA
uvdsl: how would this work if a client asks for JSON?
laurens: there is some wording from the Activity Streams spec to also return JSON
<Zakim> bendm, you wanted to ask also about the fallback
bendm: would this also work if a client asks for application/ld+json
<uvdsl> +1 to Ben's concern :)
<Zakim> acoburn, you wanted to talk about fallbacks
acoburn: I would like to see the default be application/lws+json but in the IANA considerations section we could mention it conforms to application/json and application/ld+json that would resolve this.
… There is wording from ActivityStreams which allows us to do exactly that.
<Zakim> bendm, you wanted to ask so there is an IANA description needed?
bendm: there is an IANA description needed?
acoburn: The ActivityStreams community put this in a considerations section afaik.
pchampin: I think this is wrong -- the IANA considerations section is for formal registrations with IANA
… I do see an application/activity+json application is present
<pchampin> https://
pchampin: the work of the group is to write the IANA considerations section, the W3C staff contact will help with the registration part
<uvdsl> Good discussion today, thank you all!
laurens: thank you for the discussions today