1. Introduction para #2, Definition of binding is not well stated. I believe a better description would be: "in the SAML architecture, the description of how messages are transported is called a 'binding'."
2. Not immediately clear these are two not one from the text "specific use cases: authentication and assertion query/request." suggest "In addition to the new RADIUS attribute and the RADIUS binding, this document also creates two profiles for their use. The first profile is for the case of ABFAB authentication and the second is for assertion query/request. This is intended to promote interoperability between implementations for these common use cases." 3. Introduction - Summary points - s/An Authentication Profile/An ABFAB Authentication Profile/ 4. Section 4. Title - Look for an be more consistent about the term you are using. I prefer "RADIUS SAML-Message Attribute" to "SAML RADIUS attribute". Consistent name of the topic would be good. 5. Section 4 - I think Scott raised an interesting question in the meeting about the ability for this attribute to be deflated (optionally?) before being sent. This would tend to make the message a lot smaller. One could probably detect the deflation based on the first character in the data field (i.e. '<' vs ???) so no signaling method would be required. 6. Section 5.2 - "RADIUS can be used over multiple underlying transports;" It is unclear to me that this binding really needs to care about what the underlying transport is and why it would need to state what the transport is going to be. I have problems with trying to state what the transport should be because there is no way for the application to be able to control it. 7. Section 5.2 - Item #1 - "MAY transmit a SAML request" there is no MAY here, it just "transmits a SAML request" If it is not transmitting the request is not acting as a SAML requester and is not relevant to the document 8. Section 4.2 - Item #2 - "A SAML requester MUST NOT send a second SAML request element in a subsequent SAML request element." I think this is also an added restriction as well. 9. Section 4.2 - I don't know if this goes here or someplace else, but there may be an issue with an IdP being unable to satisfy the conditions in an AuthzContext request. Would this be returned as a SAML error and failed authentication? Note in this case no EAP would be run by the IdP. 10. Section 6 - last sentence - who is the name identifier being established for? 11. Section 6.2 - Bindings: Eliminate the first sentence and just say that it requires the SAML binding. 12. - Section 6.3.1 - The GSS Initiator not the GSS Acceptor invokes the GSS EAP mechanism. I think the language in this paragraph is being very sloppy about what is happening. 13. Section 6.3.4 - the text starting with "MAY issue" is fuzzy. a) is it may issue or the issued response may be consistent w/ the authentication result? b) the A and B and C at the end of the sentence seems to meander without a point. 14. Section 6.4.1 para #2 - Needs to say that a failure will occur if it either will not or cannot satisfy the request. MUST NOT do an access accept using different criteria than asked for. 15. Section 6.4.2 para #3 - This paragraph actually bothers me for the following reason. It allows an RP to determine if a pseudonymous identifier that is going to be specific to it will be returned or not. (say don't create and then say allow create). It is not clear to me that this is desirable behavior. 16. Section 6.4.2 - last bullet point - This is a partial address of a previous point in this mail. I think this is an incorrect statement. I think that the statement should be, if you return a response, you must have a AuthnStatement that matches the request. If you do not return a response, then you are not bound to obey any of the requested context. This set of rules would allow the RP to determine if the request has been satisfied or not. 17. Section 6.4.3 - Bullet #2 - This implies some type of re-authentication protocol. As we are not having a GSS-EAP based server re-authentication operation, does this need to be clarified here or is the text I am going to put into the architecture document suffice? Jim _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
