(Post title offered in the spirit of Norm’s post here… Or should that be “draught”? Maybe when referring to a collection of DocBook specs!)
I was scheduled to give a talk last week at the XBRL (Extensible Business Reporting Language) conference in Boston, on the topic of using Liberty Identity Web Services (ID-WSF) and other modern web services security standards to secure and authenticate XBRL-based financial report data. Unfortunately, just a couple of weeks before showtime, I was “cordially required” by my management to attend a different event and had to bow out, but my colleague Farrukh Najmi kindly offered to cover the session for me. Thanks, Farrukh! He and I worked to together to develop the content, which was an absolute pleasure.
Farrukh’s main specialty these days is ebXML Registry, whose latest spec version has a nice connection to both SAML and XACML; it defines how to do web single sign-on to a registry through a fairly thin profile of SAML, and also defines a binding to XACML for managing registry access control. This is a great example of reusing existing standards in an elegant and appropriate way. (By the way, if you happen to be an OASIS member and your company rep hasn’t yet voted on V3.0 of ebXML Registry, make sure they do so before April 30. I hope you’ll support its bid for OASIS Standard status.)
In similar fashion, the XBRL folks have been working away on their highly specialized language for business reports, but have recognized that the infrastructure — for example, secure web services technology — that will support XBRL payloads is best outsourced as a design problem. In my research for the talk, I learned that these folks have some interesting goals for capturing security assurances on report data, as well as for representing them in a GUI. For example, one fellow described to me how a reader of a financial report should be able to visually peel back the layers of trust on a statement such as “I, the auditor, certify that this electronic report corresponds to the official printed one.” They also have some classic access control concerns in the early stages of report development, though once a report is filed, everything switches to a “business-to-anonymous” pattern — anyone must be allowed to read the thing. (The Gilbane Report blog has some comments here about XBRL and its applications.)
Technologies like XML Signature, XML Encryption, WS-Security, SAML, XACML, and Liberty ID-WSF could potentially all get into the act to make XBRL security nirvana happen, but there’s no one obvious way to use them out of the box to achieve the desired results, so the next step called for is a deeper exploration of use cases and, most likely, some profiling activity. Just as ebXML Registry did, XBRL might find that reusing these security standards can be a feature goldmine.
