[foaf-dev] generating FOAF - dumb or smart?

Peter Williams pwilliams at rapattoni.com
Sun Feb 3 20:19:18 GMT 2008

I'll take the hints: (1) constrain the FOAF stream's form so it can be usefully rendered to people by your XLST engine; (2) use a template technique to limit the form of my output graph so it meets those "application-motivated" constraints. Pragmatism, above all!


Now we can back to access control. My ultimate objective is as practical as the XLST-renderer: I want to exploit SAML2's "attribute-level" encryption practices. I want to use that set of existing encryption techniques as the means of enforcing access controls on particular FOAF file triple groups. 

Conceptually, if an RDF file consists of distinct groups of triples about 10 resourceIDs (2 groups for each of 5 unique resourceIDs, say), each group becomes a serialized string that is treated as an "attribute" in the SAML2 world. (I think its irrelevant whether this hidden serialization is XML/RDF or N3). Metadata in the SAML2 world would then drive which of those "attributes" are then encrypted using standard and well-understood crypto primitives, once bound to a communication channel. The collection of all attributes, both those in  cleartext and those in ciphertext, would be streamed out of the SAML2 engine. The whole stream may be optionally signed, providing proof of origin usable by the communicating/proxying agents. One can apply chains of SAML2 engines, per the SAML2 "secure proxying" model.

Thanks to SAML2 being specified as a generic typesystem, independent of protocol binding, the form of that stream can vary, by binding to the communication system. In a simple binding to an HTTP POST communication channel, the form will normally apply xml-dsig and xml-enc enveloping (per attribute, in the case of encryption). In other bindings such as REDIRECT, the signature may be somewhat detached. Other bindings entirely discard the use of XML as an communications syntax. If one wanted, another (research) binding could apply "RDF-security", having canonicalised the RDF perhaps (as RDF, not as canonical XML) and used RDF-native cryptoprimitives - which seem to have existed, at some point.

If I've characterized the ultimate _practice_ what is the "agent middleware" I'll need -- to do it all the "semweb" way?

http://www.cs.cmu.edu/~softagents/papers/aaai_ss04_security.pdf provides an good starting architecture model. An OpenID OP agent can impose the security model, expressed in that policy-requirements vocabulary and stored in the agents triple store, on the FOAF stream wandering by. Once evaluated, the result would be SAML2 metadata about attribute-level protection requirements - that then drives std SAML2 engines. The SAML2 engine imposes the encryption/signing on the RDF stream  during communication, working as a substream processor cooperating with either openid's AX-protocol resolver engine or SAML2's own AttributeQuery protocol. It could also be similarly cooperating with Microsoft/VeriSign's ws-trust resolver, in their commercial identity metasystem (attribute-renaming, authorization-policy enforcing) vision.

In general, as the implementation means for an OP Agent's AX resolver is a local matter, I want to exploit existing datalog-centric techniques - already applied to this very problem, http://www.cs.virginia.edu/~humphrey/papers/GridFTP_SecPAL_2007.pdf.

Most generally, we could be attempting to ensure that the communication security techniques used to impose security policies on SemWeb streams are formally verifiable  (through the use of reasoner-based construction operators, all based in theorem proving) - applying formal verification as a explicit design practice in much the same way it was applied during the 1980s to access control problems in the trusted computing bases of A1-evaluated operating systems.



More information about the foaf-dev mailing list