Henry Story

The Title of this issue is creating the impression that we are confronted with an exclusive dichotomy. Either this or that. In fact all authentication methods can work together inside...

As this is bound to take a lot of iterations to work out correctly I opened a wiki page so that edits can be placed together: https://github.com/read-write-web/SoLiD/wiki/Storing-an-Apps-Public-Key

My use case was to store the WebCrypto generated public key on the server to give apps from that origin access to the apps' folder where the user could store...

There is a pull request out now for this, so it's easier to comment on the details [Pull Request 60](https://github.com/solid/solid/pull/60)

I have continued editing this [on my wiki](https://github.com/read-write-web/SoLiD/wiki/Storing-an-Apps-Public-Key), as it is easier to think that way, and as my PR is taking time to get reviewed. I have now looked...

Perhaps we need a version2 github tag? In [rww-play](https://github.com/read-write-web/rww-play) I implemented this over 2 years ago more widely readable ACLs and was not aware that other implementations had made a...

I have argued that all resources can/should have at least one acl Link header relation. https://github.com/solid/solid/issues/61 At present I think one needs to implement whatever is deployed and documented, but...

@melvincarvalho wrote: > @zoggy I believe the rough consensus is the first one : >> permissions on metadata of resource R are the same as the permissions on R That...

> But for metadata, i.e. R.meta for resource R, I do not see a use case where having different ACL for R.meta and R would be useful. There are two...

The browser extension for signing in using public/private key pair already exists: it is TLS client certificate authentication: https://www.w3.org/2005/Incubator/webid/spec/tls/ . Sadly Google Chrome is in the process of removing a...