[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: relationship of sec-tc/S2ML to other **ML (was: RE: IDMEF/IODEF)
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"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC