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

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