[foaf-protocols] Webid Spec: HTTP status codes?
dlongley at digitalbazaar.com
Fri Aug 13 00:24:07 CEST 2010
On 08/12/2010 04:05 PM, Akbar Hossain wrote:
> Wondering if it makes sense to specify/standardise the possible HTTP
> status codes the resource you are trying to access should try to
> respond with.
> Curious how/if TLS errors/failures should be communicated back to the
> identifying agent.
> Maybe of less importance to browser usage but of value when
> considering services trying to access resources.
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
As far as I know, dereferencing the Web ID and confirming identity, etc.
happens after the TLS handshake, not during. I assume this is the
process that would be generating the errors you're talking about.
It would require a lot more work and modifications to servers to do it
differently. My understanding is that Web ID can be implemented fairly
easily on an Apache php server by getting the client-side certificate
from a global var (which is populated by setting a configuration option
in Apache) and then checking its public key against one that is
retrieved from the Web ID url. This is all done post-TLS-handshake. If
I'm wrong about this hopefully someone will correct me.
That isn't to say that we shouldn't necessarily standardize on error
conditions that can be sent back to the identifying agent. I would just
expect them to be sent over HTTP, not within the TLS protocol as alerts.
There may also be timing attacks and other implications should the Web
ID url deferencing+public key checking happen within the TLS handshake
-- and we would just want to avoid dealing with that entirely.
Again, perhaps an idea worth exploring, but I recommend that it be
outside of the TLS protocol.
Digital Bazaar, Inc.
More information about the foaf-protocols