modelling the digital trust domain
Fri, Jul 18, 2008
As Guanxi 2.0 progresses towards official release and I’ve ironed out a lot of issues and streamlined parts of the system, I thought it was time I took a few steps back, as a painter might, to get an idea of the overall picture and the aims of the application. As skill level increases in a particular domain, in this case Shibboleth, one may work up through the Dreyfus levels, to reach an understanding that encompasses not only the internal workings of the application but the wider context in which it sits. Although Guanxi is primarly a Shibboleth implementation, there are other SSO systems out there, which I should keep an eye on, such as OpenID and OAuth. As well as that, each wagon circle has its own vocabulary and protocol exchanges but underlying all is the concept of trust.
In the UK Federation, the trust fabric is expressed in SAML2 metadata [PDF] with a set of extensions that are manifestations of an underlying technical problem that had to be surmounted in the early days of Shibboleth, to do with SSL certificates not being propagated to SAML entities. So with Shibboleth, there are three steps to verifying the authenticity of a SAML entity, such as a Service Provider (SP) trusting an Identity Provider (IdP):
“As far as the software is concerned, there’s no such thing as a federation” [ref]
Federations are there to keep lawyers in business and to keep members in check. They specify who can and who cannot join, based on profile implementations, what level of assurance they can offer on the validity and integrity of their data and whether they can comply with tracking requests to pursue errant users of Service Providers. In a way, they’re a necessary evil as humans will, given enough rope, eventually become pirates. Federations are gentlemens' clubs designed to keep out the pirates. That also means that there are two layers in systems that work with federations. There’s the core SAML layer, which satisfies the demands of the federations' lingua franca, SAML and Shibboleth in particular and the application layer where the federation rules are implemented, for example logging and tracking functionality, such as the requirement to satisfy section 6 of the UK Federation Rules of Membership [PDF].
However, there are other trust models to deal with, so in the next few posts I’m going to look into using my favourite agile methodology, Domain Driven Design, to find a ubiquitous language with which to describe the digital trust domain and use that domain model to implement a generic trust engine for Guanxi. Will it be possible to encompass multiple trust requirements in one domain? I don’t know, yet but it will certainly be an interesting voyage in the stormy seas of digital identity.