1. Data Transport Standard Nathan Chitty Software Architect Nelnet April 24 th, 2007

3. Topics –Data Transport Standard (DTS) Defined –History of DTS Project –Current state of DTS –Business Flow Implementations –Technical Architecture discussion

4. DTS – Data Transport Standard – is a specification for an adjunct to or a replacement for existing data transport mechanisms: –FTP, “Secure FTP”, and/or Email –PGP / GnuPG encryption –SecretAgent

5. What is DTS? –DTS is a specification not a product –DTS was developed by the Postsecondary Education Standards Council (PESC) for exchanging data for: Inquiries Reports Transactions

6. What is DTS? –DTS uses Internet technologies to facilitate real time data exchange and transaction processing –DTS builds on stable technologies, not specific products –DTS, once implemented, reduces programming and per-transaction costs through standardization

7. DTS Technologies utilized –WSDL (Web Services Description Language) –SOAP (Simple Object Access Protocol) –WS-I (Web Services Interoperability) –HTTP (Hyper Text Transfer Protocol) –X.509 Certificates –zLib compression –Other Web Services specs (WS-*)

8. History of DTS - Topics –Original Business need/Justification –Business needs/requirements DTS SOAP:Header elements –Version 1 Interoperability issues Security and Public key management

9. History – Original Need/Justification –Overcome inefficiencies of existing transports Commonrecord:Commonline (CR:C) would reach current “standard” limits Separate encryption/authentication steps from transport Delivery confirmations –Industry desire to attain “real-time” processing

10. Business Requirements –Guarantee Delivery –Support immediate and deferred processing –Accommodate various technical platforms –Highly secure –Support larger payloads –No distribution royalties –Based on open standards –Useful for internal and external communications –Single transport for all business needs without evaluating payload

11. DTS addresses delivery issues –Web service implementation Requires synchronous response –Status message –Processed result payload –SOAP:Fault No response from service = client error –Order of delivery handled by client guaranteed confirmation enables confirmed hand- offs

12. DTS is Highly Secure –Use of Secure Sockets Layer (SSL) HTTPS – same as online banking Data encryption in the same step as transport –No longer a separate step or application –Use of Digital Signatures X.509 certificate and certificate authorities Strong authentication Non-repudiation

13. DTS can accommodate various technical platforms –Operating Systems Use of broader IT industry standards, not specific products Actually proven to work with Java and.Net –Size/Type of organizations Client only implementations (smaller organizations) –Push-Pull Deferred –Immediate Service and Client implementations –Push-Push Deferred –Immediate

14. Additional Data Elements defined –Elements defined but the contents are left to line of business Experience proved the necessity of certain information –DTS SOAP:Header elements

15. Request Headers –DTSRequestRouting –DTSRequestServiceExpectation –DTSRequestPayloadType –DTSRequestPayloadBytes –DTSRequestSignature Response Headers –DTSResponseRouting –DTSResponseAcknowledge –DTSResponsePayloadType –DTSResponsePayloadBytes –DTSResponseSignature

16. DTSRequestRouting and DTSResponseRouting –Routing Header elements sourceId sourceIdSubCode recipientId recipientIdSubCode UUID transmissionDateTime

17. Why SOAP:Headers? –Immediate/deferred processing (ServiceExpectation / Acknowledge) –Larger payloads (PayloadBytes) –Single transport for all process without evaluating payload (PayloadType) –Useful for internal and external transport (Source/Recipient)

18. Why SOAP:Headers? (cont.) –Map current EEAT filename components Filename –Format: A-B-X_Y_Z-M –Example: CRC01_REQUEST-02-DOE_004444_01-123 DTS Header Elements –DTSRequestPayloadType = A –DTSRequestRouting »sourceIdSubCode = X »sourceId = Y_Z »UUID = M

19. DTS Version 1 –Approved by PESC May, 2006 –How did we do it? –Problems encountered Overcame –Almost there! Security and Key Management

20. How did we do it? –Identified what and the proposed how –Created a working proof of concept for how Simple HelloWorld Service Added simple type SOAP:Headers –Not interoperable Added complex type SOAP:Headers –Not interoperable

