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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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.

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

> 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

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]