relationship of sec-tc/S2ML to other **ML (was: RE: IDMEF/IODEF)

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Prateek:

> One of the goals of the S2ML spec. was to provide a number of bindings
> for interactions based on a number of standard protocols. This has
> been called out in Section 6, Bindings to Messaging and Transport
> Protocols.
> ...
> I am puzzled tho' by your thought that this might be completely out of
> scope for this group.

I understand and agree that there should be several ways of moving our
as-yet-unnamed (call them S2ML-NG) assertions about, hence the need for
definitions of bindings.  My question was not about that, but rather about
the relationship, if any, between S2ML-NG assertions and other
protocols/formats that are being specified in XML.

SyncML might be an example.  I don't know anything about what SyncML does
for security and don't have time to look right now; I heard someone say
that the security features it specifies are minimal at best.  We might
say:  gosh there are a whole bunch of these kinds of things, almost all
being produced by folks who are not security-knowledgable, hence we would
be doing a wonderful thing if we specified a generic means for associating
security elements with whatever other XML elements an XML-based protocol
provides.  This would allow, say, the next rev of SyncML to say:  just
stick some S2ML-NG elements here and this provides desirable security
properties.

This could be interpreted to be consistent with our purpose:

  "The purpose of the XML-Based Security Services TC is to define an XML
  framework for exchanging authentication and authorization information."

and I'm mentioning it least partly because when I was describing the TC's
work to someone they assumed that this was what we're up to.

Thinking further about this, I think there are a few different aspects to
the question of the relation of other protocols to our work and that at
least some of the below will be worth covering in our docs.

I imagine that we would all agree that in most use cases the structures we
are designing are not exchanged for their own sake but to establish
security properties of an association that can then be used to do some
other work.  So, if, say, SyncML has a notion of a session, and that
session has security properties that are meaningful to SyncML peers, then
it would (IMHO) be entirely reasonable to use S2ML-NG to establish those
properties (some other security scheme might also be used).  This kind of
use applies of course regardless of whether the other-work protocol is
XML-based or not, and has more to do with whether that protocol also uses
the lower-level transport (HTTP, etc) to which S2ML-NG is bound.

While we could hope that this kind of use would "just happen" without its
having to be specified at all by us, let me suggest that we might want to
cover this kind of thing, maybe with a real-life example, as part of
security considerations, as an example of a domain of applicability of the
S2ML-NG work.  This consideration might also affect how we specify
S2ML-NG's relation to security features of its underlying transports.

For XML-based protocols, as I mention above, a closer relationship might
be possible where S2ML-NG XML elements get incorporated directly into the
XML elements of the other protocol (or the reverse, other protocol
elements in S2ML-NG).  I suspect we would agree that this is a can of
worms that we would rather place out of scope, at least for the moment.
It might be worth saying this explicitly somewhere, so we remember it when
this comes up again, as I bet it will.

 - RL "Bob"