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

On Tue, 06 Jul 2010 17:17:02 +0200
Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> wrote:

> 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.

I'd say that FOAF+SSL implementations *must* accept any RDF
serialisation that is a W3C Recommendation. Right now, that's RDF/XML,
XHTML+RDFa, and arguably SVG (which allows both RDFa and RDF/XML to be
used within it). Implementations *may* accept other formats and
*should* list formats they support in the HTTP Accept header.

WebIDs *should* be served in at least one of the recommended formats,
and *may* be served in other formats via connection negotiation.

> 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.

The WebID should identify the thing that instigated the HTTPS request.
In my opinion any entity capable of instigating an HTTPS request may be
classified as a foaf:Agent.

> 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).

I have had at various times multiple keys associated with my WebID. I
find rdfs:label works fine for that.

> 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?)

My library currently allows it, and checks each until it finds one that
"works".

>    - 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?

This doesn't seem like something that needs to be standardised. Maybe
an implementation note as an informative appendix?

>    - Do we want to address the potential dual role of an X.509
> certificate: as a WebID certificate and as a "normal" PKI certificate?

I don't think we need to. A client presents a certificate to the
server. The server can choose to authenticate that certificate using
FOAF+SSL, but it may instead choose to authenticate it by some other
method (e.g. comparing the RSA key to some value in a local store).
Other methods of authentication are beyond the scope of FOAF+SSL. We
should just mention that they exist.

> 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?

I can see value in standardising this. But I don't think we should
clutter up the core specification with it. It may be worth leaving it
out of the initial round of standardising, as I get the impression that
it might still need a little time to evolve.

> 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?

Do we have a good solution for this yet? If we do, then by all means
include it. But if we don't, this seems like something slightly
orthogonal that can probably be plugged into implementations at a later
date.

> 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).

Agreed. We don't need it as part of the WebID spec. Once a client is
authenticated, what the server does with that information is its own
business.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Tuesday, 6 July 2010 18:06:34 UTC