>1) I think we should say somewhere that you shouldn't send back multiple >assertions unless it's appropriate to just combine them together. >I.E. assertions from the same IDP about the same subject are probably >OK, at least until we figure out what we want to do in those cases.
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. >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. 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
