Let me try and be explicit about what I'm wanting. We're saying that when you receive a SAML authentication response from this AAA attribute you SHOULD NOT call a saml validation routine. You MUST still decide what statements you will allow the IDP to make, but AAA is handling the technical trust.
I pointed to a couple of trust model earlier in the week. They effect two decisions the SP needs to make: 1) does it call SAML validation and if so, what does it do with a failure result 2) When evaluating whether the issuer is permitted to make the statement being claimed, does it use its rules for the IDP or for the actual issuer. I.E. does it assume that the IDP has vouched for the statement or simply passed it along. These are both technical decisions that affect interoperability and security. My claim is that to produce a technical specification that meets the requirements of RFC 2026 without known technical omissions we need to tell implementations what to do in these cases. I agree with you that various levels of ambiguity have been used with regard to these sorts of issues in other standards, and we have not been perfect. However I do think we have considered these sorts of issues. Often, the answer we've given is "that decision belongs at the next layer." I don't think we can do that here, although I'd be interested in evaluating a proposal to do so if someone made one. I would not support a proposal that required per-IDP configuration. --Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
