Subject: comments on SAMLCore CD 01
Some errata/minor edits for SAMLCore CD 01 (originally used the feedback form; doesn’t appear to be working?):
Line 330 – “An assertion is a package of information that supplies one or more statements…” Both the schema and other places in the text (like line 536) give the cardinality as zero or more.
Line 611 – Here and throughout the document, the <BaseID> element is used as if it could appear in some XML document context. However, it is an abstract type; perhaps it should be replaced with “A concrete type derived from <BaseID>”.
Line 1134 – Insert “non-schema simple” between “Specifying a “ and “datatype on <AttributeValue>”. An extension schema would not be needed for a built-in XML Schema type.
Line 1389 – If the signature is valid, why would the responder “MAY process the request or respond with an error”? See for comparison lines 1453-1455.
Line 1477 – Is <StatusDetail> only for error conditions? That is the interpretation here and at lines 1571-1572. However, lines 1497-1498 indicate that it can be used when the status is “success”.
Line 1984 – What is the point of the empty sequence (<sequence />)? It appears that the element doesn’t have any sub-elements (line 1955); this is also the case for line 2050.
Lines 2082-2083 – Please specify whether a set of assertions returned as the result of an <AuthnReqest> must supply a <AuthnStatement> in just one assertion, or in every assertion in the set.
Line 2256 – s/RegisterNameIDRequestType/ManageNameIDRequestType
Line 2521 s/NameIDRequestType/NameIDResponseType s/RequestAbstractType/StatusResponseType
Line 3037 – No support for HTTP DELETE? Sections 8.1.1 and 8.1.2 both have the notion of a delete operation.
In general – There is little guidance with regards to XML Encryption. It would help to offer some guidelines in areas like recommended algorithms (as is done with SSL/TLS), encryption by different parties, super-encryption, etc. Some (non-normative) examples would be especially useful.
John de Freitas