SOAP based WS* Standards and MISMO

1. SOAP based WS* Standards and MISMO

2. Agenda • Review standards & technologies relating to SOAP, XML, Web Services, and the WS* standards • Roadmap for moving MISMO towards a SOAP based solution • Industry’s challenges, advantages, disadvantages of moving to a SOAP based communications framework

3. What is SOAP? • A standardized message structure based on the XML Infoset • A processing model that describes how a service should process the messages • A mechanism to bind SOAP messages to different network transport protocols • A way to attach non-XML encoded information to SOAP messages • Current version 1.2

4. What is SOAP? • 3 aspects of SOAP Message • Envelope • Header • Body

5. XML Based Protocol Independent Standards based Extendable Supports an extension model similar to MISMO today. Robust High adoption rate Cross industry buy in Seasoned Standard since (2000) Strong 3rd party support Independent of Web Services Web services have an implementation as SOAP based extensions. Protocol Dependant SOAP over MQ HTTP SOAP is SOAP is not

6. What are Web Services? • W3C Definition • A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.

7. What are the WS* Specifications/Standards? • A set of requirements that codify typical problem areas trading partners face when communicating over the internet. • XML based specifications and standards • SOAP based extensions

8. WS* SOAP Based Standards/Extensions Stack

9. Can MISMO use SOAP without Web Services? • Yes • SOAP is an independent specification • A complete Web Service-based solution is out of scope • Discovery • Description • SOAP and Web Services are two independent adoptions • There are SOAP extensions that have nothing to do with Web Services • SOAP allows MISMO to create their own extensions if we desire • Some WS Standards do not deal with the concepts of Web Services • Other WS Standards require the core concepts of Web Services and are designed to support these services

10. Current MISMO challenges that SOAP can help solve. • Security • XML encryption • Authentication (Digital signatures) • Routing • Flexibility to identify multiple intermediaries via pass through headers • Messaging • Unique message identification • Large attachments/Messages • Preferred Response(s) • Compression

11. Mapping MISMO to SOAP and WS* • Can be implemented in several different ways, all that are within the SOAP spec are “right”. • Standards/Specifications allow us to leverage multi-industry experts experience and knowledge.

12. What else can SOAP provide MISMO? • Allow MISMO to concentrate on the business of real estate transactions properties, borrowers, products . • Increased adoption/speed of integration by using open standards, tools, and 3rd party products. • Flexibility to allow MISMO workgroups to continue to push forward on pressing issues

13. Roadmap to SOAP, WS* • Evolution not revolution • Decide what can be placed in SOAP headers and what can stay in body • Decide whether to use current standards or leverage SOAP extensibility (e.g. with an oversight body & approval) • Complete proof of concept • Begin with basic SOAP headers • WS-Addressing • WS-Security • WS-Reliable Messaging

14. Which WS* Standards make sense for MISMO? • Phase 1: Direct mappings to MISMO Envelope today • WS-Addressing • WS-Security MISMO Security Workgroup • WS-Reliable Messaging • Phase 2: Possible in the near future • WS-Coordination- Multi-Services Workgroup • WS-Eventing • WS-Transaction • WS-Coordination- Multi-Services Workgroup • WS-BEPL- BREW • Phase 3: Potential Long Term Options • WS-Metadata Exchange • WS-Policy

15. SOAP Envelope SOAP Header Security Header Block Addressing Header Block SOAP Body XML Payload Conceptual Sample SOAP based Envelope MISMO structure WS-Security WS-Addressing XML MISMO

16. Sample WS-Addressing SOAP Header with MISMO Payload Headers Body

17. Current WS* Overview For initial MISMO enveloping strategy concentrate on SOAP and message related standards first then evaluate other soap based standards as the need arises

18. How can SOAP and MISMO be Used Together • Headers are used for protocol/messaging specific items. (Headers are optional) • MISMO may be passed in the body of the SOAP message with little or no change to structure

