W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2008

discovery and trust

From: Brian Eaton <beaton@google.com>
Date: Wed, 3 Dec 2008 15:41:22 -0800
Message-ID: <daf5b9570812031541y57286394k8b79540941022041@mail.gmail.com>
To: xri@lists.oasis-open.org, www-talk@w3.org

Hey folks -

There have been several conversations on the www-talk and xri tc
mailing lists about discovery and security. The www-talk discussion
[1] is centered around delegation of authority and questions about
which steps in the discovery process should be signed. The xri tc
discussion seems to be happening mostly on the wiki [2] and in private
e-mails, and has covered both signature format and authority to sign
documents. One of the challenges here is that different use cases
require very different levels of security, with OpenID at the high-end
and favicon.ico at the low-end. The only point everyone seems to agree
on is that simplicity is critical for adoption.

One of the really confusing points in these discussions is that we
aren't talking about the semantics of these signed documents. I'd like
to look at the OpenID use case in particular, propose a solution that
works for OpenID, and see whether it scales up well to the general
discovery problem. It may not; it is entirely possible that different
use cases require fundamentally different approaches to security. A
discovery specification should be flexible enough to support that.

One of the approaches I've considered for delegation and discovery in
OpenID is a notion of signing each link in the discovery chain. For
example, you start with a resource R and look for metadata M, possibly
following several layers of indirection in between. A site-meta file
might point in one direction, a 302 in another, a fallback rule might
give you a third pointer to follow. Trying to provide security at
every single step in that chain of trust is hard. How do you sign a
302 redirect? How do you sign a 404 that causes discovery to fall back
to another option? How do you sign a statement embedded in a blog?

In practice we wouldn't be able to find a way to sign those
statements, so we'd end up with two discovery work-flows, one for use
cases without significant security risks and another for use cases
where security is required. The secure work-flow would be more
difficult to implement since fundamental pieces of the HTTP protocol
(like 301s and 302s) would be untrustworthy. This is too complicated.

Dirk and Breno and I have been talking about a scheme that works by
following a chain of documents *until* you reach a signed document.
Once you reach a signed document you can have a delegation of
authority.  Security wouldn't depend on all of the links in the chain,
only on the signed links.  We're not quite ready to share this
proposal yet, but it seems promising.

Cheers,
Brian

[1] http://www.mail-archive.com/www-talk@w3.org/msg01941.html
[2] http://wiki.oasis-open.org/xri/XrdOne/SimpleSign
Received on Thursday, 4 December 2008 07:25:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:29 GMT