Jim, First, I apologise for the appalling tardiness of this response to your review. Thank you for your comments.
>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??? I agree that your proposed change would more clearly reflect the primary motivating use case (Abfab), but I would strongly prefer to maintain the generalisation because it maintains consistency with the other bindings defined by OASIS SSTC. These bindings talk of requesters and responders, and RPs and IdPs are instances of higher-level abstractions that happen to use these bindings (as requesters and responders) to communicate. I would be happy to add some text talking around this point, if you think that would help? >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." Ok. >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]. Ok. > I don't see >any requirement that the binding should be specific to the RADIUS >transport >- do you? Well... I think it has to, by definition. The underlying transport is inherent to a discussion of any binding. Perhaps I have misunderstood your point? >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? I think that's implicitly true, because either of those messages necessarily concludes a RADIUS exchange. However, I like the idea of making this explicit in the text. > Also what other >currently defined packets is the element permitted in - for example can I >include it in an Access-Challenge packet? I have a strong preference to constrain the SAML response to the Access-Accept and Access-Reject packets. RADIUS has a really fuzzy notion of a session, and I think drawing some clear boundaries here could avoid inadvertently reaching inconsistent states at the AAA and SAML layers. >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 No; only allowed one of these. > or are they some other type of statement? Yes. A SAML assertion can contain three types of statements: authentication, authorisation and attribute. >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. Right :-) thanks >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." Yes. >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. Agreed. >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". The former. However, isn't this policy orthogonal to the question of whether the identifier is pseudonymous or not? >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. I agree. I would prefer that the spec says words to the effect of "die if the signature, if any, does not conform to policy" and remain silent on the question of policy. (I have a strong personal preference to deal with this question by prohibiting message-level signatures altogether, and leaving integrity to the transport level where deployers have a better record of getting this right, but that wasn't a popular opinion in Taiwan). >10. I believe that a discussion of what is expected to happen as these >messages cross federation boundaries is probably in order. What would you expect to see in this discussion? >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. Ok. >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? Ok. >3. There is an extraneous period in the last sentence of section 5.3.3 Ok. >4. Bad grammar /confirmation as the processing as defined in/ I don't >know >what this should be. Sorry -- defined where? >5. Please add http links to your SAML references so I don't have to >search >for them - I am very lazy. Ok. >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. Ok. >s/reponse/response/ >s/Consequently here exists/Consequently there exists/ >s/unsolicited responser/unsolicited response/ >s/disgression/discretion/ I will have an update out by the end of the week. Thanks, Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
