- From: Harry Halpin <hhalpin@w3.org>
- Date: Sat, 10 Jul 2010 18:34:22 +0100 (BST)
- To: "Henry Story" <henry.story@gmail.com>
- Cc: "Toby Inkster" <tai@g5n.co.uk>, "Bruno Harbulot" <bruno.harbulot@manchester.ac.uk>, "Thomas Roessler" <tlr@w3.org>, "Tim Berners-Lee" <timbl@w3.org>, "Harry Halpin" <hhalpin@w3.org>, foaf-protocols@lists.foaf-project.org, "Ivan Herman" <ivan@w3.org>, "Ian Jacobs" <ij@w3.org>, "Jeffrey Jaff" <jeff@w3.org>, "www-archive" <www-archive@w3.org>
> 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. > Digesting. Overall, great to follow, +1 to Bruno's points re security. Note that the last e-mail was sent with my "Social Web chair/Uni. of Edinburgh" hat on, not my W3C hat on. With a more W3C hat on.... I think my last e-mail was not concrete enough about the role of the W3C and how Working Groups form. The Social Web final report will try to put forward some overview of the landscape and possible role for the W3C, but it will *not* be definitive, it will be a suggested roadmap to the W3C. The decision for actual standardization that rests with the W3C management and membership. The usual process, which I would assume would happen and be recommended by the W3C final report, could involve a workshop that looked at what worked and what failed on work in digital identity. The discussion around this would happen after the Social Web XG's final report I think, i.e. it would be drafted in August/Sept. As there is a large number of identity specs out there, and the workshop could identify their overall space and maturity. However, it's important that all communities get involved in the identity space can be involved, and their specs and backing also be understood. My earlier recommendations (the wikipage on member supporters and clarifying the concept's relationship with other identity work) would be essential to allow the W3C management and membership get a grip on FOAF+SSL, and every other proposal as well. Whether or not that workshop or the Social Web final report leads to a workshop that then leads to standardization would be too hard to say at this point, but there ideally would be a clear emerging consensus and desire to do so by the various identity communities and vendors. However, there is no guarantee for future standardization in this space from the W3C - for example, a competing W3C effort that did not work with other communities would only fracture the space further, which the W3C wouldn't want to do. The W3C works best to help build consensus, and this would work with the identity space as well as any other. Let's aim high and get the work done. To put the Social Web XG hat back on, I think that the main task now is to build a clear draft overview of the identity space for the W3C, i.e. the "overview" and "gap analysis" of the final report. > 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 Saturday, 10 July 2010 17:34:34 UTC