Comments on sstc-saml2-attribute-management-protocol-01

["Scott Cantor" <cantor.2@osu.edu>]

The major issue I have with the content as a whole is that I agree with a
comment made by Oracle that this needs to have, at minimum, semantics for
create/update/delete at the value level. Otherwise it's useful only for a
subset of attributes, but more importantly I think it would lead to
deployers contorting their attribute definitions to conform with the
limitations of the protocol. I would like to know what others think about
that issue.

Separately, I have a number of specific comments. This isn't exhaustive, as
there a number of fundamental issues with this before it could be considered
for CD.
 
Document will need to define both the protocol and specific profile(s) using
it, because conformance requires profiles. An example of this is found in
the Identity Provider Discovery Protocol and Profile document. It's somewhat
redundant but necessary for consistency.

Document also needs a conformance section before it can proceed, which would
need to be expressed in terms of one or more profiles defined in it.

Document needs XML namespace assigned, it's not in this draft. Suggest
urn:oasis:names:tc:SAML:2.0:profiles:attribute-management

A number of the references seem unnecessary, and at least a couple are out
of date.

The reference links in the document don't appear to be functional, as though
they were entered only as text and not actual references.

The document seems to omit any reference to Bindings, which will be
necessary in documenting a profile of the protocol.

There's no schema here that I can see. You can't take this forward until one
is defined for these messages, including both snippets in the draft and a
stand-alone schema.

To the extent that it's limited to this current "set all values" semantic, I
question the use of the <AttributeStatement> element in the examples rather
than just expressing the sequence of <Attribute> elements directly.
Statements have a specific purpose in the schema, and I don't think it's a
good idea to reuse them here.

Much of the security section should be addressed by moving such language to
normative statements about the use of bindings. For example, "The requester
MUST authenticate itself to the responder and ensure message integrity,
either by signing the message or using a binding-specific mechanism." Such
language can be found throughout the SAML Profiles document.

The specification mentions XML Encryption of the messages, but SAML does not
allow for that at the protocol layer. If use of EncryptedAttribute is deemed
too inefficient, additional schema work needs to be done here to address
that requirement.

-- Scott