OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public Comment


Comment from: john_de_f@hotmail.com

Some errata/minor items for SAMLCore, CD 01:

Line 330 - "An assertion is a package of information that supplies oneor more statements...". The schema shows that the cardinality is zero or more; also see line 536 for the same issue.

Line 611 (and recurring throughout the document) - <BaseID> is often mentioned as if it could appear as a subject identifier, but it is an abstract type. Perhaps replace with something like "A type derived from <BaseID>" in these situations.

Line 1134 - Add "non-simple XML Schema" between "Specifying a " and "datatype on <AttributeValue>. A built-in XML Schema datatype would not require the extension schema to be available at processing time.

Line 1389 - Why would the responder MAY respond with an error if the signature is valid? Compare, for instance, with lines 1454 and 1455.

Line 1477 - Is the content of <StatusDetail> for error conditions only? Lines 1497-1498 indicate that a success status may use this element, but 1571-1572 again mention that it is for an error condition.

Line 1984 - What is the purpose of the empty sequence (<sequence />)? This occurs in a few other places as well (e.g., line 2050).

Lines 2082-2083 - Need to specify whether a set of assertions responding to an <AuthnRequest> must contain at least one <AuthnStatement> in just one of the assertions, or in every assertion in the returned set; the language is unclear.

Line 2256 - Typo: replace "RegisterNameIDRequestType" with "ManageNameIDRequestType".

Line 2521 - Typo: replace "NameIDMappingRequestType" and "RequestAbstractType" with "NameIDMappingResponseType" and "StatusResponseType", respectively.

Line 3037 - No support for HTTP DELETE? Sections 8.1.1 and 8.1.2 both support the notion of a delete operation.

In general - XML Encryption is not profiled in a meaningful way. At the very least, guidance on algorithms, key exchanges, etc., should at least be given some treatment. Ideally, some treatment of processing rules and guidelines would include encryption by multiple parties, super-encryption, some (non-normative) examples, etc.

Regards,
John de Freitas




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]