1 / 18

Requirements for DSML 2.0

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

Download Presentation

Requirements for DSML 2.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related