Hacker News Reader

In theory this all sounds fantastic, until you actually get to implement it and see that only a handfull of servers actually managed to implement it correctly. Probably because of its complexity. See also another comment from the Flock author: https://github.com/WhisperSystems/Flock/issues/93#issuecomme...

>I'd say WebDAV is more mature, it has litmus[1] for testing implementations.

Within the first few weeks of writing vdirsyncer's testsuite, I already found a bug in SabreDAV, which is tested with litmus. I tried to raise this hole in their testsuite on their mailing list, but at the time their mailinglist was down.

>remoteStorage has as far as I know only one production instance running at 5apps [2].

Yes, that's sad. It has yet to be proven that implementations of remoteStorage will actually become more reliable than the ones for WebDAV, but I'm confident that it's easier to get implementations right with remoteStorage.

>The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3].

SabreDAV implementing it is cool. They're the best FOSS serverside implementation of the -DAV protocols I know.

But still: It's all optional. Servers implementing all of this is a luxury. Right now we're in a situation where even the stuff that isn't optional doesn't work.

Don't trust anything just because it has been around for a long time.

(Co-founder of 5apps and RS core contributor here.)

> remoteStorage has as far as I know only one production instance running at 5apps

That's not true. 5apps is running the only public service for end users at the moment, but there are certainly more production instances running.

> The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3].

As both of these would be optional additions to WebDAV servers, all of WebDAV's benefits parish with most servers not supporting these new extensions. That's the very critique in the article as far as I understand. WebDAV alone is not good enough, and optional additions lead to a world of incompatibility and pain.

> One thing missing from WebDAV is the (implicit) mapping of OAuth scopes to ACLs, which should not be too difficult to implement

And another addition.

> I'd prefer something like OAuth authorization server discovery

And another one. Counting 4 now. :)

> but it just doesn't bring (in my opinion) many benefits and loses interop with existing WebDAV clients for no good reason

You just mentioned that to get to feature parity with remoteStorage, a WebDAV server needs 4 optional additions, for only one of which an unmerged PR to a single server implementation exists. Maybe I miss something, but it doesn't sound like interop is WebDAV's benefit in this scenario.

Ah, my point was, actually, to base the remoteStorage spec on WebDAV instead of a new JSON-based protocol as it currently exists. remoteStorage could define a WebDAV 'profile' for what needs to be supported by the server...

Yes, and then you have another optional version of WebDAV, adding to the existing mess, while you don't actually have the benefit of interop that you say would be the reason for using WebDAV in the first place.

The way I read it, that's basically the point of the article.

The linked proposal for OAuth2 discovery is broken. In most cases the client application will have to authenticate by providing client credentials that are registered with the authentication service.

A proper solution already exists and is called OpenID Connect (http://openid.net/connect/).

I'm not sure if you're claiming that the OAuth integration into WebDAV is broken or OAuth itself (because remoteStorage's integration works fine, e.g.).

I'm just saying that the mechanism to provide authorization endpoint and token endpoint to the client as proposed in https://www.tuxed.net/fkooman/blog/as_discovery.html is (in general) not sufficient. The client usually needs to provide valid client credentials in order to authenticate.

OpenID Connect solves that by extending OAuth2 with a layer to discover additional information about the authentication service (like authorization endpoint and token endpoint) and to sign up for client credentials.

There is no general issues with OAuth2 and DAV. We're using it successfully to authenticate at Google's DAV services and with Yahoo! Calendar.