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

Great discussion folks!

I think this thread should give the w3 folks we are CCing here a good idea 
of the passion, quality of work, depth of discussion and breadth of the foaf+ssl 
community, which includes hackers from every programming language, researchers
from every continent, security as well as linked data specialists, and more.

Perhaps we should leave them a bit of time to digest the details of this thread,
so they can then let us know how we should proceed.

No need to work out the final details of the spec right now :-) Let us leave ourselves a bit of work for when we get round to the formal piece.


	Henry

P.S. Is there a record for the fastest WG spec produced by the W3C which we could
beat?



On 6 Jul 2010, at 20:05, Toby Inkster wrote:

> 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:58:38 UTC