[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] comments on SAMLCore CD 01
Hi John, I was charged with providing a formal response that documents which of your suggestions have been incorporated, and which haven't (with some explanation). Where fixes are mentioned, these are in the post-CD drafts (CD-1b is the latest). > 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. Fixed. > 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>". <BaseID> is an element, not a type. Types cannot appear in instances, so it is correct usage to say that <BaseID> can and will appear in an instance. It just has to have an xsi:type with it. There are numerous cases of this in the spec (<Statement>, <Condition>). > 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. Fixed. > 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. I added some clarification to this. Signature validation is merely one of many things a responder has to do to determine the validity of a request. > 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". Fixed. > 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. Fixed. > 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. This is clarified. > Line 2256 - s/RegisterNameIDRequestType/ManageNameIDRequestType > > Line 2521 s/NameIDRequestType/NameIDResponseType > s/RequestAbstractType/StatusResponseType Fixed. > Line 3037 - No support for HTTP DELETE? Sections 8.1.1 and > 8.1.2 both have the notion of a delete operation. I think in the spirit of freezing the Authz functionality in favor of XACML, this has been left alone, since we'd have to add a new 2.0 identifier for this. I would have liked to see the language a bit stronger telling people that they should be very cautious about using the Authz pieces if they aren't already. > 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. The SSL stuff is gone, and has been moved to conformance where it belongs, and there are some Encryption-related algorithm requirements there now. The other issues don't appear (to us) to require any profiling. Examples will show up eventually, but are non-normative and since I don't have working code to produce them, I haven't done it. Thanks, -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]