Shibboleth Developers

[Tom Scavo <>]

On Sun, Oct 24, 2010 at 4:37 PM, Scott Cantor 
<>
 wrote:
>> 5. The same certificate SHOULD NOT be used by two different entities.
>
> I think that's up to the deployer.

Yes, I agree, all of that first group are deployment requirements.
This particular requirement is meant to convey that the deployer does
so at their own risk since some implementations enforce this rule. Is
that not reasonable?

>> 3. If an implementation produces metadata on-the-fly, it SHOULD
>> produce metadata with at most one encryption key.
>>
>> It's this very last requirement that is the purpose of this message
>> (since the previous two are already met by Shib). Regardless of the
>> number of decryption keys configured, does the SP produce metadata
>> with at most one encryption key?
>
> No, since there is no SAML requirement to limit that.

That's true. So here we have an example of a "feature" that's not
strictly required for operability, but causes issues with respect to
interoperability. Wouldn't a deployment be wise to limit such a
feature?

>> If every <md:KeyDescriptor> element in metadata has a 'use' XML
>> attribute, multiple encryption keys in metadata are not strictly
>> required. So the first step of the key rollover process should be to
>> replace a <md:KeyDescriptor> element having no 'use' attribute with
>> two <md:KeyDescriptor> elements having explicit 'use' attributes. Was
>> this intentionally overlooked?
>
> The generated metadata, which is a testing tool, simply reflects the
> configuration as accurately as possible (and no more so, since it can get
> many things wrong). That's all it was intended to do.

Maybe so, but it's certain to be used as a production metadata source
eventually. In fact, it already is in use by one US federation, so
it's just a matter of time before that "test" metadata finds its way
into other federation metadata stores.

Tom