> -----Original Message----- > From: Josh Howlett [mailto:[email protected]] > Sent: Friday, August 19, 2011 8:45 AM > To: Sam Hartman; Jim Schaad > Cc: [email protected]; 'Sam Hartman' > Subject: Re: [abfab] EAP naming attribute document > > >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.
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. > > >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? Or are you saying that GSS-EAP should somehow do this? Jim > > 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
