Shibboleth Developers

["Howard Gilbert" <>]

> > session. While dates and names in the Metadata certificate may be
> ignored by
> > the SP, these same fields may be checked for validity by the runtime
> > environment or library routines as they are presented in the copy of the
> > same Certificate presented through XML or SSL.
> 
> That's simply not true in our code, and we took great pains to ensure
> that. What other people write is on them, but our code had better be
> consistent across all platforms on this point. I feel very strongly
> about that.

Yes, but in the Metadata this isn't a comment about a particular
implementation but rather about the generic consumer of the Metadata
service. Maybe the comment might better be that the dates and names in the
Certificate in the Metadata are not meaningful to other consumers of the
Metadata, but other copies of the certificate presented in the XML or SSL
session may be checked by other implementations of the protocol. Or better

"We don't promise that an expired Certificate will be detected and rejected,
but it is poor practice to include expired stuff and just assume it will
work."

> If this is an IANA registered MIME type, then I will most definitely
> change my default. Otherwise...

Well I might just want to build a repository full of *.sso files that I want
to vend subject to Shibboleth authentication. They may be Stupid Senseless
Objects, but I don't want the filter mapping to get in the way of my vending
them.