[foaf-protocols] foaf+ssl basic, and foaf+ssl for HTTP

[Peter Williams]

When I promote foaf+ssl with folks, this is what I say.


A.      Here is a web-friendly way of cutting out discard complex multi-party message flows introduced by the likes of openid (authentication of users) or  IETF's WRAP (authorization token rewriting done along openid/oauth lines)



B.      Foaf+ssl "basic" has a user present a webid to a resource server in a SSL client auth certification (probably self-signed and trivially easy to provision), which deferences a valid foaf Person from a foaf file on the associated server. Its secure (and the webid is deemed be controlled by the user) if the domain of the webid matches the domain of the server, based on https server cert domain validation. It eliminates all the complexity of openid and WRAP by (i) being nothing more than a foaf file pick over https, and foaf's vocabulary allows for the expressing of user attributes, authorizations and name/identifier mappings in a manner consistent with semweb's architectural principles.



C.      Foaf+ssl "for HTTP" builds upon B, but can address all HTTP verbs and responses. This allows for foaf+ssl to verify the user controls the webid for any and all possible HTTP interactions between the resource server and foaf file repository. The extension to all HTTP flows allows foaf files to sourced by triple repositories identified by domains (or alternative authorities constructs) other than those declared in the webid.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091105/72d6b2ff/attachment.htm