search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
491 stars 46 forks source link

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

Open michielbdejong opened 4 years ago

michielbdejong commented 4 years ago

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:

@csarven @kjetilk is this list correct?

michielbdejong commented 4 years ago

Not breaking the client-server interaction per se, but breaking for how users expect app permissions to work:

  1. 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 commented 4 years ago

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 commented 4 years ago

Ooops, hit the wrong button. :-)

michielbdejong commented 4 years ago

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 commented 4 years ago

At some level you could say https://github.com/solid/specification/issues/115 is a sixth one, although it will probably go down in history as a clarification and not a breaking change.

michielbdejong commented 4 years ago

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

michielbdejong commented 4 years ago

Ah, and I think the TLS-bridge requirement from https://github.com/solid/webid-oidc-spec/pull/26#issuecomment-506347607 / 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:

For websockets-pubsub server:

For IDPs:

For app developers

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

timbl commented 4 years ago

Issues I have with the changes

kjetilk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

michielbdejong commented 4 years ago

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

csarven commented 1 year ago

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.