Why is WebDAV not sufficient

[bslassey]

This question was asked at IETF 114 and should be addressed in the Review of existing solutions

[castiz]

Looking at the comments, I think @ekr suggested this. Eric, what part of the solution were you envisioning replacing with webDAV? I wasn't sure if you're thinking of replacing the relay server or some other element.

[ekr]

Yes, my question was why the relay server can't simply be a profile of WebDAV. Your main critique of S3 is that it is proprietary, but WebDAV is not.

[castiz]

In theory, we could rewrite the solution to use WebDAV. Some of the functionality matches, like the lock & unlock verbs. WebDAV isn’t widely supported by Web Frameworks out of the box so it seems like an extra barrier to entry for implementing a solution and would reduce the number of entities that would adopt a standard. Could you elaborate more on where you see the benefits of adding WebDAV to this solution?

[ekr]

Sure. It provides pre-existing functionality that you would otherwise have to invent.

[castiz]

In my opinion, the main reason not to use it is because it is not widely supported by web frameworks. We want to make sure there are limited barriers to entry, and use widely accepted technologies. I'd love to hear other's thoughts here though. @bslassey @nicksha what do you think?

[ekr]

What do you mean "by Web frameworks"? For instance, which frameworks?

[bslassey]

I have the same question as to what you mean by "web frameworks" here. There are certainly many implementations of WebDAV in existence already, so I would be in favor or reusing existing tech rather than inventing new things.

[castiz]

Sorry maybe I didn't use the best wording. So if we used webDAV instead of an intermediary server, wouldn't both iOS devices and Android (etc) need to support webDAV? I am pretty sure iOS does not already, and based on my limited knowledge it doesn't seem Android does either. I see there are some webDAV apps, but presumably the credential management app would need to use webDAV in some capacity.

Let me know if you were envisioning something else and I'm not understanding?

[dimmyvi]

Hi Eric, thanks for clarifying the question. While the solution to the problem can be implemented in a number of ways, including, but not limited to, WebDAV, S3, Signal, etc, we believe that the complexity of implementation for the particular problem that we had, would be much higher if we chose other protocols. We have a problem transferring sensitive credential info between 2 mobile devices, want users of these 2 devices not to be traceable during the exchange, users to have the best and easiest possible experience, transfer to be done just between 2 particular devices. WebDav (or other alternatives fo that matter), will require a some sort of full-fledged web server (such as Apache, Nginx or other similar solution). We don't believe, that implementing a web application with just just 5 HTTP endpoints is heavier, then taking an existing WebDav implementation and updating it to address our requirements. Please feel free to disagree, but the Relay server app, as we propose, can be implemented by 1 developer in just a few weeks (depending on additional tweaks - such as integration with PushNotification servers or validation of WebAuthn) , while setting up an Apache server and extending it's functionality with manual code, just to reuse an existing web server that supports WebDav (half of which functionality we don't really need for our use case) requires a person who has deep knowledge in particular implementation.

[bslassey]

@castiz from some quick google searching, it seems supporting WebDAV with existing Android APIs is relatively strait forward.

@dimmyvi I think you overstate the complexity of an implementation using WebDAV.

But, at a higher level, for this document we're describing the requirements and why various existing technology doesn't meet them. From everything I've read here so far, WebDAV is a perfectly valid option.

[ekr]

But, at a higher level, for this document we're describing the requirements and why various existing technology doesn't meet them. From everything I've read here so far, WebDAV is a perfectly valid option.

I think this last sentence is the main point. It seems to me that this document should largely stick to the requirements for what the system needs and not why they can't be met with existing technologies.

[dimmyvi]

I can agree with the statement, that requirements should stick to what the system needs. Bringing it to review with the community is certainly more coming for an advice, not dictating the technology to solve the problem. If someone makes an effort to propose an implementation involving other technologies than we proposed in Tigress, that better align with the requirements, this certainly should be reviewed and considered.

[dimmyvi]

alternative solutions, including webdav are in scope for tigress - a new requirements document with sample implementation based on WedDAV was published on 17 Feb