Requirements for DSML 2.0

1. Requirements for DSML 2.0

2. Summary • RFC 2251 fidelity • Represent existing directory protocols with new transport syntax • Backwards compatibility with DSML 1 • Use XML - AGREED • Transport protocol independence • OOB security • Directory interoperability for very common operations – UNRESOLVED, DEFER • Optional knowledge of tree structure – UNRESOLVED, DEFER • Batching • URL naming • Defined relation to SAML • Done in 3 months • Unsolicited notification of change • XSLT-friendly • Different types of referral • Schema discovery • Ability to define enums, ranges etc. • Makes use of XML schema • Can be expressed with a DTD • It should be possible to create a DSML 2 gateway to existing LDAP servers - AGREED • LDAP v3 is assumed - AGREED • Should allow you to do anything you can do in LDIF - AGREED

3. RFC 2251 fidelity • Means anything you can do with LDAP still makes sense, client can use either • But doesn’t include bind • Does include extended operations and controls (agreed but question whether they work well). Basic controls needed to support raw extensibility. • Doesn’t include inetorgperson, 2256, etc. • Need 2252, 2253, 2254, 2255 et al also? – no 2251 is core • What do we use for the filter representation? • How we represent stuff is less crucial than that there is a mapping of the operations.

4. Questions on RFC 2251 fidelity • Is it limited to request/response – not async ops or unsolicited notifications

5. Represent existing directory protocols with new transport syntax • Don’t want new protocols • Don’t want divergence in way protocols are handled • 2251 conformance necessary but not sufficient • What about LDAP extensions, VLV etc? • Just make an alternative representation, don’t try to solve LDAP problems in DSML • Proposed additions that might provide functionality not in LDAP should be evaluated very carefully. (Eg. specifying serial/parallel operation and interoperability for common operations)

6. Backwards compatibility with DSML 1 • Do we use DSML 1 syntax where possible? • Attributes with structured syntax could be a problem – want to make them more XSLT-friendly (they are opaque in DSML 1.0)

7. Transport protocol independence • Bind, async operations are issues. • We should identify specific protocols that can be used. • If simple request/response, then can use any protocol • Could be useful to have standard mappings to some particular protocols.

8. OOB Authentication • Do credentials stay in the transport layer or can they be exposed at the application layer? • Have transport credentials at application layer plus additional credentials also • Issue of re-using secured connections for performance reasons • Require OOB authentication and have inband authentication as an option also? • How is identity asserted for access control? • Is there a man-in-the-middle attack if authentication is OOB? • Should Id and authentication information be included in DSML? AGREED NOT • I.e. agreed no inband authentication

9. Batching • DSML should not specify serialism or parallelism of operations • With a large number of operations, it can be valuable to be able to say which can be performed in parallel • This can make processing complex • But doesn’t have to – serial is default and can be used even where parallel is indicated • So it’s OK provided it is truly optional – agreed should be an explicitly stated advisory option in DSML 2

10. URI naming • Ability to access a URI that has a directory operation encoded in it and have the result of the operation returned in DSML (a la LDAP URL) • Have to understand what this means in context of transport independence. • Eg dsml://host:port.dc=xx . . • Are they needed for referrals? • Defer until we have a written proposal.

11. Defined relationship to SAML • Use of DSML by SAML and use of SAML by DSML • Don’t want to rely on SAML for any authentication • SAML may be interested in using DSML, but don’t want to hold DSML work up

12. Unsolicited notification of change • Related to lcup? • Has to be protocol-dependent • Leave it to post 2.0? Could then be harder to put it in if we want to • Doesn’t impact the format of DSML • But would want to include unsolicited notification (from 2251) in the DTD • Agreed defer pending receipt of a written proposal.

13. XSLT-friendly • Structured attributes – eg comma-delimited not tagged – harder to process. More general XML issue than just XSLT • Agreed that this is an aim

14. Different types of referral • Referral v Continuation reference • Issue of LDAP URL • Agree do what LDAP does & defer anything above this to v 3.0 • There are broader issues beyond LDAP that should be addressed, but later

15. Schema discovery • LDAP supports this, but way you do it may differ between LDAP servers • The LDAP standards do cover this • Group needs to validate what products do • Should there be a standard translation that transforms the LDAP representation of the schema to XML? • But given timescale we should leave things other than just doing what LDAP does to a later version.

16. Ability to define enums, ranges etc. • Aids processing text strings that have internal structure • Should be addressed at the LDAP level rather than the DSML level

17. XML Schema • Potential v3 item.

18. Can be expressed with a DTD • Ie – the DSML language itself should be able to be so expressed • DTDs have limited capability to express certain things – such as can’t say that an attribute must be either a string or two or more value tags. Eg. Can’t precisely express rules for a credit card number. • XML schema should be provided as a bare minimum • There are many DTD-oriented XML tools, some recently that work on schema. • Desirable to have a DTD but • MS draft uses a schema • Leave as open issue. • Do as schema first – then consider making DTD (but leave schema as the normative version)