Comments on Attributes in Draft 08 e-draft-03-diff

[Anne Anderson <Anne.Anderson@Sun.COM>]

Some problems with the specification of Attributes in Draft 08:

1. NameFormat [Required]
     A URI reference representing the classification of
     the attribute name for purposes of interpreting the name.
     See Section 7.x for some URI references that MAY be used as
     the value of the NameFormat attribute and their associated
     descriptions and processing rules.  If no NameFormat value
     is provided, the identifier
     urn:oasis:names:tc:SAML:2.0:attname-format:unspecified (see
     Section 7.x) is in effect.  Type="anyURI".

   Comment: If NameFormat is intended to map to a schema
     specification (or surrogate) in which the name is defined,
     please say so.  "A URI reference representing the
     classification of the attribute name for purposes of
     interpreting the name" could mean as many things to as many
     people as "NameQualifier" and "NameSpace" did.

2. Source [Optional]
     The source location or database from which the attribute
     came.  Interpretation of the source information is
     application-specific.  Type="string".

   Comment:
     Is source a "database type" or a specific database
     repository location?  If it is a repository location, say so
     and make the type "anyURI", saying it SHOULD be a URL.
     Also, if Source remains of type "string", there is the
     possibility of name collisions.

3. Arbitrary attributes
     This complex type uses an <xsd:anyAttribute> extension point
     to allow for arbitrary XML attributes to be added to
     <Attribute> constructs without the need for an explicit
     schema extension.  This allows additional fields to be added
     as needed to supply the context in which the attribute
     should be understood.  SAML extensions MUST NOT add local
     (non-namespace-qualified) XML attribuets to the
     AttributeType complex type or to any element bound to this
     type or a derivations of it; such attributes are reserved
     for future maintenance and enhancement of SAML itself.

   Comment:
     The addition of facilities such as this guarantees
     non-interoperability and makes it impossible to specify
     standard mappings to other Attribute formats.  It is likely
     to be mis-used, and common mis-uses then become defacto
     standards that everyone has to work around.  Define any
     number of specific, optional attributes instead, but make
     sure each has a VERY clear semantic.

4. Name and NameFormat

   Comment: will these ever be used separately?  Does anyone ever
     want "all instances of the 'gorp' Attribute", regardless of
     the NameFormat, or "all instances of Attributes with
     NameFormat 'urn:oasis:tc:xacml:', regardless of the
     Attribute's Name.  If not, at least define ONE scheme for
     the NameFormat URI (such as "urn:") so that NameFormat and
     Name can be concatenated using a single known separator
     character (such as ":").  This will make mapping much easier
     for systems that require unique identifiers for Attributes.
     Even better would be to specify one unique name combining
     Name and NameFormat.

5. ValueType

   Comment: Reconsider making this "required" instead of
     "optional".  Other standards groups have discovered that a
     data type is necessary in the Attribute metadata in order to
     handle type checking.  Having it be optional means only
     certain Attributes can be handled easily by systems that
     require type checking.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692