[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on sstc-saml2-attribute-management-protocol-01
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]