- From: Henry Story <henry.story@gmail.com>
- Date: Tue, 21 Jan 2020 12:12:52 +0100
- To: Martynas Jusevičius <martynas@atomgraph.com>
- Cc: public-webid <public-webid@w3.org>
> On 21 Jan 2020, at 11:45, Martynas Jusevičius <martynas@atomgraph.com> wrote: > > Hi, > > Does WebID-TLS specify anything related to error handling? I am not > able to find anything in the spec. > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html > > Should a WebID that fails to verify (e.g. URI does not dereference) > throw an error or simply be ignored and treated as no authentication? > I am leaning towards the latter due to a potentially common failure > using localhost WebIDs (below). I guess that in a way if the X509 Certificate is self-signed then the TLS connection succeeded (the private key was verified), but the WebID was not. If you send an error message back using the TLS channel then you can’t explain the problem. If you accept the the TLS connection you can send an error message back along HTTP with an error code, but then you need to find a way to break the TLS session too. > The thing with localhost WebIDs is that they can work on the same > host, but it will fail to dereference in any decentralized scenario. > Should WebID-TLS make a special mention of this? Well that is a problem mostly for developers and there is no interoperability question there since every developer could do things differently without impacting the protocol. The problem with TLS is that it does not fit well with HTTP2.0. There have been proposals to solve the client reconnection problem but I am not sure where they have lead to. Perhaps have a look also at a version that could use HTTP Signature. https://github.com/solid/authentication-panel/blob/master/HttpSignature.md Http Signature is now being considered by HTTP WG. Henry Story > > Martynas > atomgraph.com >
Received on Tuesday, 21 January 2020 11:13:00 UTC