Per-Entity Metadata Working Group

[Tom Mitchell <>]

[Apologies, I’ve realized this week that our corporate mail filters are 
stopping Tom Scavo’s emails to InCommon lists from getting to me. I 
anticipate no resolution.]

> If the goal is to get our arms around the larger group of clients
> (Shibboleth, SSP, AD FS, Ping), then we also need to reconsider our
> overall security model. TLS on the MDQ server can not be avoided if we
> truly want to be all-encompassing.

I’d like to play devil’s advocate here. I believe the documents being passed 
around are public and carry their own security so shouldn’t require TLS 
protections. Clients really shouldn’t care from where they’re getting the 
documents, they should only care that the signature within the document is 
valid.

> What I'm trying to say is: other software (apart from
> Shibboleth and SSP) can not verify an XML signature directly. A
> 3rd-party add-on tool is required for that (and if the past is any
> indication, those 3rd-party tools won't get used). So if we're serious
> about including other clients in our solution, then we have to address
> the TLS issue.

This seems to me to be a much larger concern. In my mind verifying the server 
is not in any way comparable to, or a sufficient substitute for, verifying 
the XML signature. And if a client is willing to trust the XML without 
verifying the signature, what’s to stop them from failing to verify the 
server against the certificate sent over TLS? I do not think an MDQ solution 
should take steps to allow such clients to circumvent the security built into 
the signed XML documents. I may be naive.