Per-Entity Metadata Working Group

[David Walker <>]

+1  We already provide a method to verify the information that deployments may or may not check.  I don't see much value in another method, just to add some deployments that perform a (probably weaker) check.

David

On 07/28/2016 10:06 AM, Tom Mitchell wrote:

[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.

Attachment: signature.asc
Description: OpenPGP digital signature