>> >> I think we need to be circumspect how we choose to constrain the >>protocol. >> If we need it for technical interoperability, fine. Otherwise I'd prefer >to leave >> anything to do with the semantics of the messages to the application to >> worry about. I don¹t think its the business of the transport or framing >>to >> dictate that. > >I tend to agree with Sam here. Given that different subject values could >refer to the same subject, there is no way for the service to know which >SAML statements would be for the client and which are extraneous without >such a constraint being stated.
I don't think we disagree, we're just saying slightly different things. I think Sam was saying that - as a baseline - we should constrain the protocol so that the service can assume that assertions with different claimed subjects refer to the same principal (note that that doesn't require, at the payload level, that two or more assertions must have the same subject value). I was saying that service should be free to ignore the subject value claimed by the system, and infer the use of another value on the basis of other characteristics of the protocol or payload context, for its own purposes (whatever they might be). The original intent was to use SAML's model, where scenario-specific constraints are defined separately from the transport and framing "Binding" specifications within "Profile" specifications. While this provides a separation of concerns and other good stuff, it's also a lot of work and I don't think we've had a motivating use-case until now. It could be that we need to look at this again so that we can, as Sam says, "define new semantics in the future and reuse the framing". >> >> >2) It sounds like we should start doing design work on the case of >> >attributes coming from multiple sources at least enough to support your >> >use cases. My personal suspicion is that I want a bit more AAA framing >> >than we do for the single issuer case. I don't have a problem doing >> >that standardization now. However I want to make sure that is not >> >mandatory-to-implement and that a RP can easily tell if a situation it >> >does not implement is happening. >> >> I agree. However I think we already partially support the case of >assertions >> from multiple issuers within a single transaction, where a AAA server >>has >> aggregated assertions from multiple IdPs and is sending them along to >>the >> AAA client. That's just a bunch of assertions in a single SAML response >> message over the AAA response. We don't support the case where the >>client >> needs to specify to the AAA server which statements it needs from which >> IdPs. >> >> However, we also need to consider the case where the AAA client is >> aggregating assertions from multiple AAA servers. In the general case, >this is >> my preferred aggregation strategy. We've touched on this in the past, >>but >> not really taken it anywhere. > >I don't understand your usage case here. I can understand the case of the >AAA server at the IdP aggregating multiple statements together based on a >SAML query that came with the EAP message, however having the AAA client >doing this functionality I don't understand. How it would take place? >Are you suggesting that the server ought to be able to send multiple SAML >queries through the AAA client to get multiple statements? Yes; there was some mail about the use of the Authorize-Only facility previously: http://www.ietf.org/mail-archive/web/abfab/current/msg00366.html I don't think we resolved whether this was a reasonable use of this facility in that the Authorize-Only request isn't going to the original authentication server, but another AAA server. I've been meaning to ask Alan to seek his opinion... Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
