- Yogesh: a couple of viable candidates- one is the HTTP extension.
Good time to revisit that solution. 2nd approach - webDAV. Reactions
were varied
- performed an analysis - this could work with minor tweaks but a deep
dive is needed
- Roundtrips requirement: idea is that enough information is needed
from both participants that there has to be a back-and-forth. Are
new resources created, the same ones modified? How can the
participants take turns?
- ECR: if everybody here wants a new thing, but it isn't the best
thing you are probably still farther ahead. Question is, what is the
energy level of the group? Is anybody advocating for webDAV that is
also going to implement?
- Brad L - it is worth exploring, then comparing.
- ECR: Can think of ways to do this: files indexed by numbers, eg
mesgs from alice to bob are odd, from bob to alice are even etc.
Whether using WebDAV or not, the more like a drop box this is, the
happier we will be.
- Eric: not sure I want my door locks to have more webDAV. Reasoning
about what is the shape of what we build is valuable. Then you can
look at each implementation option to see the delta. Understanding
conceptual thing this is analogous to could have great value, eg:
drop box.
- Yogesh - agree the drop box is a good analogy. Goal here is to
discover whether vanilla webDAV can work, but clearly that can't. Do
we want to go down the rabbit hole just because we are obsessed with
webDAV?
- Eric - worth looking at what is the delta rather than jumping away
from webDAV without going to the "other" answer automatically
- Kaliya: question - when you say credential do you mean password? Is
this like the encrypted data vault work, using obj capabilities to
access cloud repositories?
- Yogesh - credential is loaded term, here a credential is a set of
cryptographic tools that grant access to some property (and some
metadata). If I get a key to my hotel room but it isn't valid until
3pm, for example this could be the basis for additional access
control
- ECR: (question & following discussion is opaque to the scribe,
sorry)
- conversation about locking vs. deletion of credential during
transfer
- Eric: if I am sender A and i send to receiver A, if random attacker
can access that, that is bad. Theft, interference, incompetence,
tampering, that will be an issue
- Yogesh - the problem is that webDAV defines access control
mechanisms that are more open than we want.
- Eric - in my mind, webDAV - not about does the thing we build on top
of satisfy all the req'ments, just is it a place we can start.
Details that create question marks may be worth doing the exercise
to address. Access ctrl vs locking is something we can identify, but
wouldn't be the end-all be-all. Looks like you have sufficiently
identified the issue, so we are good.
- Leif - to summarize, this comes down as "operational considerations"
- doesn't necessarily mean webDAV has to change, maybe it just gets
profiled down. Not a problem if something like webDAV has to be
profiled
-
Yogesh - trying to know what is easy and what needs more work.
another requirement for webDAV is connection integrity
- need to ensure injection isn't possible
-
3rd requirement: non-correlation. prevention of correlating users
between exchanges, prevention of mapping social graphs
- found areas without answers - how, if authentication is needed,
the server won't be stored?
-
Aaron: lot of parallels to other work (eg in OAuth WG). These
requirements have been discussed there and so you should be able to
leverage existing building blocks. WebDAV seems not to fit perfectly
but there could be other options. tomorrow's OAuth meeting may be
useful, verifiable credentials will be discussed and this may be
helpful.
- Prachi requested Aaron to review, Aaron agreed.
-
ECR: asking about access control in webDAV
- wrestling with the web model. Treat this like a read-write
transaction on a resource, your issues go away entirely. Will
send something to the list
-
Eric: step 1 is establishing it is "mine" so I can come back. I
leave a space open for "slot #2", once slot 2 is filled, then that's
it. After that, the establishing token and the token in slot 2 are
the only participants that can interact.
- Speaker #2: Understand solution isn't perfect, but privacy is
preserved
- Aaron: Capability URLS are not necessarily best security practice
(EKR disagrees). problem with capability URLs is it is same string
used by sender/reciever. Have fundamental problems, and many groups
are working on solutions. Could be a solution that doesn't rely on
the URL being the only thing protecting the credential stream.
- Eric: let's not rathole on details, but talk about what are the
building blocks
- Yogesh: mechanisms will change - what we are trying to build is
based on intention to share a credential
- Speaker #2: still want attestation
- John B: what does support for WebAuthn mean? Hybrid transport exists
now where a piece of key material is exchanged that could accomplish
this.
- Brad: what are you attesting?