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

3
RFC 2251 fidelity

• Means anything you can do with LDAP still makes
  sense, client can use either
• But doesnt include bind
• Does include extended operations and controls
  (agreed but question whether they work well).
  Basic controls needed to support raw
  extensibility.
• Doesnt 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

• Dont want new protocols
• Dont want divergence in way protocols are
  handled
• 2251 conformance necessary but not sufficient
• What about LDAP extensions, VLV etc?
• Just make an alternative representation, dont
  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 doesnt have to serial is default and can
  be used even where parallel is indicated
• So its 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//hostport.dcxx . .
• 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
• Dont want to rely on SAML for any authentication
• SAML may be interested in using DSML, but dont
  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
• Doesnt 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 cant say that an attribute must
  be either a string or two or more value tags. Eg.
  Cant 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)