Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jul 2012 15:20:31 -0400

Jim, per our discussion, I've added text to gss-eap-naming-03 indicating
that today we're not defining the semantics of setting these attributes.
>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Sam & Josh,
    Jim> This document looks good, only a couple of issues most of which are probably
    Jim> not too contentious.  In terms of tone, I am making the assumption that
    Jim> there is nothing in the naming that prevents a set as well as a get for many
    Jim> of the properties.  I am not sure that it makes any sense to do a set for
    Jim> SAML Attributes and maybe Name Identifiers, just the entire SAML statement.
    Jim> That could potentially be done via the RADIUS attribute and just say that
    Jim> all of the fed-saml-* names are read-only names.  I don't know if this is a
    Jim> GSS-API concept or not.

    Jim> Jim

    Jim> Major:

    Jim> 1.  In section 5 - I believe the following text should be added to the last
    Jim> paragraph.  "If more than one attribute for the name exists in the packet, a
    Jim> multi-valued value is returned."

    Jim> 2. In section 5 - What text do we need to put in here about the temporal
    Jim> nature of the values?  I assume, but don't know, that all of the values
    Jim> would be wiped out and a new set of values would be populated when, and if,
    Jim> a new RADIUS response is received.  An alternative would be to state that
    Jim> only some values are over-written - either a specific set or those with new
    Jim> values.  I do not believe that we generally want to always just append
    Jim> values together.  This would lead to possibly n State attribute values, one
    Jim> for every RADIUS message pair exchanged.

    Jim> 3. In section 5 - Is there a need for the Code of the last packet to be
    Jim> retrievable from the GSS-API interface?  This is not currently doable. 

    Jim> 4.  In section 5/6.1 - There is a restriction on getting the SAML assertion
    Jim> via the fed-saml-assertion name.  Does the same restriction exist if the
    Jim> value is retrieved via the radius-attr name?

    Jim> 5. In section 6 - Is there a need to distinguish between the an empty
    Jim> AttributeValue and a Nil AttributeValue.  There is text in 2.7.3.1 of
    Jim> SAML-CORE-2.0 that does so, but it is not reflected in section 6.2.
    Jim> Minor:

    Jim> 1.  In section 4 para #5 - I think that s/MUST not/MUST NOT/  - however -
    Jim> how would that GSS-API code be able to possibly enforce the requirement?