Re: WebID error handling

Henry,

what I had in mind is a successful TLS connection but RDF cannot be
loaded from the WebID URI (e.g. connection refused).

A concrete case I have is:
- user launches a service locally which generates a localhost WebID for him/her
- user clicks an external link which leads to a WebID-TLS protected server
- user chooses the localhost certificate in the browser prompt
- the external server throws an HTTP error ala "Connection to localhost refused"

That is technically correct but not great for user experience. The
user is following simple and completely legitimate steps yet they end
up in an error.
I am looking for ways to avoid it and so far the best option IMO is to
silently ignore WebID loading errors and default to unauthenticated
access.

Martynas

On Tue, Jan 21, 2020 at 12:12 PM Henry Story <henry.story@gmail.com> wrote:
>
>
>
> > 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:26:52 UTC