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.
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.
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.