Comments on the current version of the document. First let me say that overall I am very happy with the state of this document. It is slightly repetitive, but is very clear about what happens when and where. I believe that I now have a clear understanding of how I would go about using SAML statements in Plasma by starting with using the Authentication Profile and then following it up with generic queries using the identity that was returned in the Authentication response.
Jim Major 1. Do we have any other examples where we might have a SAML requester/responder other than the case of the RP/IdP? If so, it might be wise to mention at least one other case in the introductory paragraph in section 1. Otherwise it might be easier to just say that we are sending messages between the RP and the IdP and not generalize it. Can anybody see a reason that one might want to reverse the endpoints? So that the RP becomes the server and the IdP the client??? 2. In section 3, I would suggest adding the text "There MUST be at most one SAML-Message Attribute in either a RADIUS request or response message." 3. In section 4.1 and 5.1, the Identification will require an IANA action. I think we are looking at urn:ietf:params:xml:ns:abfab:<something goes here> I think that something probably looks like SAML:binding:RADIUS-binding in section 4.1. The contact information should be [email protected]. I don't see any requirement that the binding should be specific to the RADIUS transport - do you? 4. In section 4.2 item #2 - If the SAML responder is going to response to a SAML request, is there a requirement that the responder MUST response no later than the Access-Accept or Access-Reject message? Also what other currently defined packets is the element permitted in - for example can I include it in an Access-Challenge packet? 5. In section 5.2 - Section on Responses: - I am confused when I read this text. It first says that you must return exactly one authentication statement. It then says that the IdP can return other statements in the assertion. Are these other assertions allowed to be authentication statements or are they some other type of statement? 6. The last sentence in section 5.2 makes no sense to me. I believe the sentence should finish "to a Relying Part without step 2 occurring." Doing it without having the EAP protocol run in section 3 would be bad news. Ditto the last paragraph in section 5.3 - I think it should just say that "The Request in section 5.3.2 is omitted from the process." 7. In section 5.3.4 - I would like to see a statement that in this profile, if the <samlp:AuthnRequest> is marked as fail then the EAP should also return fail. That is there should not be difference in the returned value for the SAML request and the EAP dialog. 8. In section 5.4.1 paragraph 3 - I am not sure how this section interacts with the ability of an IdP to return a Pseudonymous identifier. Are you stating that the identifier must already exist, or just that the policy for creating the identifier must already exist in the case AllowCreate is set to "false". 9. In section 5.4.1 last paragraph - I think we should make some type of statement about what happens if either the request is not signed, or the signature on the request cannot be validated by the IdP. I think that both of these cases are going to be more likely that the case of it is signed and the IdP happens to be able to validate the signature. 10. I believe that a discussion of what is expected to happen as these messages cross federation boundaries is probably in order. Nits 1. We need to get a consistent method of doing Abfab or ABFAB. I have always used all upper case, this document is doing mixed case. We should be consistent and I think the all upper case is the normal way. Please change. 2. I object to the capitalization in the following sentence "The NAI SHOULD be used to route the message towards the SAML responder, which MAY be more than one RADIUS hop distant." How are these requirements on the binding that is being produced? Are these not intrinsic properties that are true just by saying that we are using RAIDUS? 3. There is an extraneous period in the last sentence of section 5.3.3 4. Bad grammar /confirmation as the processing as defined in/ I don't know what this should be. 5. Please add http links to your SAML references so I don't have to search for them - I am very lazy. 6. Can we move some of the references out of normative? For example I think that 3575 could be informative since it affects only the document writer and not the implementer. The same is probably true for some of the other references. s/reponse/response/ s/Consequently here exists/Consequently there exists/ s/unsolicited responser/unsolicited response/ s/disgression/discretion/ _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
