Requirements for DSML 2.0

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

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.

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

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)

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)

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.

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

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

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.

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

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.

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

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

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.

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

XML Schema Potential v3 item.

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)