21. Interop problems with SOAP:Header –xsi:type attribute must be in header tag Java includes and requires this attribute by default –Null reference exception during deserialization.Net does not need the attribute

22. Overcoming the Interop problem –SOAP transmitted across the wire of primary importance Element Name Type Attribute –.Net class declarations were augmented to force xsi:type attribute to be created during serialization Details are in the Reference Implementation Guide at http://www.pesc.org/workgroups/datatransport/http://www.pesc.org/workgroups/datatransport/

23. DTSv1 Security and Key Management –Highly Secure Using SSL (https) for transport X.509 Signatures –Strong Authentication –Non-repudiation –Protects against man-in-the-middle and modification of data

24. DTSv1 Security and Key Management – However, –DTS Signature proprietary header element –Out-of-band certificate exchange required Key management and exchange practices not improved

25. Current State of DTS (version 2) –New tools –No changes to interfaces –Reorganization of SOAP Headers –Integration of WS-Security (WS-S)

26. New Tools –Recent versions of Axis Java toolkit removed requirement of xsi:type Reduced complexity for.Net implemenations Easier inclusion of other WS-* specifications –WSS4J and MS-Web Service Enhancements (WSE) WS-Security integration

27. Reorganization of Headers (more like other WS-* specifications) <DTSRequestRouting xsi:type="DTSRequestRouting" xmlns="http://www.datatransportstandard.com"> <DTSRequestPayloadType xsi:type="DTSRequestPayloadType" xmlns="http://www.datatransportstandard.com"> CRC01Request <DTSRequestPayloadBytes xsi:type="DTSRequestPayloadBytes" xmlns="http://www.datatransportstandard.com"> 53 <DTSRequestServiceExpectation xsi:type="DTSRequestServiceExpectation" xmlns="http://www.datatransportstandard.com"> Immediate <DTSRequestSignature xsi:type="DTSRequestSignature" xmlns="http://www.datatransportstandard.com"> someting <DTSRequestHeader xmlns:dts="urn:org:pesc:datatransport" soap:mustUnderstand="1" soap:actor="urn:org:pesc:datatransport/dts" xmlns="urn:org:pesc:datatransport">... … Version 1 Version 2

28. WS-Security –Removed proprietary Signature element –Replaced with WS-Security complex element Including element

29. Binary Security Token Element –WS-S specification allows for the X.509 certificate to be included in the transmission –X.509 Certificate must be signed by Certificate Authority (CA) No need to exchange public key out-of-band Verification by chain of trust including the CA Single point of contact for updates and revocation

30. More Interoperability problems –.Net implementing WS-S via WSE Adds WS-Addressing elements to SOAP Creates interop problem with java Solution: –Output handler in ASP Pipeline to remove WS- Addressing elements

31. Current State wrap up –Version 1 approved (5/2006) –Version 2 with Change Control Board –Electronic Exchange Advisory Team has published Technical Manual with DTSv1 implementation defining specifics very little will be changed for DTSv2

32. Business Flow Implementations –Expected transactional flows

33. Immediate

34. “Push/Push” (part 1)

35. “Push/Push” (part 2)

36. “Push/Pull” (part 1)

37. “Push/Pull” (part 2)

38. Reference Implementation Architecture –Client Application –Client Core –Service Core –Service Application

39. Client Application –Knows nothing of SOAP or Web Services –Implements Client Core Interface “Setters” and “Getters” of DTS specific elements –Houses specific business logic

40. Client Core –Knows nothing of business logic –Uses properties set to construct the SOAP –Interface for “setting send” and “getting returned” elements –Handles the communication to Service Core- DTS Specification

41. Service Core –Accepts transmissions from Client Core –Implements Service Application Interface “Setters” and “Getters” of DTS specific elements –Creates return SOAP Format return acknowledgement or data from Service Application Construct SOAP faults

42. Service Core (cont) –Isolated business logic Examples –Invoke Service Application based on payload –Place payload in “queue”

43. Service Application –Interface for “setting sent” and “getting to be returned” elements –Houses specific business logic –Knows nothing of SOAP or Web Services

44. Connecting the Layers

50. Questions? Nathan Chitty Nelnet Software Architect nathan.chitty@nelnet.net (904) 631-1308 Thank You!