El 03/11/11 14:10, Luke Howard escribió: >> First, if the SAML assertion is generated by a legacy idP then it should >> discriminate between requesters (the RADIUS server in this case) and to >> decide not to sign the assertion issued for this entity. It could be ok, but >> I think should be explicitly described in the text. Other option is to >> allow the RADIUS server cuts short the assertion and to remove the XML >> signature, but I don't like this. > The acceptor could ignore it. yes, I was thinking in the size of the SAML assertion and the limit of 4096 bytes commented by Alejandro in the last email. The XMLSignature would increase considerably the message size. > >> Second, you have to take into account that the SAML assertion will be for a >> one-time use and it could not be managed/validated by a third party. Let's >> think in a scenario where the received assertion is used later on to request >> other end user attributes and the original SAML assertion should be >> first validated in order to check validity. > > This makes sense (kind of like Kerberos constrained delegation where the > authorisation data is signed). But it could be optional? not sure about that
regards, Gabi. > > -- Luke -- ---------------------------------------------------------------- Gabriel Lpez Milln Departamento de Ingeniera de la Informacin y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: [email protected] _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
