Comments on Work Item 28b: Attribute Reconciliation between XACML and SAML

["Reid, Irving" <irving.reid@hp.com>]

I'm going to start with a bit of a philosophical rant here; I'll try to keep it short...

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. As I see it, the fewer software components that need to care what's inside any given element, the easier it is to compose solutions. When someone does need to look inside an element, they should be able to do it with standard XML mechanisms like XSLT, XQuery, etc. This leads to an approach where the schema defines a thin framework, with type="any" in almost every element.

I see SAML and WS-Security (especially WSS) going down a road of requiring every piece of code that handles a document to understand the entire document, and often look inside almost every element in case there's something relevant inside. This leads to thousands of lines of wasted code, manipulating elements that the application wishes it didn't have to care about.

The other part of the minimalist philosophy is to not invent new mechanisms where XML already provides one (or more). For example, every time we want to add a new namespace or type designator, we need to ask "can this be done with xsi:type or XML namespaces?" I'll grant that sometimes the answer to that question will be "no", but I suspect there are plenty of XML schemas that could be made a lot simpler.


OK, enough of that. Corner me by a whiteboard some time and ask about my 6-line XML Schema for SAML...


My comments are based on Rebekah Lepro's submission of Tuesday, Sept. 30. Line numbers refer to the PDF document linked below.

> From: rlepro@arc.nasa.gov [mailto:rlepro@arc.nasa.gov]
> Sent: Tuesday, September 30, 2003 12:32 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Groups - 28b-draft-solution-0.1.pdf uploaded
>
> Document Description:
> Initial draft of a proposed solution for attribute 
> reconciliation between SAML and XACML.  Also considers a 
> solution to several existing use cases presented on the mailing list.
> 
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/3666/28b-draft-solution-0.1.pdf


I've been struggling with how to approach this issue, and trying to pin down why I feel uncomfortable with this proposal. The meat of the matter starts at line 15, Proposed Solution; all changes are to the "AttributeDescriptorType" schema.


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.

Rather than re-use AttributeNamespace, if we want this added complexity we should add a new "AttributeNameFormat" attribute.


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?

Existing assertions look like:

Andy asserts that Chris is Blue (Andy is issuer, Chris is subject, Blue is attribute)

Are you proposing to support:

Andy asserts that Jean says that Chris is Blue (adding Jean as the attribute issuer)

I think that the semantic subtleties of this are far beyond what the average administrator will be able to understand and correctly configure.


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'm concerned about the effect of adding extra attributes, even if they are optional. Unless we have very specific guidance in our profiles, a relying party can't ignore them - after all, how can we know for sure whether

<Attribute name="foo" nameFormat="uri">...</Attribute>

and

<Attribute name="foo">...</Attribute>

are supposed to be interpreted as the same.


I'm having a hard time figuring out how to express my big concern, but here goes. I feel like every time we touch this spec (and WS-Security, and many others like them...) we're making it harder and harder for people to successfully implement the specifications. Worse yet, I think the complexity we're adding means that even if a piece of software correctly implements the specification, it will be prohibitively difficult for users to figure out how the software works. In normal circumstances this is a major problem. With security-related specifications, it's much worse. We simply cannot expect even well-trained computer scientists to be able to tell whether they're getting it right. There are too many examples of well-meaning but broken-by-design security mechanisms already.

Unfortunately, the next question is "what do I suggest we do about it?". I wish I could answer that. We don't want to start over from scratch, so I guess what I'm looking for is an evolutionary attitude that goes back to what I said at the beginning of this message. Wherever possible, we need to look at ways to solve new use cases by simplifying the schema rather than making it more complex.

 - irving -