Subject: Re: [security-services] Comments on Work Item 28b: AttributeReconciliation between XACML and SAML
These are mostly my comments on the proposal and not a response to Irving's, but it's easier to start with his ... On Tue, 21 Oct 2003, Reid, Irving wrote: > The more XML specs I see (and, to be honest, I haven't seen _that_ > many), the more I prefer a minimal approach to schema design. I agree that additional elements have to be strongly justified as being worth the additional complexity at design-/deployment-/run-time. Our Internet2 activities are often about advising campus infrastructure architects on making effective use of the myriad knobs and whistles in common technology. Each additional element is a place where conventions for use have to be established and strongly promoted, or interoperability becomes impossible. > 1) Change the semantics of the "AttributeNamespace" XML attribute. The > old interpretation was as a "grouping" of attributes to reflect a > pre-negotiated interpretation of both the attribute name and value. The > new proposal is to use this attribute to identify the textual > interpretation of the attribute name, ie. OID, URN, etc. I disagree, I guess with both Irving and with the proposal, that having standard AttributeNamespace identifiers for common cases is a change in usage of AttributeNamespace. In fact my still-forthcoming proposal for a convention for naming X.500/LDAP attributes in SAML is exactly of this nature: an AttributeNamespace URI that would unambiguously identify 100% of attributes defined using X.500/LDAP schema definition rules. As far as I know there are no existing public conventions for how AttributeNamespace and AttributeName are used by any SAML designers/deployers (I have written one describing the conventions embedded in the Internet2 Shibboleth implementation, but it hasn't been published yet). So I don't know how any claim can be made that there is an existing style or semantics for these elements. It seems to me that if one kind of "pre-negotiated interpretation" is a convention that can be widely used by lots of deployments, we all bettah off. If this convention can represent the AttributeName as a URI and thus be consistent with XACML's choice to represent its AttributeId as a URI, this is fine by me. I don't believe the world can be limited to just using this convention, however, so real XACML implementations will be obliged to handle SAML attribute statements (and other forms of attribute input) that require an implementation-specific mapping to a URI to fit the XACML schema. > 2) Add an optional "Issuer", with a corresponding "Format". First, the > "Format" should be "IssuerFormat" to make it clear we're talking about > the format of the "Issuer" attribute, not of the attribute value. > > I'm not entirely sure what the "Issuer" attribute is supposed to mean. > Is it a rough replacement for the existing "AttributeNamespace", that > is, a way of identifying the context of the attribute? Or do you intend > to allow a new assertion semantic? > ... > I think that the semantic subtleties of this are far beyond what the > average administrator will be able to understand and correctly > configure. I agree that a per-attribute Issuer is, as far as I can see, a complication that doesn't seem necessary. The semantics of a SAML Attribute Statement, contained in a SAML Assertion, is that the Issuer of the Assertion is the authority making the statement about this Subject having these Attributes. I think this is useful and understandable as it is. More complex semantics, such as "this Issuer says that Issuer says X" could be handled by additional structures, such as an attribute that is itself an assertion. > 3) Add a "DataType" attribute to indicate the type of the corresponding > AttributeValue. For this one, I'd like to see a clear argument for why > we couldn't use xsi:type or namespaces to solve the problem. I find this part of the proposal puzzling to begin with. In the sorts of data distribution systems I'm familiar with (LDAP primarily, also RDBMS), schema defines datatypes as part of defining attributes (columns in dbms). What is the use case for having an attribute type definition (to use LDAP terminology) that doesn't also define the datatype (ie syntax, in LDAP) of values? If the point of the proposal is to send schema info, I'm not aware of any other technology that sends schema info inband, mixed with data itself. If the intent is that by sending schema along with the data recipients could handle new attribute types dynamically, well, X.500 and LDAP have supported schema discovery for a long time, and the real-world observation is that applications are built to use concrete schema, so schema discovery never gets used for more than demos. Stepping back, I have to wonder about the goals for the alignment that's being proposed here. As I understand it, an attribute designator in XACML would be used as part of defining a policy, where such a policy might say "if the subject has attribute X from issuer A, and attribute Y from issuer B, then ...". So decorating attribute-value instances with issuer (and maybe even datatype) etc makes sense. But a SAML attribute statement is a different thing: it just expresses some attr-value instances about a subject, as asserted by a single issuer. I would think that the processing model would be for a SAML attribute assertion to be mapped into a XACML-canonical form for policy evaluation purposes, and the requirement is that this be able to be done unambiguously. And so it can: the SAML assertion Issuer becomes the per-attribute issuer in the XACML attribute, its datatype is copied, etc. But saying that the on-the-wire assertion format has to match the fully-splayed-out matchable format seems like mixing phases to me. So, in summary: I agree with the proposed use of AttributeNamespace, but don't think the proposed Datatype and Issuer (XML)attributes should be added. - RL "Bob"