Document changelog from "roughly-0.8" to "Dec-2019"

[michielbdejong]

Please document the changelog from the roughly-0.8 version to the Dec-2019 version. It may be useful to categorize the changes by if and how they require action from server- and/or client- implementers:

• changes that will make a roughly-0.8 server incompatible with a Dec-2019 client
• changes that will make a roughly-0.8 client incompatible with a Dec-2019 server
  1. #77 Restructure JWT in Authorization header Bearer token (the SolidAuthClient will look at the WWW-Authenticate header and be able to switch between both formats, but new servers will only be required to implement the new one). Note that this change will at first be documented in a PR and not in the master spec text, but @jaxoncreed will already add support for it to Solid-Auth-Client.
  2. Add AUTH command to WebSockets protocol (older servers will ignore the AUTH command but newer ones will require it)
  3. Remove SPARQL-on-GET
  4. Remove Globbing
• changes that will break compatibility in both directions
• changes that are non-breaking

@csarven @kjetilk is this list correct?

[michielbdejong]

Not breaking the client-server interaction per se, but breaking for how users expect app permissions to work:
5. the acl:trustedApp mechanism was removed

This means a user should (find a way to) use acl:origin in ACL docs instead of acl:trustedApp in profile docs.
Something like https://github.com/inrupt/launcher-exploration / https://launcher-exploration.inrupt.app/ could probably make this pretty seamless, though.

[kjetilk]

There is no Dec-2019 document, because we were told it is more important to reach rough consensus on as much as possible than produce a document. The only thing that has been decided to the process so far is to remove globbing. Remove SPARQL-on-GET happened before, but I guess it is in a similar situation. #77 still has the "Under discussion" status, as no rough consensus text has been proposed, and it is up to the panel to propose it.

[kjetilk]

Ooops, hit the wrong button. :-)

[michielbdejong]

So from what I can see, those 5 are the main changes between the roughly-0.8 version we tagged in July, and the "December 2019" version we're tagging today.

[michielbdejong]

At some level you could say #115 is a sixth one, although it will probably go down in history as a clarification and not a breaking change.

[michielbdejong]

So for my own notes, I'll consider this right here as "current Solid", starting today. Just like until today I used inrupt/pod-server#15 as "what I call current Solid".

[michielbdejong]

Ah, and I think the TLS-bridge requirement from solid/webid-oidc-spec#26 (comment) / https://github.com/solid/solid-spec/pull/171/files#diff-04c6e90faac2675aa89e2176d2eec7d8R126-R127 was also not copied over, right?

Changelog from 0.8 to 0.9

So to summarize ([-] is feature no longer required, [+] is feature newly required):

For storage servers:

• [-] sparql on get
• [-] globbing
• [-] acl:trustedApp
• [-] strong consistency
• servers can now choose whether they prefer the receive the old or the new bearer token format

For websockets-pubsub server:

• [+] not sending updates to clients that didn't prove acl:Read access to the resource in question (which clients can do by sending the auth <bearer> command, see below).

For IDPs:

• [-] webid-tls bridge (probably downgraded from a SHOULD to a MAY?)

For app developers

IIUC, for app developers (as a result), this means:

• no longer rely on sparql-on-get
• no longer rely on globbing
• no longer rely on acl:trustedApp (https://github.com/inrupt/launcher-exploration can help there)
• start sending the auth <bearer> command when connecting to websockets-pubsub
• support both the old and the new bearer token format
• deal with servers that are only eventually consistent (and not strongly consistent)

[timbl]

Issues I have with the changes

• I think acl:trustedApp is useful. For things like the data browser.
• Don't wantr to remove use of TLS to log on until we have webathen log on . We should always have at least two systems.

[kjetilk]

I haven't participated in the auth* work directly, but that seems to be about it.

I do note that the REST API documentation is very sparse, and that we know that NSS doesn't conform to LDP, and that / semantics isn't well developed, and various other issues. It is our ambition to not break things in there, and we're working on verifying the current NSS behaviour, but there is a lot of grey area.

[elf-pavlik]

Don't want to remove use of TLS to log on until we have webathen log on . We should always have at least two systems.

I think we should always stay very clear which case of 'log on' we discuss

1. user establishing session with their OIDC Provider (OP)
2. user establishing session with any Solid Storage (RS) by navigating to URL hosted on that storage directly with a browser
3. user establishing session with an app (Client)
4. user making authorized request to Solid Storage (RS) using an app (Client)

While for 1. we probably can leave it up to OP to use whatever it wants. For the rest we want to have one common mechanism evolving from WebID-OIDC in Authentication and Authorization Panels.

I think acl:trustedApp is useful. For things like the data browser.

This comes into play in case 4. from my previous point. IMO direction which gets strongest consensus would give this responsibility to OP, which would ensure respecting user's privacy while still giving user full control over how much of their access they want to delegate to each application.
Mentioned one common mechanism which builds on OAuth2 seems capable of addressing those requirements gracefully. WebID-TLS doesn't seem to provide comparable capabilities and since spec can leave case 1. (log on to OP) open probably it wouldn't even need to mention WebID-TLS just as it doesn't need to list any other of all the possible ways for user to establish session with their OP.

[elf-pavlik]

I've just created PR attempting to clarify that WebID-TLS doesn't play any more a special role in solid ecosystem #140

[michielbdejong]

Also heard a rumour that deletes may become recursive, see https://github.com/solid/specification/blob/editors-draft/main/introduction.bs#L23

[csarven]

I suggest to close this issue. Will label with "Waiting Commenter" for the time being prior to closing.

https://solidproject.org/TR/2021/protocol-20211217 (Version 0.9) is taken to be the first published version of the specification that went through some process/group/team deliberation. It does not have a change log because the diff is not straight forward to produce or necessarily observable. While documentation prior to v0.9 exists, they weren't "specifications" in the common sense. We had to draw the line somewhere.

That aside, if a change log along the lines of https://solidproject.org/ED/protocol#change-log can be produced for https://solidproject.org/TR/2021/protocol-2021121 , we can consider adding it.