Section 4: The following text does not parse The RADIUS SAML binding defined by this binding Section 5 uses two attributes to convey SAML assertions and protocol messages [OASIS.saml-core-2.0-os] respectively.
I think it would be more clear if we move the reference after respectively. I don't think it's right to say that more and reserved are ignored. More for example will be set often and reserved should be handled as in RFC 6929. Section 5: "A SAML Responder that refuses to perform a message exchange with the SAML requester MUST silently discard the request" Please clarify we mean ignore the attribute, not drop the entire RADIUS packet on the floor. It may well be that we generate an access reject as a result, but silent discard at the radius level is not really what we want. Section 5.3.1 Isn't the AAA server a SAML consumer of an authentication request? If so, it seems like it's more realistic for it to apply policy based on the NAS identity rather than the NAI realm as described in the text. I wonder whether requester and responder might be better than issuer and consumer in this section. old: A digitally signed request alone is not sufficient. new: A digitally signed request alone is not sufficient. A AAA entity can include a SAML message that it observes that is never intended by the issuing SAML entity for this AAA session. How exactly would one include a realm identifier in metadata? That is, is there well defined way to name a realm in SAML? Section 7.3.1`: Is this request in the initial access-accept? Every access-accept? Section 7.3.3: Wait. You're saying that my RADIUS server MUST look inside the SAML message and if a certain attribute is present go change my EAP state machine? I don't think anyone will ever implement that. Also, how does it interact with semi-long-term elements like Kerberos TGTs or TEAP tickets? Section 7.3.4: Is the simple system model inside or outside the scope of this profile? This also (and more importantly) applies to the requirements for the response. Ah, I see that this is handled later. There are still a lot of todos. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
