OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments re: sstc-maler-w28a-attribute-draft-02.pdf

Not much to say:

- where suggestion is made to change AttributeNamespace to NameFormat, the
proposal then erroneously suggests it be named AttributeFormat

- also suggest that the NameFormat URIs be something like
attrname-format:uri instead of att-format:uri for similar reasons

- still generally uncomfortable with the xsi:type vs. ValueType issue, but I
like the idea of making xsi:type uniform across values. Would like to
actually deprecate or at least discourage use of xsi:type anyway, since it
harms interoperability for validating implementations.

My only real substantive comment is on 3.2, the NameFormat URIs being
enumerated. I wonder if we need more than just
urn:oasis:names:tc:SAML:2.0:att-format:uri and the unspecified one. If the
name is a URI, then it is by necessity unambiguous, and it seems like the
use of OIDs or GUIDs can then be left to attribute profiles that describe
how to assign URIs to certain classes of attributes, but doesn't need to
clutter the processing in core.

Is there a separate use case for wanting to know that something is an X.500
attribute as opposed to simply knowing that it's a particular X.500

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]