> 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.
Well, if by IdP you mean the identity intrinsically associated with the AAA server, then I guess I would have to say that it's reasonable to say that you get that technical trust from the AAA layer, but that any other assertions from other issuers should be signed and verified independently (meaning the rules would be based on the actual issuer). In practice, I don't think IdP-side aggregation works all that well and the most common SAML profiles basically preclude it unless the IdP reissues the data itself, so I tend to focus on doing it at the SP. But then I write SPs, so that's a bias. I think when we do things like re-issue data at the IdP end, there's not usually any kind of indicator to the SP that this was done, because the whole point is often to hide it. > 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 there should be a clear statement about the validity assumptions one should make about any additional assertions, because normally there is no such assumption...you always validate any assertions you get. Trying to dodge that requirement (or optimize it out) introduces the need to be explicit. > 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. I think I understand you to be saying that you're solely concerned about the technical trust component, and not the business level aspect of the truth of the data or the right of the issuer to speak on what it says. If that's the case, I agree with you, and it should not require explicit configuration per source to control whether validation is done. We do, as I mentioned briefly, need to discuss SAML conditions, though, even in the case of the assertions from the single IdP. *Something* has to evaluate them, or they have to be precluded by profile from appearing. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
