Berlin meetup 2011

From WebID Wiki

Berlin Meetup

The meetup took place together with the Federated Social Web Meeting in Berlin. Some very incomplete minutes were taken, so this wiki page will aim at completing the conversation. Please fill in what you remember took place at the various sessions.

Friday 3 June

There were two sessions on Friday, a morning and an afternoon session.

Morning

Present

  • Henry Story
  • Dan Brickley
  • Mike Jones (Uni Manchester)
  • Evan Prodromou (Status.net)
  • Martin Gaedke
  • Andrei Sambra (MyProfile Project)
  • Julia Anaya
  • Bergi
  • Dominik Tomaszuk
  • Yngve Petersen
  • Blain Cook
  • Hendrik Gebhardt
  • ....

Presented WebId Identity in Browser video and the USB crypto stick video too.

Dan Brickley drew up a WebID complexity chart

.

The graph shows how quickly things can get out of hand, if we don't limit the core somewhat. There was consensus on limiting the scope initially at least.

  • RDF/XML, and RDFa as a must for syntax understanding
  • http, https URLS as a MUST for URLs
  • cert/rsa ontology as a MUST for ontologies (with possible merger of cert and rsa namespaces)

Blain argued that it was not necessary to have accnt:joe@gmail.com urls in the core of WebID. Accnt urls were more for human readability, whereas WebId hides the URL in the X509 Certificate, so it is no longer something that needs to be remembered.

Afternoon

Test cases were discussed. Mike Jones defended the Waterfall model. But someone with experience from the XMPP work pointed out how important implementation and feedback from work was. It was also pointed out that "An interoperability report on existing WebID implementations" made test cases a part of the XG's deliverables. Test cases could be create a dynamic report whose final version could be published for the final report.

Multiple URIs in SANs

Mike Jones argued that: "The SubjectAltName MUST contain at least one WebID URI. It MAY contain more than one URI, but if it does each URI SHOULD point to the Same Document Content (i.e. mirror). If the URIs do not point to the same document the server SHOULD resolve all URIs and construct a single graph. If the Server does not resolve all different URIs then any resulting authorisation decision will be undefined. I think this is what I meant!"

Bblfish argued: "That we need clearly written out use cases to understand precisely why the documents at each WebId should be the same. This does not a priori seem clear."

Critical extensions

We discussed if we can ignore critical extensions on the SSL layer and how this can be done with an Apache server. The conclusion was, that it is an option in the OpenSSL library or Apache which must be set at compile time.

Spec

There was agreement that more work needed to go in improving the spec. (was that in this session?)

Saturday 4 June

Federated Social Web talks

Foaf Workshop

  • OStatus and LinkedData discussion: This was tuned to looking at what the semweb can learn from the OStatus stack, what advantages it offers and what limitations are. This was a very initial discussion to get some thoughts rolling.
  • A brief conversation about Atom and Publish/Subscribe pattern vs. WebID and Semantic Pingback.

WebID Workshop

  • Delegation issues are important for Federated Social Web Servers (ie: servers larger than freedom boxes, with multiple users).
    • servers could pretend to be a user, by adding a public key to each users profile in order to then pretend to be that user. But this would be very costly for larger servers, that would need to create seperate TLS sessions for each user.
    • Servers could identify themselves with their own WebId (a srv: Subject Alternative Name, and a URL one perhaps) and each user on that server could identify that server as their "butler". But then the Relying Party that server would connect to would not be able to distinguish any of the different users of that server. The communication would be a lot more efficient between two larger providers though.
    • What seemed to be missing would be for a WebID server to connect to a remote server as itself, but ask for WebResources as if it were a particular users. Perhaps an HTTP "Connect As: {webid}" would allow such a message to be passed.
    • Mike Jones mentioned RFC3820 (TLS proxy spec) as relevant for delegation of identity and not delegation of authority. Is not efficient enough for servers with many users, and does not allow agents to take an independent action.
( The discussion was then continued in even more detail on Sunday at C-Base. See write-up there. So the server needs to - and indeed can - pretend to be the user. What issues then does that bring up....)
  • SSL Browser efficiency issues were brought up by Yngve Petersen (summary?)

Sunday 5 June

Chat with Bergi on Test Suite

Bergis current Test Suite for WebID endpoints is based on Java and JUnit. To test an endpoint it's required to have a test page which presents the results in RDF/EARL format.

Every test case follows this procedure:

  1. generating the WebID certificate - can be broken
  2. creating the corresponding RDF document - can be broken
  3. write the file on the server
  4. try to login to remote services
  5. verify the EARL result with an SPARQL query

Some examples and where they differ from the default:

  • missing RDF: don't run step 2
  • wrong modulus/exponent: manipulate RDF document in step 2a
  • multiple URIs: add additional URIs in step 1

Results:

  • This test suite plus the endpoint test pages should help finding gaps in the spec.
  • To test caching long running tests are required which aren't possible with the current architecture.
  • The spec could allow endpoints to handle multiple URIs in two different ways:
    • Secure mode: Every URIs must be reachable and verifiable.
    • High availability mode: Any URI which is reachable and verifiable is accepted.
  • The test should run regular and generate a matrix of features supported by the endpoints.

We need to develop a EARL ontology for these meta test suites

Evening at C-base

very detailed discussion with Mike Jones on delegation. (bblfish will write up the diagram and arguments)