InCommon metadata support

[David Langenberg <>]

> On Dec 6, 2016, at 3:44 PM, Tom Scavo 
> <>
>  wrote:
> 
>> On Tue, Dec 6, 2016 at 4:26 PM, Tom Poage 
>> <>
>>  wrote:
>> 
>> I’ve been trying to find ways to get unknowledgeable (and 
>> non-participating) vendors to obtain a trusted/verifiable copy of our IdP 
>> metadata.
> 
> That would be a wonderful Xmas present ;-)
> 
>> Many vendors, albeit understandably, refuse to download the InCommon 
>> aggregate. Even if they do, understanding the content and parsing out our 
>> IdP metadata, often by hand (ugh), and without even broaching the extra 
>> consideration of signature verification, seems an insurmountable task for 
>> the typical kind of support person on that end assigned to the task.
> 
> Yes, you've hit the nail right on the head, Tom. This is why IdP
> deployers will immediately gain benefit from an MDQ server even if
> they don't reconfigure their IdPs. As you've noted, there's great
> value in having a permanently addressable URI for a single IdP entity
> descriptor.
> 
>> I’ve resisted self-publishing our IdP metadata (with or without local 
>> signature, to varying degrees of success), so the MDQ server seemed a good 
>> bet. Now to get them to take that small but oh so important step of 
>> verifying what they download!
> 
> The consultation of the Final Report from the Per-Entity Metadata WG
> [1] ended yesterday, otherwise I'd ask you to weigh in on the
> following issue:
> 
> Should the MDQ server serve entities over TLS? Most people say yes but
> then that raises a more interesting question: Should the TLS
> certificate be self-signed OR signed by a commercial CA OR signed by
> an internal CA created specifically for that purpose?
> 
> Thoughts?

My vote would be commercial CA signed.  Then provide instructions / support 
for how people can configure their software to pin the chain appropriately if 
they want to avoid the concerns of trusting a commercial CA. 

Dave

Attachment: smime.p7s
Description: S/MIME cryptographic signature