Re: [security-services] Comments on draft-sstc-attribute-02

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Scott Cantor wrote:
 > As promised on the call, my overall comments on the proposal:

I, too, took an action (aeons ago) to send my comments on this proposal 
to the list...  I'll respond mostly by building on top of Scott's notes 
below.  For reference, here's the location of the proposal:

http://www.oasis-open.org/apps/org/workgroup/security/download.php/4884/draft-sstc-attribute-02.pdf

(For some reason, I'm not seeing the same line and section numbers on 
[SAMLCore] V1.1 that are referenced in the proposal; not sure why that 
is.  So I'm guessing a bit on the correspondence between the two.)

On to the proposals made in the paper:


Section 2, requirements:

 > Standardizing multiple-valued and null-valued attributes:
 >
 > I think we need to do both of these, and I support normative language 
saying
 > that multiple values should be carried in multiple <AttributeValue>
 > elements, and that a null value should be carried by relaxing 
minOccurs to 0
 > on <AttributeValue>. This allows us to distinguish a null value from a
 > non-existent or invisible attribute.

Scott added some text to the core-03 draft, and I tweaked it in core-04, 
with the following result:

"<AttributeValue> [Any Number]  The value of the attribute. If an 
attribute contains more than one discrete value, it is RECOMMENDED that 
each value appear in its own <AttributeValue> element. If the value of 
the attribute is "NULL" or "empty", then the <AttributeValue> element be 
omitted."

(Oops, I had meant to change "can" to "MAY" in the final phrase, but 
screwed up the edit.  Need to insert "MAY".)

If it's possible to crisply define what it means to be "an" attribute 
value, then it might be worth it to change at least one of these 
instructions to MUST.  But if not, then not.


Section 4.1, AttributeNamespace:

 > Attribute Naming:
 >
 > Fundamentally this is about AttributeNamespace. I fully support (and
 > currently implement) the design proposed here, in which the Namespace 
+ Name
 > provide the unique name for the attribute and the Namespace indicates the
 > format of the Name. This is not consistent with other SAML 
implementations
 > (all are correct, but we're doing different things). Furthermore, I 
believe
 > the advantages of eliminating AttributeNamespace and directly using URI
 > naming outweigh any of the arguments I've ever heard against it.
 >
 > I think we should re-examine the original motivation for the two part 
naming
 > in SAML and if we still feel it's needed, then we should make sure 
that the
 > XML attributes are defined precisely enough to insure more consistency in
 > use. And then we can cross that with the requirements in this 
proposal and
 > see what needs to change.
 >
 > In particular, if people are not in fact using AttributeNamespace as 
a part
 > of naming attributes, but rather for metadata about the attribute, we 
should
 > make that clear in the spec and also encourage use of URIs for
 > AttributeName. As it is, if we have only string names, we lack
 > interoperability for no good reason.

The proposal in Section 4.1 of the paper would certainly bring attribute 
"namespaces" more in line with the other URI-based identifier mechanisms 
we've used elsewhere.  If there's not significant opposition, we should 
consider doing this.  I'd probably also want to rename the 
AttributeNamespace attribute to something like AttributeNameFormat (to 
be understood as "attribute name interpretation", as we've discussed 
when dealing with name identifier formats etc.).


Section 4.2, AttributeDesignatorType:

I'm not sure what text is being suggested to be deleted and why.


Section 4.3, BaseAttributeType:

I'm not sure what utility this adds to the existing AttributeType, which 
does the same thing and can be extended (as well as used directly, which 
BaseAttributeType couldn't).  If we did add this, it should be called 
AttributeAbstractType, BTW.


Section 4.4, IssuedAttributeType:

 > Attribute Issuer:
 >
 > As I said on the call, I agree with Bob Morgan on this issue, and 
believe it
 > is currently supported using distinct assertions.

+1


Section 4.5, TypedAttributeType:

 > Data Typing:
 >
 > As long as it's optional, and possible to incorporate the XSD data typing
 > system, I don't object to carrying a data type URI on the attribute. 
But I
 > still believe that any unique attribute definition should imply data 
typing.
 > If we end up requiring a user-specified (as opposed to automated) mapping
 > from SAML attribute names to XACML attribute names (see next issue), 
then I
 > believe there is little point to this addition because it won't solve the
 > real problem, which is unambiguously performing that mapping.

I wonder if this wants to be an XACML extension to SAML?  If we do add 
this, then we'd need to offer <TypedAttribute> as an alternative to 
<Attribute> in an <xs:choice> group inside attribute statements, yes? 
And if we do add this, I think ValueFormat is a nice descriptive name 
for what this is trying to do.


Section 4.6, AttributeValue:

(Oops, it's an error to say that xs:anyType is a simple type!  I can fix 
this.)

It appears that this proposal nets out to (a) ensuring through spec 
prose that multiple occurrences of this element within a single parent 
will have identical types, and (b) ensuring through spec prose that such 
type will be semantically compatible with the type expressed in 
ValueFormat on any <TypedAttribute> parent.  The first one sounds like a 
testable assertion (through XSD-friendly means), but the second one 
doesn't...


Section 4.7, Scoped Attribute Value:

 > Attribute Scoping:
 >
 > I think there's some general consensus across a few different
 > implementations that this is useful. But I'd note that this proposal 
is in
 > line with my submitted use case, which is a property of the 
AttributeValue
 > and not of the Attribute.

Scoping remains semantically undefined in the proposed new text, so I'm 
not sure if exactly the same thing is meant here as in the F2Fs where 
it's been discussed.  I had thought that the request from RSA and others 
was that this be on the attribute as a whole, though.  And if we do add 
this notion (assuming I understand it correctly!), why can't we add an 
optional Scope attribute on AttributeType (or AttributeValueType) rather 
than having a special type just for this addition?


Hope these thoughts help as we head into the F2F,

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com