RE: [security-services] comments on SAMLCore CD 01

["Scott Cantor" <cantor.2@osu.edu>]

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