Hi, Apologies for reopening a discussion that seems to have concluded (my only excuse is that I was hovering most of the last 2 weeks 20 meters below the surface of the Red Sea). But I still need some more convincing that we MUST carry the SAML data over AAA. It seems to me that using the AAA fabric just to introduce the parties to each other and do additional attribute exchange out-of-AAA-band has a number of advantages, most importantly, no issue with the 4k limit. I find the argument that intermediate nodes may need to rewrite attributes not very convincing, after all there are many hub-and-spoke federations in SAML-space that do just that routinely, no need for AAA intermediaries. In this respect our use is very different from the AAA+EAP for network access use-case, there we are suffering from the fact that the supplicant has no layer 3 connectivity yet, but in the abfab case all actors have IP-connectivty?
Or am I just being dense? In that case please enlighten me (beyond "but doing everything over AAA is a much cleaner solution") Klaas On Nov 29, 2011, at 6:55 PM, DIEGO LOPEZ GARCIA wrote: > > On 29 Nov 2011, at 09:10 , Alejandro Perez Mendez wrote: >> I think that the "more SAML data" attribute proposed by Alan would work >> also if included in requests. In such a case, the AAA/idP could send an >> Access-Challenge message (including User-Name and State attributes, for >> example), waiting for more data to come from the RP. > > As Alan noted, we should aim for a more general name for the attribute. > Though the exchange of SAML data is the main (and probably unique, at least > for the moment) use case, I don't see any hurt in using something like "more > additional data" or "more external data" or "more authorization data"... > >> Additionally, the "more SAML data" could contain some kind of "cookie" >> or "nonce" value, in such a way that if returned unmodified in the >> following Request/Response message to the creator, it allows to tie all >> the messages within a conversation, if other means (e.g. State >> attribute) are finally not enough or not applicable. > > Indeed. I think it would provide not only this tying mechanism, but also the > possiblity of using it to point the conversation (and the subject of the data > being exchanged) to the elements providing those additional authorization > data, and I guess this could satisfy what Josh called the decoupling of the > authentication and assertion roundtrips. > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
