[foaf-protocols] Webid Spec: HTTP status codes?
henry.story at gmail.com
Fri Aug 13 00:39:48 CEST 2010
On 13 Aug 2010, at 00:24, Dave Longley wrote:
> 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 is indeed the most obvious way to implement it.
Recently Reto tried something different in Clerezza. He put the handshake
in the TLS session. Here is the Scala code
We are playing with this to see what advantages or disadvantages it brings.
One advantage is that one could if WebId auth fails, try normal CA auth.
So if people have ideas of things we can explore in this space, let us know...
> 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.
> Dave Longley
> Digital Bazaar, Inc.
> Phone: 540-961-4469
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols