Re: [security-services] Comments on Work Item 28b: AttributeReconciliation between XACML and SAML

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

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"