Checking contextual integrity

[Rod Widdowson]

> There has to be an action that actually runs the filtering step, that's
> what I would expect is checking this (if it is in fact a required context
> in every possible scenario).

There's the rub.  I think that it is reasonable to expect the Principal,
RequesterID and IssuerID to be present, and it is realistic to check for
that.  Equally, in SAML flows I think that it is reasonable to have the
Requester metadata available (so most of the metadata based filters will
work).   I believe that we should not be policing that the Issuer metadata
is available (we do not want to *have* to require our own metadata), but if
it is not available then the Attribute Issuer metadata filters become
meaningless (issue an error message and return the failsafe).

I'll add annotations to the relevant contexts to indicate this.

> But I think it's also the case that in an extensible system, there's no
> way to guarantee that every extension will be able to assume that it has
> what it needs. But they probably should fail "safe" in that case.

I know you dislike the term so I'll not say "trust but check".  I think that
safe has to be to issue and warning and return false.  Then the only case
impacted wrongly is the less common <DenyAttribute/> case.  Further this
sort of failure will not be transitory, it is a config issue.

> >Or do I just learn to love living with ThrowingPredicates?
> 
> I would tend away from that model, as I think I've said in other cases. I
> don't like "true/false/throw" interfaces.

Digression: ... or typed nulls ? Does anyone (apart from Ian and an ex
mutual colleague of ours) remember slow and fast noops in the DEC-10?

Agreed then.  Currently the only exceptions thrown in filtering come from
scripting.  Let's keep it like that.

Thanks
Rod