Sam & Josh, This document looks good, only a couple of issues most of which are probably not too contentious. In terms of tone, I am making the assumption that there is nothing in the naming that prevents a set as well as a get for many of the properties. I am not sure that it makes any sense to do a set for SAML Attributes and maybe Name Identifiers, just the entire SAML statement. That could potentially be done via the RADIUS attribute and just say that all of the fed-saml-* names are read-only names. I don't know if this is a GSS-API concept or not.
Jim Major: 1. In section 5 - I believe the following text should be added to the last paragraph. "If more than one attribute for the name exists in the packet, a multi-valued value is returned." 2. In section 5 - What text do we need to put in here about the temporal nature of the values? I assume, but don't know, that all of the values would be wiped out and a new set of values would be populated when, and if, a new RADIUS response is received. An alternative would be to state that only some values are over-written - either a specific set or those with new values. I do not believe that we generally want to always just append values together. This would lead to possibly n State attribute values, one for every RADIUS message pair exchanged. 3. In section 5 - Is there a need for the Code of the last packet to be retrievable from the GSS-API interface? This is not currently doable. 4. In section 5/6.1 - There is a restriction on getting the SAML assertion via the fed-saml-assertion name. Does the same restriction exist if the value is retrieved via the radius-attr name? 5. In section 6 - Is there a need to distinguish between the an empty AttributeValue and a Nil AttributeValue. There is text in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not reflected in section 6.2. Minor: 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - however - how would that GSS-API code be able to possibly enforce the requirement? _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
