[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Comments re:sstc-maler-w28a-attribute-draft-02.pdf
Thanks for commenting on this. Can others please take a look and comment? We didn't get to this on Tuesday's call and it will be a while before we get a chance to make formal decisions again; it would be great if we could knock off W-28a for good on March 16. Eve Scott Cantor wrote: > 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 > attribute? > > -- Scott -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]