Overview
- What is FOAF+SSL? Why is it needed?
- Comparing FOAF+SSL and other authentication methods
- How FOAF+SSL works
- Building authorization on top of FOAF+SSL
- Next directions
What is FOAF+SSL?
- A RESTful, secure, open authentication framework
- Like OpenID, with security by default and no provider
- Implemented seamlessly on top of SSL
Why FOAF+SSL?
- Linking common semantic representation to user token
- Distributed ACLs
- Protecting sensitive data on the Open Social Network
Current Alternatives: HTTP Authentication
- Pros:
- Supported by almost all web clients/servers
- Easy to set up and maintain
- Cons:
- Site-specific login information (password glut)
- Easy to set up insecurely (Basic over HTTP)
- Shared secrets
Current Alternatives: OpenID
- Pros:
- Single username, single sign-on
- Already deployed, many providers and provider softwares
- Cons:
- Security concerns (spoofing)
- Not as easy to integrate or set up as HTTP authentication
- An architectural hack (requires graphical browser)
- Can still be implemented insecurely (HTTP provider)
Using FOAF+SSL
- Pros:
- Single 'username'
- Requires SSL by default for security
- Integrates with existing practice and standards
- Provides link between user and semantic descriptions (for authorization)
- Cons:
- Self-signed client certificates may need minor workarounds on server
- Implicit security of protocol unproven
- Optional certificate presentation not well-supported (Safari, Chrome)
Technical Background - FOAF
- "Friend of a Friend" vocabulary
- A defacto RDF standard for describing a person
- Semantic Web-based vocabulary
- Gives an individual a URI
FOAF+SSL - The Protocol
- User requests page.
- Client/server establish SSL connection.
- Client provides self-signed certificate with pointer to 'FOAF' URI.
- Server pulls document from FOAF URI in certificate.
- Server verifies public key of cert with FOAF.
- Client is (not) verified as 'owning' that URI.
FOAF+SSL - Adding Authorization
- Only establishes control of a URI
- FOAF URI and certificate allow for establishing trust (PKI/Third-parties)
- Self-signing clients are okay: PKI works better with clients than servers
- Can use URI as unique identifier for policy reasoning
An Example - Adding Authorization with TAAC
- TAAC is an example of the more general reasoner-based approach.
- On file access, checks for policy (assume there is)
- Do FOAF+SSL protocol
- Generate log of access
- Reason over log and access policy for compliance
- Grant (or deny) access based on reasoning results
Use Cases
- Single-signon web service user identification (as in OpenID)
- Single-signon web service personalization
- (Distributed) HTTP access control
- Remotely modifiable Friends List/Address Book
- Single-signon with multiple protocols (XMPP, etc.)
The Adoption Cost: Certificate Creation
- Integrating in-browser SPKAC/SPKI cert creation
- Several implementations of SPKAC/SPKI cert creation with FOAF+SSL
- Caveat: IE doesn't support SPKAC/SPKI
FOAF+SSL Implementations
- TAAC
- mod_python and Apache (CGI version being tested with lighttpd)
- Includes reasoner for authentication
- In alpha
- FoafServer (in Sommer)
- Java-based
- Has certificate generator
- Lacks authentication at this time
- PHP, Perl, Openlink Virtuoso, others, as well
Open Questions
- How secure is the self-signing client?
- Appears better than a self-signing server
- Caveat: Establishes user as able to write to the URI, not that they ARE the person described by the URI.
- Usability concerns
- Some browsers poor at providing optional certificates
- Some browsers don't accept client certificates
- No authorization standard (out of scope)
- TAAC is an example, but not representative
FOAF+SSL Resources