Use Case & thoughts about publishing an apps key

[bblfish]

Starting from an Use case of adding the public key generated by an application using WebCrypto to the SoLiD server, this document tries to work out what the different ways of implementing this are, and points to a number of issues and documents that may be required for this to succeed.

The use of such a document is that it helps tie together a number of issues, and give them a context that helps inform decisions about how they fit together in practice. It also helps brainstorm about the best way of doing something.

It is not clear that this should go into the proposals directory. It seems more correct to have a lighter discussion space, for documents such as this, as it opens up a few lines of investigation, and is trying to gather ideas about how people envision this rather than being a finished proposal.

[dmitrizagidulin]

I'm unclear on this proposal, overall.

"P1: Publish the key in a public space (perhaps using a distributed hash table protocol)" - this is out of scope for the Solid spec at the moment. As in, if your app wants to post something to IPFS, go for it, no need for that to be in the spec.

"P2: Create a specialised (In)Direct Container" - I'm not sure current Solid servers support indirect containers (I know LDNode doesn't). Giving that this would require a significant server-side component to be developed, you should raise this as a separate issue (although I don't think there is compelling benefit to supporting those).

"P3. Place the key in a Specialised Basic Container" - Again, this would require server-side coding to support. And although I would certainly love to see a general mechanism for specialized components, we don't have that yet.

"P4. Saving the key to the application's space" - I think if all you need to do is save a public key for the app, this would be the simplest choice. Specifically, put a key somewhere, register it using the type registry mechanism, and your apps can discover it from there. However, this is all generic Solid mechanisms, no need to alter the specs yet to include this.

[bblfish]

@dmitrizagidulin The reason I proposed 4 different solutions is so that we can look at the options in front of us.

Some of the options like P1 may not be interesting for us now, but it is useful to document it as a pointer to people who are very very serious in their desire for privacy and do now want the key to be traced back to a user. If they later come to this they can see that a DHT is not excluded in principle, but is a decision we are making for pragmatic reasons.

I point out that for P2 indirect containers are not widely implemented. But it helps make the case for P3.

P3 does not actually require a specialised container. That's an error in the title. It just requires the creation of a special relation. Have a look a little more closely at that that one perhaps.

I will look at the type registry mechanism, as that has been evolving recently. But the point of P4 would be to describe the usage according to the spec, at least to see if I have understood it correctly as far as this use case goes.