Jim, >This looks much more like the discussion that we had after the last IETF >meeting so I am generally happy.
Glad to hear that. >1. I think inserting a paragraph start at "The name identifier..." will >make it clearer which artifacts are designed to be used in ABFAB scenarios >and which are designed for more universal usage. Agreed. In fact I'm thinking of re-structuring the entire document to make that distinction more obvious to the reader (but not sure if it's worth the pain). >2. In section 2 for the last bullet point in the first list - should >this >be the subject of an assertion or the subject of a protocol message? I am >always very unclear about SAML naming of items. However this confirmation >method can be in both a SAML assertion and in a query (i.e. >AttributeQuery). In SAML, only assertions and their requests have Subjects; framing PDUs do not. I'll try to make this more obvious in that bullet. >3. In section 5.2 - I am not happy with the single reference to RADSEC as >being the required. I would be more happy if the profile required either >TLS/UDP or TLS/TCP as required. Either that or TLS/TCP should be >recommended. I am worried that without this there might be an issue with >people thinking it is restricted to UDP. > >Note that for longer messages you probably really want to require the >TLS/TCP version not the DTLS/UDP version. Good point, I'll clarify. >4. In section 5.2 - I have probably said this before, I am not really a >big >fan of the use of language such as "MAY transmit a SAML request". If you >don't do the request how can one say that you are acting as a SAML >requester. A similar statement is also made for the second item. Just >say >"returns a SAML protocol message" and then talk about reasons that you >might not wish to do so. Yes, you did mention that before but I failed to follow through. I will do so on the next iteration. >5. In section 5.2 - s/responder MAY also return/responder MAY return/ - >it >might be read as saying you could return two even though that is >explicitly >forbidden. Ok. >6. In section 5.2 - I think we should probably add the following >paragraph: > >SAML responders SHOULD return a RADIUS state attribute as part of the >Access-Accept message so that future SAML queries can be run against the >same context of an authentication exchange. Good idea. >7. In section 6 - update the reference for NAI to draft-ietf-radext-nai Ok -- I had no idea the NAI was being updated (again). (I note that the new doc talks of "confederations", which I consider a synonym for "federation" in this context. Possibly the author of that doc might want to refer to ABFAB, by way of an example?) >8. In section 7.3.3 - I am not sure that the dependence on the abfab >document at the end of the section makes sense. For example, why should >the >EAP method support channel binding in order to return a SAML response? I >think that one can restrict the requirements to those in the AuthnRequest >and those necessitated by the application (whatever the application). You >probably just missed this in the general ABFAB removal. Correct; I'll remove. >9. In section 7.4.1 - I think the second paragraph can be removed and >placed in section 7.4.2. It is not related to the AuthnRequest but to the >Response. Ok. >10. In section 7.4.2 - I think we might need to make a statement about >returning no subject identifier and the correct interaction with the >AllowCreate attribute. If the IdP is not going to return a name, but is >just returning a subject conformation that says - the user associated with >this conversation - is this to be considered a "new identity" for the >user? I need to think about this; I will propose a form of words. >11. In section 7.4.2 - I have a problem with the last bullet point. I >would be happier if the text looked more like: > >Other conditions MAY be included as requested by the Relying Party or at >the >discretion of the Identity Provider. The Identity Provider is not >obligated >to honor the requested set of conditions in the <samlp:AuthnRequest>, if >any. If the Identity Provider does not honor the requested set of >conditions is MUST either not return a <samlp:Response> message or return >a ><samlp:Response> message with an error. The conditions included by the RP in the request are (SAMLCore section 3.4.1) "intended as input to the process of constructing the assertion, rather than as conditions on the use of the request itself". An assertion that include these conditions can always be discarded by the RP, so I am unclear what value the new sentence adds? >12. In section 9. I think in this case it would be useful to have an >informational reference to TEAP about mapping these from an EAP method to >the URIs specified. I'm not sure if we want to explicitly map the TEAP concepts of user and machine, although I admit that I don't have a strong argument against this. I suppose have a vague concern that in creating this linkage we might inadvertently constrain ourselves to TEAP's definition of 'user' or 'machine', or guide implementors/deployers towards use of a specific EAP method (I suppose that informative usage guards against this to some extent, but I could imagine an over-zealous interpretations of this). >s/artefacts/artifacts/ Thanks again for the review. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
