Shibboleth Developers

["Scott Cantor" <>]

> The behavior of the isRequired attribute and what to do if all required
> attributes are not returned is given in the SAML spec, so there is no
> ambiguity there.

The IdPs would never have accepted a fixed definition, so there isn't one.
The meaning of the attribute is unambiguous, but there are no strict MUSTs
around the entire AttributeConsumingService element. It's explicit in the
protocol actually that an IdP MAY ignore it. So I continue to believe it's
not only difficult, but outright inappropriate, to even try to insist on
something. And I also don't believe it will create the problems Tom is
worried about.

It is necessary to articulate an expectation of possible behvaior. Since an
IdP MAY send anything it wants at any time, including an error, at the end
of the day, that's what SPs have to handle. That's not a new thing just
because this feature is involved.
 
If SPs think they will gain by lying and omitting the isRequired attribute,
they're wrong, because that isn't going to make a successful response more
likely. They still won't get the data. I think it's more than adequate to
leave it at "you require it if your service won't function properly without
it" and count on people doing what they're supposed to do as part of their
federation participation, which usually includes "provide accurate
information about the service".

-- Scott