Zoom Logo

Secure Data Storage - WG - Shared screen with gallery view
Dmitri Zagidulin
02:37
Attendance doc: https://hackmd.io/qv8vDYdVR9ueqzdsZp1GjA
tobiaslooker
03:53
Please note your selves on the atte
tobiaslooker
04:00
*attendance list
tobiaslooker
04:04
^
Dmitri Zagidulin
04:16
https://hackmd.io/qv8vDYdVR9ueqzdsZp1GjA
Manu Sporny
05:51
woo hoo, welcome Derek!
Dave Longley
05:56
+1
Derek Trider
06:03
Thanks everyone!
Daniel Buchner
06:33
Hey there!
Manu Sporny
12:09
q+
Troy Ronda
13:31
joined late - hi all.
Manu Sporny
13:43
hey Troy :)
tobiaslooker
13:43
Welcome!
tobiaslooker
17:01
q+
Dmitri Zagidulin
19:19
q+ to address Adrian’s question
Dmitri Zagidulin
19:31
(after manu)
Chris Were
22:33
I may have missed it from last week, but are these slides available?
Manu Sporny
22:56
Chris, yes they are -- don't have the link offhand... dmitri does tho! :)
Dmitri Zagidulin
23:16
@Chris - https://docs.google.com/presentation/d/1QEHSs4XJ05yQl2mvpiqbM80-MySxlVI9cNDLPq_XkkY/edit
Chris Were
23:18
Thanks :)
Manu Sporny
24:38
q+
Dmitri Zagidulin
25:08
q+
Adrian Gropper
26:01
Is Vault Configuration explained somewhere?
Manu Sporny
26:52
yes, here -- https://identity.foundation/confidential-storage/#datavaultconfiguration
Daniel Buchner
29:03
q+
Dave Longley
29:19
q+
Chris Were
29:59
+1
Andreas Freund
30:00
+1 for full CRUD
tobiaslooker
30:06
q+
Andreas Freund
31:12
q+
Adrian Gropper
31:30
q+
Juan Caballero
31:38
that sounds like a permissions model difference to me ?
Daniel Buchner
31:59
Yeah, if so, yes
Juan Caballero
32:38
people or hubs?
Manu Sporny
32:41
q+ for distinct use cases for each permission.
Chris Were
33:12
q+
Daniel Buchner
33:26
Tombstones can just be distinctly identified entries
Daniel Buchner
33:44
so you don't actually erase the past objects, you have something that says "deleted"
tobiaslooker
33:46
Create ~= Write action to target EDV
tobiaslooker
33:56
Update ~= Write action to target EDV document
Daniel Buchner
34:04
thus if you don't have the permission to say "deleted", that is simply ignored
Daniel Buchner
34:15
which is to say, the object lineage and data is not effected
Daniel Buchner
34:28
this means you need to be able to distinguish objects that from one another
Juan Caballero
34:35
if hubs and nonhub edv users need a diff set of permission options, the hub-edv protocol might be the place to distinguish between update and delete ?
Daniel Buchner
34:41
so that you at least 'leak' what the action is
Juan Caballero
34:43
just spitballin'
Dave Longley
34:45
my point, daniel, is that if you have "write" permission, you can write an empty document -- so we should be careful not to create permissions that give people false hope they are preventing something
Daniel Buchner
35:24
I don't think you're parsing what I am saying correctly
Daniel Buchner
35:35
say I have an object { foo: 1 }
Daniel Buchner
35:51
and its ID is XYZ
Daniel Buchner
36:16
if you want to 'delete' object XYZ, you don't send a write of { }
Daniel Buchner
36:37
you send a command "delete", wherein the command is in plaintext and there is no data
Kaliya Identity Woman
36:46
our listening audience can’t here this discussion
Daniel Buchner
37:10
so if there is no delete permission, the Hub/EDV just throws it in the trash and doesn't act on it
Dave Longley
37:34
i get what you're saying daniel, but it may not be a useful distinction/complexity ... and someone with write permission can just write {}, so you're not preventing them from deleting anything
Daniel Buchner
38:16
Sure, but the difference is that a {} is a recoverable write that the user can reverse, because you retain the deltas from the past
Daniel Buchner
38:31
whereas a true tombstone may actually delete the past object data
Dave Longley
38:42
and i think they all have to be recoverable (at least in terms of sequence number)
Daniel Buchner
38:45
so delete vs {} as a new delta is different
Dave Longley
38:46
not content
Dmitri Zagidulin
38:48
q+ to mention standardized scopes.
Dave Longley
39:42
daniel -- we should have a more full discussion about it at some point, i think we're both on the same page that it's important to get right and capture the features we need
Manu Sporny
39:53
q+
Manu Sporny
40:13
q+ for distinct use cases for each permission.
Daniel Buchner
40:44
Super high-level sync: https://hackmd.io/MrjfH8cTRjmeGhOviJtfsA
Manu Sporny
42:25
q+ to note that CRUD isn't the only model we can use... remind folks about UNIX *shakes cane at young whipper snappers*
Manu Sporny
43:03
Remember when all we had was RWX ... Pepperidge Farm remembers.
Chris Were
43:52
@manu: Ideally CRUD + user/owner/root? =P
Juan Caballero
44:28
but who is "user" or "you"? the hub might think its deleting even when its writing {}
Juan Caballero
44:40
the hub can be crud and the edv can be unix :)
Adrian Gropper
44:46
+1 manu - all we need is registration of a PDP
Chris Were
44:56
yep, totally :)
Daniel Buchner
45:03
It depends if your tombstoning actually deletes past data
Daniel Buchner
45:06
q+
Dmitri Zagidulin
45:07
@Juan - always a good question. and specifically for Encrypted Data Vaults, the storage server /must not/ know “who” the user is. It only cares about whether the user is holding a valid capability
Adrian Gropper
45:30
Registration is a Verb
Steve Magennis
45:45
the right to be 'forgotten' really implies more than just 'marking a chunk of bits' unavailable to an end user, possibly even extending to deleting logs of read/write
Juan Caballero
46:20
agreed-- who can roll back the write to null if the did controlling the edv deleted it?
Steve Magennis
46:22
as well as purging bits from being discoverable
Dave Longley
46:22
daniel, i think you're right that it affects "past data"/sync/replication ... but maybe that's a separate thing entirely: an operation like: "stop replicating"/"stop syncing" or a "delete" sent to /history
Dave Longley
47:01
q+
Dmitri Zagidulin
47:08
+1, good point Steve
tobiaslooker
47:23
So question is does delete extend to deleting the history?
Dmitri Zagidulin
47:24
@Dave — ooooh, nice, DELETE to /history
Adrian Gropper
47:35
See also the Audit issue in the tombstone / delete context https://github.com/decentralized-identity/confidential-storage/issues/143
Chris Were
47:52
q+
tobiaslooker
47:56
Yeah agree @Dave
Daniel Buchner
48:27
So you don't HAVE to have delete...if you never actually delete anything
tobiaslooker
48:27
One effects essentially re-writting the past vs an update to an empty document
Manu Sporny
48:57
edv/238942374/forget
Dmitri Zagidulin
49:15
Manu is making Roy Fielding cry, somewhere… (re /forget)
Andreas Freund
49:25
are we then not going to have to define the scope of delete aka specific update
Manu Sporny
49:26
edv/23947234/nuke-from-orbit
Manu Sporny
49:43
technically, Orie made Roy cry first by proposing this as a general design pattern for this group :P
Andreas Freund
49:44
that includes actually removing the physical bits on a storage mefium
Andreas Freund
49:59
LOL
Dmitri Zagidulin
50:00
hahaha nice (re Orie)
Daniel Buchner
50:10
I agree with that, and just want to have, for developers, a command called "delete", wherein it does the past history erasure of all object deltas
Andreas Freund
50:10
nuke-from-orbit … love it
Andreas Freund
50:17
q+
tobiaslooker
50:24
q+
Daniel Buchner
50:33
so for devs, they want 'delete' in a concept they understand
Daniel Buchner
50:47
even though Dave and I can be nerds about what that actually is under the covers
Dmitri Zagidulin
51:01
q+ to mention “service agreements” / configuration of the vault config
Dave Longley
51:07
daniel -- yes and there will be cases where you want to "delete" but allow for "undelete"! :) ... and that's different from taking off and nuking from orbit... just to be sure.
Dmitri Zagidulin
51:10
Terms of Service, etc.
Daniel Buchner
51:27
different permission: redoabledelete
Daniel Buchner
51:33
undoabledelete*
Daniel Buchner
51:42
permanentdelete
Adrian Gropper
51:46
What about off-line backups and forward secrecy?
Andreas Freund
51:46
LOL
Juan Caballero
51:54
delete versus covermytracks +iwasneverhere
Nader Helmy
51:57
permanuke
Daniel Buchner
51:59
edv/34635355234/manuke
Manu Sporny
52:04
nice!
Manu Sporny
52:09
nuke by hugs.
Dmitri Zagidulin
52:19
lol
Andreas Freund
52:20
I have not even gone the route of highly asynchronous data storage
Andreas Freund
53:13
what happens if a store comes online that is "pangalacticgurgler" type out of date?
Dave Longley
53:37
we need to be careful that we don't make the core too complicated ... we should be looking toward composability to solve more challenging use cases
Dave Longley
53:39
q+
Daniel Buchner
53:42
Hub's will have a single MUST on all this
Andreas Freund
53:53
the controller of the ID are not even the same anymore
Daniel Buchner
54:01
we're going to have a fractured decentralized app ecosystem if every instance defines its own concept of delete
Steve Magennis
54:03
discoverability and GDPR are very important concepts today - we ignore this at our risk
Andreas Freund
54:12
anyway … edge cases are always the hardest and should not be show stoppers
Daniel Buchner
54:30
I won't let that literally dictate that we can't have a normative spec definition for delete
Juan Caballero
54:42
your edge case is my gdpr-compliant business model ;)
Steve Magennis
54:43
I don't think these are going to be edge cases going forward
Daniel Buchner
54:46
If GDPR does that, we change GDPR
Daniel Buchner
54:55
and we can
Chris Were
54:57
lol
Daniel Buchner
54:59
royal we
Steve Magennis
55:03
go Daniel!
Adrian Gropper
55:03
Can an EDV replace my HSM?
Daniel Buchner
55:04
wanna bet?
Daniel Buchner
55:24
I have to bail, but love the direction
Juan Caballero
55:30
q+
Daniel Buchner
55:30
we will delete in harmony one day
Andreas Freund
55:32
I just call up Angela -- know her from way back when in the early 90s
Andreas Freund
55:41
i am sure she can move the mountain
Andreas Freund
55:50
since germany rules the EU
Daniel Buchner
56:08
Who can undelete depends on what 'delete' it was LOL
Daniel Buchner
56:21
was it delete delete, or like pseudo-delete
Dmitri Zagidulin
56:33
q+
Steve Magennis
56:39
just close your eyes and it all goes away...
Daniel Buchner
56:40
deletelite
Adrian Gropper
56:42
q+
Manu Sporny
56:44
#deleteNOTdelete
Dave Longley
56:45
this is why history should be different from the head document, it makes more obvious what you're affecting when you "delete"
Andreas Freund
57:14
what if permission replication is slower than store data replication
Andreas Freund
57:34
and you delete data that you no longer have the permission to delete
Nader Helmy
57:35
Interesting analogy about the filesystem/OS dmitri
Dave Longley
57:37
do you want to clear the history? or just say the document is "currently" deleted.
Manu Sporny
57:45
Dave's principle :)
Manu Sporny
58:12
... who stole it from Occam.
Chris Were
58:23
IMO “Deleted” has to mean deleted. If you don’t mean deleted, use a status = archived or archived = true.
Dmitri Zagidulin
58:28
@Andreas - re permission replication vs data replication. Excellent question. So, one thing to keep in mind is - the vault does not keep any sort of permissions or authorizations on the server side. The authorization (the “hall pass”) is always carried with each request
Andreas Freund
59:10
of course it does not
Dmitri Zagidulin
01:01:26
+1, future topic: replication of revocations
Manu Sporny
01:02:13
good point, andreas!