Ruben Verborgh

> When WebID-OIDC solid client encounters new origin, it would still require presenting an input And that's how it should be, privacy-wise, but hopefully not with a modal popup.

> A file that is removed and has its ACL persist may seem harmless, but then if another file (or folder) with the same name is put back in its...

The comment above rather seems to be about whether a POSTed file can end up in a specific location for which an ACL file is already in place, not about...

The issue to me is about users _without_ Control permission causing the deletion of an ACL file (which is an act that should require Control permission).

> If you cannot delete a Resource (because you lack Control permission on that Resource) Deleting a resource requires Write access on its parent folder (not Control access on that...

> As I understand it, Control permission on a Resource amounts to Write permission on that Resource's ACL. \* Read and Write > Therefore, deleting a Resource should require Write...

> Can a user have the required privileges to DELETE /foo but not /foo.acl (in)directly? Yes. Have Write permissions on / but no control permissions on /foo.acl. > If yes,...

> What advantage do you see in having /.well-know/tls-clent-cert and not Link header for rel like webid-tls-auth or something like that? OIDC also uses a well-known thing, so I wanted...

> Does it have to rely on setting a cookie or it could also (or even instead) get a Bearer token And actually, that would just be OIDC then. …which...

> If you establish cookie sessions Honestly, I'm not a fan of the session cookies we currently have; they are opaque identifiers the client cannot use. I'd like to replace...