946
edits
mNo edit summary |
No edit summary |
||
Line 35: | Line 35: | ||
Once this is done, users can share just what they want to share instead of following an arbitrary data-type-based separation. | Once this is done, users can share just what they want to share instead of following an arbitrary data-type-based separation. | ||
== Weave-data Access Tokens (WATs) == | |||
One idea for sharing data, and potentially for single-user use as well, is to implement a system of specialized bearer tokens. The tokens would look somewhat like this: | |||
<bearer token>:<key ID>:<key unlock token> | |||
That is, a long string of hashes and data, which could be stored as-is, or encapsulated in a file for example. | |||
Deconstructing the token: | |||
'''bearer token''' | |||
The bearer token portion of the Weave token would act as a "standard" bearer token. It would provide access to some subset (or all) of the user's resources stored on the server. This would need to include of course the relevant key and keyrings. | |||
'''key ID''' | |||
Which key to use. | |||
'''key unlock token''' | |||
Could be a passphrase, or perhaps some sort of digest (Tahoe-style?) that could be used to unlock the key or the data. | |||
Using the Weave token: | |||
The token could be given as-is to a Weave-enabled application, which would split it up into its component parts, and: | |||
# use the bearer token to retrieve keys, keyrings, and data from the Weave service | |||
# use the key unlock token to unlock the private key, and that way access the keyring, and ultimately the data |
edits