Comments on draft-sstc-attribute-02

[Scott Cantor <cantor.2@osu.edu>]

As promised on the call, my overall comments on the proposal:

Standardizing multiple-valued and null-valued attributes:

I think we need to do both of these, and I support normative language saying
that multiple values should be carried in multiple <AttributeValue>
elements, and that a null value should be carried by relaxing minOccurs to 0
on <AttributeValue>. This allows us to distinguish a null value from a
non-existent or invisible attribute.

Attribute Scoping:

I think there's some general consensus across a few different
implementations that this is useful. But I'd note that this proposal is in
line with my submitted use case, which is a property of the AttributeValue
and not of the Attribute.

Attribute Issuer:

As I said on the call, I agree with Bob Morgan on this issue, and believe it
is currently supported using distinct assertions.

Data Typing:

As long as it's optional, and possible to incorporate the XSD data typing
system, I don't object to carrying a data type URI on the attribute. But I
still believe that any unique attribute definition should imply data typing.
If we end up requiring a user-specified (as opposed to automated) mapping
from SAML attribute names to XACML attribute names (see next issue), then I
believe there is little point to this addition because it won't solve the
real problem, which is unambiguously performing that mapping.

Attribute Naming:

Fundamentally this is about AttributeNamespace. I fully support (and
currently implement) the design proposed here, in which the Namespace + Name
provide the unique name for the attribute and the Namespace indicates the
format of the Name. This is not consistent with other SAML implementations
(all are correct, but we're doing different things). Furthermore, I believe
the advantages of eliminating AttributeNamespace and directly using URI
naming outweigh any of the arguments I've ever heard against it.

I think we should re-examine the original motivation for the two part naming
in SAML and if we still feel it's needed, then we should make sure that the
XML attributes are defined precisely enough to insure more consistency in
use. And then we can cross that with the requirements in this proposal and
see what needs to change.

In particular, if people are not in fact using AttributeNamespace as a part
of naming attributes, but rather for metadata about the attribute, we should
make that clear in the spec and also encourage use of URIs for
AttributeName. As it is, if we have only string names, we lack
interoperability for no good reason.

-- Scott