[foaf-protocols] fleshing out foaf+ssl terms, including https proxies.

Peter Williams home_pw at msn.com
Wed Sep 30 18:37:57 CEST 2009


 

 

-----Original Message-----
From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story Henry
Sent: Wednesday, September 30, 2009 8:41 AM
To: Peter Williams
Cc: foaf-protocols at lists.foaf-project.org; 'Tournoud Damien'
Subject: Re: [foaf-protocols] first implementation of foaf+ssl for Drupal

 

 

On 30 Sep 2009, at 17:23, Peter Williams wrote:

 

> Out of interest:

> 

> 1. if the resource authority web client is configured with an https  

> proxy

> (when de-referencing an https-form webid), can/should the client  

> issue a

> CONNECT to create the (ssl) tunnel between proxy and web server of the

> claimant's foaf file?

 

Why is this a question for Damien?

 

[Peter Williams] 

 

[Peter Williams] It was not directed to Damien. It's an open question. (The
organization of mail headers is whatever Outlook mail client decided to do.)


 

[Peter Williams] Before I perform the experiment using the source code
(learning all the tools etc), I have to at least understand it. Then I can
really find out what Drupal etc is - so I can re-build the experimental
apparatus. I have to figure where my own sparql server (built on sqlserver
2008 db, from intellidimension) fits into my version of the apparatus, too.

 

 

I am not sure what the resource authority web client is. I suppose you  

mean a browser behind some firewall containing a foaf+ssl enabled  

webid, that would have to be set up to use a https proxy.

 

If so, then that is not a problem for Damien, as he is building a  

server application.

 

[Peter Williams]  We know foaf+ssl has a claimant (with a self-asserted cert
bearing a webid) attempting to get access to a (Drupal-mediated?) resource
at some address.

 

[Peter Williams] Ultimately, foaf+ssl's access controls will be put into
effect, limiting user access to the resource. These controls will based in
part on the evidence from a foaf+ssl protocol run. This resource (like a few
trillion others) has a resource authority, who names it, locates is,
controls it, etc etc. The resource authority may be as simple as a webserver
with CGI capabilities, and its SSL server role necessarily configured to
require SSL client certs). It may be as complex as a Drupal server (a
content management system, I'm guessing, from 2m looking at the website).

 

[Peter Williams] We know that this https server's thread/CGI takes the webid
from the client cert presented by the SSL record layer and makes a
server-initiated http/https connection to another server hosting the foaf
file for the claimant's webid. Though this connection is "server-initiated",
it's  just an http/https web client which may be supported by a proxy (like
any other web client). If https, it may or may not reuse an SSL sessionid,
may or may not do a full handshake, and may create a conection within the
current session.

 

[Peter Williams] (My own web proxy just spies on such server-initiated
interaction with the foaf file provider, acting as a SSL MITM agent (not a
traditional CONNECT proxy) - purely for debugging purposes. See
fiddertool.org if you use the WinNT OS).

 

 

 

 

 

On the other hand I don't think we have explored the issues with HTTP  

proxies. Perhaps this should be opened up in another thread. I don't  

yet understand these issues very clearly.

 

> 

> Presumably, it's up to the operator of the proxy providing the ssl  

> tunnel's

> client endpoint to configure (per subscriber?) which trust anchors are

> valid, decide if server cert _chains_ are handled (or not), decide to

> implement the dns validation checks (or not) on the server EE cert (vs

> socket info).

> 

> 2. What rule set was used in the resource server's sparql server to  

> walk the

> trust path from the resource server's webid to the claimant's webids?

 

Damien did not implement this part of the foaf+ssl protocol. Only the  

minimal identification piece.

 

Walking the friend network is not a necessary step. It is made  

possible by deploying foaf using the Linked Data pattern. But it would  

only be required if the server wished to implement such access control  

rules. Many other access control rules are possible.

 

Also as the php SPARQL implementation for ARC2 only works when  

connected to a mysql database currently, and as Damian did not want to  

build something with that restriction, he used a simple programmatic  

method to walk the rdf graph. So he did not use SPARQL. Hopefully the  

arc2 implementations will improve in the near future.

 

> 

> In 24h, presumably one borrowed some or other existing open source  

> rule set

> or library of sparql queries useful for walking the naming graph.

> 

> Id foresee a hosted "trust broker" model evolving here, where those  

> with

> webids (be they resource authorities or claimants) can access a sparql

> server hosted by a TTP over https (or foaf+ssl!) to access that  

> subscriber's

> "profiled" ruleset (i.e. algorithm) for trust chaining.

 

There is not need for SPARQL servers at present. So I am not sure what  

you are speaking about. SPARQL is used as a convenient language to  

query the local RDF graph of the remote foaf profile. One could do  

remote SPARQL querying, but we have not yet looked at that here, and I  

don't think we need to at present, as that would introduce unnecessary  

complications.

 

[Peter Williams]  I need some terminology, then. Here is my attempt (based
on pretty standard framework of protocol-centric terminology, from 30 years
worth of internet protocol making)

 

Foaf+ssl: an https trust scheme embodying semantic web principles

 

Trust chaining: Walking the friend graph from one webid to another webid

 

Sparql-based trust chaining: optionally using one or more sparql servers to
perform Trust chaining

 

Webid resolution: treating a claimant's WebID as a URI reference and
following the reference to a foaf Person/PPD/file (which?)

 

Trusted Webid resolution: using WebId resolution and Trust chaining to
gather identity evidence for identity-based access control (or should this
be: claim evidence for claim-based access control?)

 

Resource Authority: the party willing to expose sensitive resources to
authorized claimants

 

Claimant: a user seeking access via an foaf+ssl channel to a resource
managed by a Resource Authority

 

Authorization: grant of rights and privileges to complete a request, in
conformance to a technical security policy. (or other security-community
yadayada)

 

NB If I understood foaf's conceptual model for agents properly, I suspect
one might properly label a Resource Authority as a "foaf-agent" (vs. a mere
"party").

 

IN some way

 

Henry

 

> 

> 

> -----Original Message-----

> From: foaf-protocols-bounces at lists.foaf-project.org

> [mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of  

> Story

> Henry

> Sent: Wednesday, September 30, 2009 5:09 AM

> To: foaf-protocols at lists.foaf-project.org

> Cc: Tournoud Damien

> Subject: [foaf-protocols] first implementation of foaf+ssl for Drupal

> 

> Damien Tournoud from http://af83.com in Paris implemented foaf+ssl for

> Drupal this weekend in under 24 hours.

> 

> The code is currently here:

> 

>      http://github.com/damz/foafssl-drupal/

> 

> and it is running here:

> 

>     http://foaf.damz.org/

> 

> Damien tells me there is still some work to do packaging this

> correctly for Drupal, and removing the dependency on openssl, for

> parsing the ASN.1 certificate. He has nearly finished  writing an ASN.

> 1 parser in php for that, which should be useful for all the other php

> apps.

> 

>     If other people are here with Drupal experience it may be worth

> asking Damien how you can help test this code, improve the user

> interface, and more. I'll keep you posted.

> 

>     Henry

> 

> 

> Social Web Architect

> Sun Microsystems            

> Blog: http://blogs.sun.com/bblfish

> 

> _______________________________________________

> foaf-protocols mailing list

> foaf-protocols at lists.foaf-project.org

> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20090930/679eb8dc/attachment-0001.htm 


More information about the foaf-protocols mailing list