[wsf-dev] wsf-dev Digest, Vol 2, Issue 3: Some Decision Making

[Scott Cantor]

A few more details...

>   As Scott mentioned to you, I think where we differ from most other
> projects in our attempt to preserve the DOM as completely as possible.

Religiously. It also handles document switches and fragments much better
than the old OpenSAML code does. The overriding use case was to allow signed
assertions to be verified in and out of context, snipped and re-attached to
new messages, while not corrupting anything, but without having to
round-trip to XML and back.

> In addition there is code for supporting XML encryption and signatures,
> validation, ID attribute and searching support, XML fragment adoption w/
> proper namespace management, key resolution, and some engines for
> evaluating security tokens (keys and x.509 certs currently) for
> signature processing.

The signature support allows the creation and verification of the signature
"profile" (what's being signed and how) to be packaged in separate classes
from the objects being signed. This in theory would allow WSF security
"profiles" to be created and reused for common signature patterns like "sign
the body and all headers by ID" and that sort of thing. If you go so far as
to look at signing with XPath then this probably becomes even more crucial.

We have complete modeling of most of KeyInfo and XML Encryption objects as
well.

The TrustEngine layer which we ported from Shibboleth is also far beyond
what most libraries supply for key and certificate evaluation, and is
adaptable via glue classes in OpenSAML to SAML metadata for applications
that can consume it to supply key information.

-- Scott