Zoom Logo

Secure Data Storage - WG - Shared screen with speaker view
Dmitri Zagidulin
01:30
@tobias - do you mind doing the intro today?
Dmitri Zagidulin
04:55
np!
tobiaslooker
05:01
Apologies missed this message in chat :)
tobiaslooker
05:39
https://github.com/decentralized-identity/edv-spec/issues/11
tobiaslooker
06:01
https://github.com/decentralized-identity/edv-spec/pull/17
tobiaslooker
07:04
https://github.com/decentralized-identity/edv-spec/issues/11#issuecomment-829585284
Manu Sporny
07:31
q+
Manu Sporny
07:58
https://github.com/decentralized-identity/edv-spec/pull/17/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R2332
Juan (DIF/Spruce)
08:31
dirty delete is fine
Manu Sporny
10:46
q+
tobiaslooker
11:20
https://github.com/decentralized-identity/edv-spec/issues/10
Manu Sporny
12:43
q+
Daniel Buchner
12:58
sorry for being late
Dave Longley
14:13
q+
Manu Sporny
17:11
q+
tobiaslooker
17:18
https://github.com/decentralized-identity/edv-spec/issues/12
Daniel Buchner
17:32
YESSSS!
Daniel Buchner
17:42
DID Service Endpoints, baby!
Dmitri Zagidulin
17:43
it is if you give people subdomains!
tobiaslooker
17:53
q+ ^
tobiaslooker
18:02
To make that point
Troy Ronda
19:23
Or those of us who end up doing both .well-known for domain-level discovery and WebFinger for resource level discovery :).
Troy Ronda
19:35
(Not so far in EDV though).
Dave Longley
20:35
q+
Manu Sporny
20:49
q+ to "give people subdomains" solution
Manu Sporny
21:29
q- 'cause Dave is saying what I was going to say (and more!)
Dmitri Zagidulin
22:02
q+
Dave Longley
22:57
q+
tobiaslooker
23:56
q+
Adrian Gropper
24:14
q+
Dmitri Zagidulin
24:42
thw question for the group is - so what should we do w that issue?
Manu Sporny
25:55
In other words, you will be forced to use HTTP Signatures -- you will have no other choice.
Dave Longley
25:59
creating mutually exclusive feature sets is problematic.
Dmitri Zagidulin
26:05
standard practice for multi-tenancy definitely includes subdomains
Dave Longley
26:24
(and some people are getting burned right now because of it)
Dmitri Zagidulin
27:04
makes sense. but it’s also true that many people have been burned with a directory based tenant approach
tobiaslooker
27:19
I agree there is complexity to work through here, complexity that appears only to be increasing with the browsers current war on anything cross site/domain
Dave Longley
27:34
yes, there are trade offs with both approaches -- which is what i'm trying to highlight ... we have to be careful that we don't force people in one direction in order to use the features we need here.
Dave Longley
27:57
q+
Dmitri Zagidulin
29:10
q+ for next steps
Manu Sporny
29:51
q+ to approach it from the bottom of the stack.
Troy Ronda
30:17
Is the question basically should this be discoverable on a domain basis, on a URL basis or both?
tobiaslooker
30:37
q+
Dave Longley
31:22
yeah, we should be defining what the use case is here for finding the `<base>/edvs` endpoint
Dave Longley
31:50
e.g., what data/params/inputs do you have to start with?
Dave Longley
32:04
q+
Dmitri Zagidulin
32:15
ai also want to point out that the current edv spec assumes “magic” well-known endpoints
Dmitri Zagidulin
33:39
q+
tobiaslooker
33:40
q+
Manu Sporny
33:49
https://github.com/decentralized-identity/edv-spec/issues/25
Manu Sporny
33:53
^^^ just raised that
tobiaslooker
33:59
Thanks manu
Adrian Gropper
33:59
+1 to discovery use cases first
Dave Longley
34:03
that's not a use case :)
Dave Longley
34:14
why would anyone have a domain and be looking for an edv on it?
Dave Longley
34:17
q+
tobiaslooker
34:34
Yeah +1 to Dave :)
Juan (DIF/Spruce)
34:40
hehe
Juan (DIF/Spruce)
34:44
didn't wanna be the one to say it
tobiaslooker
34:51
Why does Alice have a domain :)
tobiaslooker
34:55
How did she get it
Juan (DIF/Spruce)
35:02
alice is walking home from the domain store...
Dave Longley
35:06
+1 to tobias
Manu Sporny
35:24
https://github.com/decentralized-identity/edv-spec/issues/25
Adrian Gropper
35:29
q+
Manu Sporny
35:54
yes! to Adrian
Dmitri Zagidulin
36:31
+1 adrian
Manu Sporny
36:37
q+
Dmitri Zagidulin
36:37
the configuration part is important
Dave Longley
36:52
+1 we want (potentially) to "discover" config/API endpoints, not individual EDVs
Dmitri Zagidulin
38:20
q+
Daniel Buchner
38:27
q+
Troy Ronda
38:33
What about the configuration aspect?
Dave Longley
38:40
yeah, the "i'm a website and need to write to your personal storage, so please give me authz and tell me where to write" use case is different from this "discovery" one i think.
Manu Sporny
39:31
q+ to be confused about "configuration" discovery.
Dave Longley
39:34
dmitriz, could you formulate the use case you mentioned in terms of personal/machine actors and what they need to do?
Dave Longley
39:40
and why?
tobiaslooker
40:23
q+
Dave Longley
40:41
for example: "I'm a web dev and my web app needs to store users' personal data, so I need to be able to ask them for authz to an EDV of their choice" <-- this is different from the use case you mentioned, can you state it similarly?
Troy Ronda
40:53
A full configuration URL shouldn’t be specific to a vendor.
Troy Ronda
41:10
Someone might know their edv as https://example.com/myedv
Dmitri Zagidulin
41:17
q+
Troy Ronda
41:24
Not https://example.com/myedv/vendorabcconfig.yaml
Manu Sporny
41:44
Yes, but why?
Manu Sporny
42:26
q+ subject to exposure from config API
Manu Sporny
42:46
I do think that discovering/getting the configuration is important... but is that discovery?
Dave Longley
43:13
in the CHAPI use case you are handed the URL for the EDV and its config, etc. -- so there's no "discovery" needed
Troy Ronda
43:41
I agree that it’s better to base on resource URL not on a configuration file URL.
tobiaslooker
44:23
This is really just driving out the need to have use cases documented
tobiaslooker
44:38
We are all having conversations assuming different inputs or starting positions
Dmitri Zagidulin
45:03
-1 to crawling
Dave Longley
45:04
what's the situation someone would be in where they didn't have the config URL but they would have the domain? why would this happen? ... who would go "oh, hey, i need to create an EDV on example.com, i wonder what its API endpoint/config is"
tobiaslooker
45:29
q+
Dave Longley
46:23
q+
Troy Ronda
46:34
Or do GET on the EDV URL and get the config back :).
Manu Sporny
47:02
yes :)
Troy Ronda
47:11
Like ActivityPub Actor Objects.
Manu Sporny
47:15
Why doesn't that work for all use cases? :P
Daniel Buchner
47:42
q+
tobiaslooker
47:50
+1 Dave is that two levels of discovery, EDV server discovery and EDV instance discovery
Manu Sporny
48:07
yes ^^^
Dmitri Zagidulin
48:11
the main scenario is - you start with a url to an individual edv document
Dmitri Zagidulin
48:28
and need to access that document’s vault config
Ian Davis (he/they)
49:00
q+
Dave Longley
49:27
@dmitriz -- i think if you have a URL to a specific edv doc, you can just use the spec to find the EDV config.
Dave Longley
49:35
because there is only one legal way to do that.
Dmitri Zagidulin
49:56
and what is that way? using a well known url template?
Dave Longley
50:03
<foo>/edvs/<edvId>/documents/<docId> <-- you just walk back to <foo>/edvs/<edvId> and do a GET on its config
Daniel Buchner
50:05
Agree
Daniel Buchner
50:14
Actually an anti-pattern
Dmitri Zagidulin
50:17
ok thats just a well known url structure
Dmitri Zagidulin
50:20
an anti pattern
Manu Sporny
50:27
why is it an anti-pattern?
Dave Longley
50:57
i think carving out spaces for paths is not an anti-pattern, taking over the namespace world on a server is
Daniel Buchner
51:09
crawler use case of finding lots of openly published data should be: you go to a decentralized registry where someone has associated a DID with a datastore, and you can iterate the ones you find there
Daniel Buchner
51:25
Why not have that be a DID
Daniel Buchner
51:26
?
Daniel Buchner
51:29
q+
Troy Ronda
51:38
Anyways. I think the EDV URL should mean the config, and from there I get endpoints and any other needed config.
Manu Sporny
52:10
^^^ I'd be fine w/ that
Manu Sporny
52:14
(what Troy just said)
Manu Sporny
52:25
I'd also be fine w/ well known URL structure.
Dave Longley
52:46
well, if you dont' have a well known URL structure you can't start from a doc URL and get back to the config URL.
Manu Sporny
52:49
q+
Dave Longley
52:56
the spec already has the well known structure today
Daniel Buchner
53:09
yep
Dmitri Zagidulin
53:54
q+
Daniel Buchner
54:43
I didn't mean anti-pattern for that
Dmitri Zagidulin
54:56
it’s an explicit well known mechanism as opposed to a silent implicit pattern
Daniel Buchner
55:02
I meant anti-pattern being that an host lists all the DIDs of who uses them
Dave Longley
55:09
+1 the anti-pattern is saying where the "root" MUST be for a path -- vs. allowing the server admin/app dev to decide that.
Dave Longley
55:53
IMO, not an anti-pattern: <anything>/edvs/<spec-defined>
Dave Longley
56:07
IMO, anti-pattern: /must-be-root/<spec-defined>
Manu Sporny
56:08
4 minutes... GO! :P
Dave Longley
56:09
q+
Dmitri Zagidulin
56:27
wait dave thats the same thing
Manu Sporny
57:02
A counter-proposal needs to be put forward... we need to weigh the current solution against another.
tobiaslooker
57:07
Yeah +1 Carving out a namespace vs imposing where it should exist in your websites namespace is totally different
Ian Davis (he/they)
57:14
q+
Troy Ronda
57:18
How many solutions are currently on the table?
Manu Sporny
57:25
I have no idea :P
Troy Ronda
57:38
:)
Manu Sporny
57:47
We should focus the problem to "I want to find an EDV configuration"
Dave Longley
57:52
dmitri -- hopefully i explained the difference.
tobiaslooker
57:55
q+ to round up issue discussion
Dave Longley
59:08
dmitriz: /you/can/do/whatever/you/want/<some spec takes over> vs. /<some spec-takes over>
Dmitri Zagidulin
59:24
both are bad tho
Dave Longley
59:33
we'll have to hear about that next time! :)