19. What functionality do the MISMO headers provide today? • Trading Partner information via MISMO XML • Submitting Party • Preferred Response • Requesting Party • Receiving Party

20. SOAP Node (Party), Roles, and Targeted Headers • SOAP embraces the concepts of multiple Nodes communicating together. • SOAP defines 3 roles which can be put in the header(s) to target the SOAP headers to specific Nodes along the service chain. • (Insert roles here) • SOAP can be extended to support more roles as the need arises.

21. Client Server Integration Scenario 1

22. SOAP Client, SOAP Intermediary, and SOAP Ultimate Receiver Scenario 2

23. SOAP Client, Intermediary, ServerMISMO Use Case LOS Portal Product Company

24. Securing SOAP • SOAP is the Foundation • WS-Security is the Baseline

25. MISMO Security Requirements • Requirements • Multiple security tokens for authentication or authorization • Multiple encryption technologies • Payload integrity • Multiple trust domains • End-to-end message-level security

26. Security Issues w/ existing MISMO Envelope specification • Clear text password is a security risk • Clear text passwords transmitted through intermediaries exposes all parties to unauthorized access • No embedded confidentiality of payload • No embedded integrity of payload • Authentication multiple end point support

27. WS-Security (SOAP Message) • Design Goals • “… flexible set of mechanisms that can be used to construct a range of security protocols; in other words this specification intentionally does not describe explicit fixed security protocols.”

28. WS-Security Support • Authentication • Username/Password (Clear/HASH Security token) • PKI through X.509 Certificates (Security token) • Kerberos (Security token) • Message Signing / Integrity • All, part or external message (XML Signature) • Message Encryption • All, part or external message (XML Encryption)

29. WS-Sec – Authentication Compatible support for UserId/Passwd exchange Username to be authenticated Password to be used Problem: Password is still in clear text and therefore problematic for the intermediary situation.

30. WS-Sec – Authentication/Hash Password now sent as a SHA1 digest instead of clear text • Advantages: • No clear text • Anti-reply attack • Intermediate confidentiality

31. WS-Security Auth Summary • When done correctly, a digest will prevent replay attacks • Digest provides confidentiality • WS-Security also supports field level encryption of the username and password, but only secure when done correctly. (Encryption vulnerable to replay/offline dictionary attack.)

32. WS-Addressing • Design Goals • …provide a transport-neutral mechanisms to address Web services and messages. Provide a specification that enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.

33. WS-Addressing • Requirements • Ability to provide service endpoint reference information within SOAP headers • Ability to uniquely identify message that is sent to endpoint • Ability to define attributes for the return endpoint location.

34. Sample MISMO XML utilizing WS-Addressing URL this message is being sent to URL this message is being sent from URL the response should be sent back to

35. Sample WS-Addressing SOAP Header with MISMO Payload Maps to MISMO Preferred Response

36. WS-Reliable Messaging Defined • Design Goals • Provide a SOAP based mechanism to for two services that wish to communicate to do so reliably in the presence of software component, system, or network failures. The primary goal of this specification is to create a modular mechanism for reliable message delivery. It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination. [spec 2004 Introduction]

37. WS-Reliable Messaging Supports • Four messaging delivery assurances models • AtMostOnce-Message will be delivered at most once or an error will be raised • AtLeastOnce-Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once. • ExactlyOnce-Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances. • InOrder -Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions. Concentrate on these aspects of RM

38. WS-Reliable Messaging • Requirements • Support • Works well with other SOAP based standards that solve MISMO Issues. • WS-Security • WS-Addressing

39. WS-Reliable Messaging Benefits for MISMO • Advantages • eMortgage • Guaranteed delivery • Acknowledgement of message receipt and order of message receipt • Others

40. WS-Reliable Messaging Sample WS-Addressing Header WS-Reliable Messaging Header

42. New Challenges SOAP brings • “The XML looks harder to understand” • Expectations-It does not solve all problems! (Provides framework to address the issues) • Competing / changing specifications and standards from various industry groups.