[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on Attributes in Draft 08 e-draft-03-diff
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]