Re: [foaf-protocols] Standardising the foaf+ssl protocol to launch the Social Web

Hi all,

I'll start by a list of points that could be standardized (open questions).

First, on the authentication part:

1. Standardizing the representation format: RDF/XML, RDFa, N3?

   We do need a common format that representation consumers must be able
to understand and that representation publishers must produce.
We've had issues with the libraries we've used. I think it's fair to say
that existing RDF libraries can generally accept RDF/XML more often or
better than they accept RDFa or N3.


2. Standardizing the vocabulary.

   We've assumed that WebIDs were for foaf:Agents, but in fact, any
resource could be linked to a public key. We don't strictly depend on
FOAF in that respect.
We may need to improve the cert. ontology, in particular to support DSA
keys and to support naming/identifying each key (in case there are
multiple keys associated with one WebID).


3. Standardizing the data we expect to store in the X.509 certificate.

   - How to interpret the presence of multiple subject alternative name
entities in an X.509 certificate? (Should this be allowed?)
   - We've considered using a convention for the issuer name (to
circumvent the problem of choosing which certificate to present from the
certificate_authorities list in the CertificateRequest TLS message). Is
it worth doing here?
   - Do we want to address the potential dual role of an X.509
certificate: as a WebID certificate and as a "normal" PKI certificate?


4. Standardizing the delegated login procedure.

   We've done some work to allow non-SSL HTTP servers to consume
assertions regarding the verification of a WebID certificate from a 3rd
party (similar to what other protocols do by delegating to an identity
provider). Should this be part of this specification or another
specification?


5. Addressing the issue of signed RDF assertions or comparison with
other repositories of keys.

   So far, we've been using a simple dereferencing of the WebID to do the
verification. It's OK, but it doesn't really improve the security
compared to OpenID. There is potential to improve the security by using
the keys of course. How far do we want to go there?


Secondly, on the authorization part, it's all the work about ontologies
for ACLs. Should this belong to the same specification? I see this as a
separate issue (although equally interesting).



(Here, just a few brief answers.)

On 06/07/2010 10:30, Thomas Roessler wrote:

> To me, some of the interesting questions are:
>
> - Where do the use cases for the two protocols overlap?

  The notion of global identifiers.

> - Where do the use cases *not* overlap?

  - Attribute exchange was retrofitted into OpenID, whereas it was built
into FOAF+SSL from the start, due to the RESTful/linked-data nature.
  - FOAF+SSL makes use of public key cryptography, which we could use to
enhance a number of security aspects of identity and trust management.
In particular, we could have WebID consumers (the websites that would
let you log on with a WebID) obtain the public key itself and use a
higher level of assertion regarding to the person holding the private key.

> - What are the benefits of using one over the other in the cases
> where they overlap?

  - Obtaining information about a WebID can benefit from the ontologies
and the uniform interface of the web (discovery by dereferencing).


Best wishes,

Bruno.

Received on Tuesday, 6 July 2010 17:41:30 UTC