RE: [security-services] Trust management and validation viametadata

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

> Well, I'm not going to argue that point too loudly. We're debating exactly
> that in our project, that's partly why I'm asking these questions. If nobody
> else is implementing anything like this, that sends a message. OTOH, my
> sense is that people are using ordinary PKI and trust lists to deal with
> SSL, but perhaps not so much with signatures. I think that's inconsistent
> for users, and I'm bothered by the fact that the metadata can't express the
> configuration rules to apply for both cases. But it can with some pretty
> simple extensions.

I'm becoming convinced based on discussions here and in the Shib project 
that while managing a trust configuration in a fine-grained way is really 
important for a SAML installation, and there are motivations to do so 
interoperably and in a way that supports trust config distribution, that 
this isn't SAML work, and shouldn't be done as extensions to SAML 
metadata.  The fact we can refer to an entity's key easily using existing 
metadata, and that that key can be used directly for validation, leads to 
the notion that more complex validation could be expressed as an add-on. 
But the presence of a key in metadata also doesn't say how that key comes 
to be trusted for validation; that comes from, say, the metadata being 
signed, and that signature being validated by trust anchors or some such; 
stuff that is not represented in the metadata itself (and can't be, 
really).

There is definitely important work in mapping application-specific naming 
and validation and constraint requirements into some common infra that can 
rely on PKI (whether traditional or new-age) for scalability (eg Paul 
Madsen's "Machine Assisted Trust Mechanisms for Grids" paper from a couple 
of years ago), and having that at hand would definitely help SAML 
deployments interoperate, but it would help lots of other layered security 
infra scale and interoperate too.  So I'm inclined to say that this work 
should be pursued independently (unless of course the TC wants to take it 
up as a new work item, which would likely need a rechartering discussion).

  - RL "Bob"