[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] comments on SAMLCore CD 01
The <sequence /> schema component can be removed; without any elements defined in the complexType, the content model is empty (modulo any defined attributes). The schema in CD 01 is perfectly legal syntax, though. Regards, John de Freitas -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Monday, August 23, 2004 11:54 AM To: de Freitas, John; security-services@lists.oasis-open.org Subject: RE: [security-services] comments on SAMLCore CD 01 Couple small comments... > 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 not an abstract type, but an element of an abstract type, and as such would appear as BaseID in a message if xsi:type is included. > 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. Because errors can occur for lots of other reasons. Maybe needs better wording, but to be honest, somebody else should provide it. I've tried at least 5 variations on this text. > 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. Right, that is the meaning. This is perfectly legal, and the alternatives aren't any better or clearer. > 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 algorithm stuff should be in conformance as it is. There are no use cases for encryption by different parties, although I suppose nothing precludes it and I don't know what we would need to say. Not sure what guidance would be needed for super-encryption either. As far as I could tell, the only profiling needed that isn't conformance-related is how to use some of the referencing options and key-passing elements. As it is, it's not a big deal because there aren't really security implications to any of that the way there were with signature transforms. I would be hesitant to start heavily profiling XML Encryption at this stage, and as long as we aren't changing schema, it's something that could be done in a future revision. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]