Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] lessons learned from AD FS 2.0

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] lessons learned from AD FS 2.0


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: [Shib-Dev] lessons learned from AD FS 2.0
  • Date: Sun, 24 Oct 2010 19:02:53 -0400
  • Organization: The Ohio State University

> 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?

I wasn't aware of any such implementations (and it's a serious bug). I don't
think we can just tell people not to do sensible or useful things because of
buggy code. They just need to be aware of the bugs so they can make
decisions or force their partners to accept the cost of the bugs in the
products they choose to use.

> 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?

A deployment can, but you were asking about an implementation. As for how
wise it is, it's a double-edged sword. The only way bugs get fixed is if
people stop working around them and make sure there is pain involved on the
part of customers using the buggy products.

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

None of that changes the purpose of the feature, though, or changes the fact
that what it's generating is compliant.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page