Welcome to the New RealTown! Submit Feedback

Matt's Real Estate Technology Blog

Blog by Matt Cohen
Minneapolis, Minnesota

Matt Cohen is Clareity Consulting's Chief Technologist. Matt consults to MLSs, Associations, brokerages, and many real estate industry software companies and has spoken at conferences, workshops and leadership retreats around the country on a wide variety of MLS-related topics. Matt is a well-regarded real estate industry expert on industry trends, software design, product management, project management, and information security. Clareity Consulting was founded in 1996 to provide information technology consulting to the real estate industry and its related businesses.

Subscribe

Your E-mail Address:
Subscribe to:

Recent Comments

RE: Re-Missioning the MLS Organization
David - I agree that it is not likely that vendors...
RE: Re-Missioning the MLS Organization
Matt, Thanks for another great post about the f...
RE: Re-Missioning the MLS Organization
Great post Matt! I think the "cooperation&qu...
RE: The Best MLS System is...
It has been many years now since my association of...
RE: Green Fields in the MLS
Thanks for your emails asking me to highlight:...

Site Feed

RSS Feed

Matt's Real Estate Technology Blog

New software provides Java API for RETS server access

Jul. 9, 2008
Tagged with: mls, rets

Check this out! RETS IQ RETS Library is a Java API that allows simple access to RETS servers. The API is designed to allow developers to connect to RETS servers and execute searches, photo downloads, metadata requests and updates without having to deal with the nuts and bolts of the RETS protocol.

Mind the license.

 

RETS is not just an "MLS Thing"

May. 16, 2008
Tagged with: rets
During the NAR meetings I had the opportunity and privilege to help staff the RETS booth, and one booth visitor in particular piqued my interest. The visitor was a developer for one of the major broker back-office applications and expressed that he had integrated with a number of MLSs and was getting more comfortable with RETS, but he was still perhaps a bit fuzzy on RETS as one of those "MLS things".

It really brought home for me how MLS-centric a lot of the RETS effort has been, since RETS really should be providing a tremendous efficiency benefit to brokers and agents beyond the area of the MLS system, moving data efficiently and error-free from forms packages to broker systems and between all of the various broker and agent systems where real estate professionals are performing duplicate data entry.

When I expressed those thoughts, I think it was a real "Ah hah!" moment for that developer. I hope that he and other non-MLS developers continue to become more actively engaged in the RETS effort, and that RETS brings efficiencies to all of the systems in use by real estate professionals - not just MLS.

The message I think we need to get out there?
RETS is not just an "MLS Thing"
RETS is a "Broker Software Thing"
RETS is an "Agent Software Thing"


Future of MLS Features – 2008

May. 9, 2008

Introduction

The purpose of this paper is to generate discussion on possible MLS system future features by providing a big picture view of the changing relationship of real estate professionals with each other and with consumers, the changing relationship of local and regional MLSs with each other, and to illustrate, at least at a high level, how these changes may be either enabled or reflected technically in the MLS system of the future.

This paper is not focused on detailed description of what features are popular already today, for example:

  • Mapping bird's eye or street-level views
  • Big pictures in slideshows and flyers
  • Total MLS staff control over fields, reports and business rules
  • Easy setup/management of RETS data feeds
  • Single Sign-On (SSO)
  • Public records data intermingled with MLS data in reports and improved statistics

This paper also does not focus on the usual incremental changes to current MLS features, but rather explores the future of MLS systems and their role further ahead.

Clareity always advises our clients during their MLS system selection process focus on the core features ('the steak') and not be overly sold on other features ('the sizzle'). Too often, a largely volunteer based Task Force can be swayed by a single 'sizzle' feature, and forget that most importantly the system must perform core functions such as listing input and search as efficiently and accurately as possible, and that the system must have high availability and fast performance. With some of the more popular MLS vendors currently having significant issues in these core areas, I want to make sure that this paper is not seen as a call to take your eyes off the system core. That said, the definition of core functionality has expanded somewhat in recent years and will continue to expand and change – and we can't ignore that either. 

By consulting for many MLS vendors over the last decade, Clareity has strongly contributed in the development of the product vision for today's modern MLS system.  Clareity was a strong proponent of features such as integrated contact management and CRM, functionality for assistants and teams, and coordinating all of the leading real estate software vendors on Single Sign-On (SSO) technology and information security improvements. Not every feature we've thought up or recommended has been adopted though. Some ideas, such as good uses for automated valuation models (AVMs), Clareity has advocated for many years, but it took Zillow and Zestimates® to serve the MLS and brokers a wake-up call.  AVM's are just now starting to be integrated properly, in just a few MLS systems, using high quality AVM tools from companies like First American and Cyberhomes.com.

What follows in this paper are some of the cool features from my MLS product development notebook. Hopefully some of these features will show up in your MLS system of the future.  If you like one or more of these features, ask your vendor for them (or build it yourself, home growers!).   

Mapping: Not Just About Showing Property Location

Mapping has currently been used in MLS systems to show the location of properties, and occasionally through data layers and other interactivity, to show information about the property and its surrounding areas. However, mapping has a lot more promise than it has been used for currently.

Mapping can be a great tool for communicating agent knowledge about neighborhoods and communities. In some systems there is currently a way to turn on specific categories of "points of interest" (POI), but does it really help a gourmet seeking a home in a high-end community to show them every McDonalds and Burger King in a two mile radius? Not at all – rather, if the agent shows the consumer that map, it demonstrates that the agent doesn't understand their client. It definitely doesn't show the client that the agent is the neighborhood expert and can help interpret the plethora of information available. So, one key feature for turning maps into a useful tool to build a bridge between agents and consumers is allowing the agent to customize the map, edit the content shown to the consumer, and add user generated mapping content.

Illustrated below, an agent is showing the listings desired by the consumer alongside some specific restaurant and shopping options. You can see that in the Bistro detail shown, customized text and additional information has been entered by the agent, showing the client that they know the neighborhood, and have been to this restaurant before.

For example, if the prospective buyer had a child that studied karate, the agent could have added the nearby dojo to the map, along with the commentary "I think Suzy will really like the karate instructor at this dojo." Or, if the buyers had children in elementary school, the agents could add rich, relevant and even personalized content about the local schools as well.

The key to successful user generated mapping content is for it to be very easy to add the content. It must be easy for agents to add new custom points of interest, pre-fill basic information from existing data sources, and create content libraries that they can leverage to create custom maps for consumers with a minimum of entry or re-entry.   Getting these workflows right is critical to feature adoption.

Another area of mapping that could be greatly enhanced is to use mapping layers to show demographics. In many surveys Clareity has performed, agents seem very skittish about this – especially when it comes to showing crime maps. Some agents have legitimate reasons for skittishness – fear of being accused of steering or other violation of fair housing laws are valid concerns – but it's up to real estate professionals to provide the consumer the information they want and need to make a buying decision. If consumers want it and the real estate practitioner won't provide it, they'll get it elsewhere and the value perception of the REALTOR® will continue to decrease. As former NAR president Billy Chee said to me back in 2002, "The consumer is the lion coming over the hill."

Mapping also has great power to display complex information in a way that's very easy for people to interpret. One of my favorite visualizations is the 'weather map' or 'heat map'. Consumers can readily obtain heat maps from Trulia, Zillow, CyberHomes, and others, but not from their agents. Why is this? While some MLS systems already have heat maps to show days on market or price per square foot, it's easy to imagine other heat maps with even more useful information.  The example below shows what areas are 'hot' or 'cold' for investors by showing appreciation over time. Such maps could also show vacancy and absorption or even percentage differences between initial asking price and final asking price or sale price, or even show shading representing the percentage of properties in foreclosure.

investment-weathermap.jpg

I've shown 'heat' two ways on the map above – with colored icons and with color shading. It's probably only necessary to use one method or the other. Icons will certainly be technically easier to implement than shading, though at a wider zoom level area shading may make more sense.

Bridging the Gap between Internet and Installed Software

Why make the consumer open up a web browser and go to a web site to see their latest prospect matches? Why even expect they would check their email? Why not 'push' the results right to their computer desktop and get the information right in front of them when they start up their PC?   This is both convenience to the consumer and value-add to the agent.

The illustration below shows two Widgets that I created back in 2005 – one designed for the consumer showing the results of a prospect search, the other for the real estate professional, showing listing activity in their market area, along with what emails, inquiries, and tasks would await them when they logged into the MLS.

konfabulator-realestate

Toolkits by companies such as Google and Yahoo!, as well as widget capabilities built into Windows and Mac OS, make widget creation fairly easy. Coldwell Banker added a very simple widget to their web site last year, but I'm imagining much more sophisticated widgets, especially for professionals. Recently, I've begun to see capabilities developed to allow even more bridging between the Internet and the desktop – where the widget can store some data locally and provide some functionality even if the user has gone offline. As this technology evolves, I expect that the opportunities opened up by its use will continue to grow.

Integration of Broker System Features

At some point I expect, or at least hope, that MLSs will have much deeper integration with broker back-office systems and/or build in more broker features. There would be significant broker data management and workflow advantages to building features into the MLS such as:

  • Lead Generation / Management tools
  • Marketing tools
  • Competitive analysis for Recruit/Retention
  • Content syndication tools (listing distribution to other web)
  • Productivity / profitability measurement tool

To dig a bit deeper in one of these areas, an agent productivity / profitability measurement tool may include such elements as:

  • Income and Expense Tracking
  • List/sell/total production graph and chart
  • Drilldown by month / week / day / date range
  • Drilldown by enterprise / office / team / agent / listings
  • Productivity modeler (Actual / What If)

The "what if" modeler may allow for adjustable components such as commission splits, selling office commissions, desk cost coverage %, closed to list ratio, average marketing time, transactions to list ratio, and more. The system would then be able to show total $, GCI, agent $, company $, market $, desk $, net $, and $ change (from previous and base scenarios).

These types of features have been in various different broker tools – but really depend on the MLS for the data to properly implement them. Again, either the key will be deeper integrations with existing products or building these types of tools right into the MLS.

Features to Better Support Agents

Most MLS features are focused on the agent, but there's still more that can be added to the MLS for them, including:

  • Listing presentation or other marketing pieces as robust as the CMA w/ MLS sales statistics and showing data integrated
  • Buyer's agent presentation
  • Easy mail merge marketing pieces w/ tax data
  • A chart/report showing housing value increase or decrease within specific search criteria - to detect price trends within a specific neighborhood - and the ability to set alerts if sale price conditions start to occur for a specific search.

As MLSs continue to regionalize and engage in data shares, creating a better system for agents to find each other and provide referrals will be increasingly important. I believe that more advanced roster search functionality will be important if an agent in one area needs to be able to find the agent in another area to best serve their client.  Being able to see who is the expert in the types of properties desired by the client and who is most experienced and 'best' at facilitating buying or selling those properties via statistical analysis is key. Potentially there would even be qualitative agent ratings, open to other real estate professionals or even the consumer. Like eBay ratings, there would be a way to address disputes. There are already a number of web sites providing mechanisms for agent ratings – why wouldn't "organized real estate" want this mechanism to be someplace where we could manage the rules around it and have it integrated with other agent information and statistics?  Consumers will have access to several agent rating services – this is inevitable – because everything is being ranked on the Internet.

Integration of Appraiser Data

Will appraisers ever be brought into the fold? Every few years this comes up and new appraiser platforms such as Zaio are developed – though usually they have not succeeded in the long term. Why separate appraisal systems from the MLS system - is there not synergy? Shouldn't data standards such as RETS be worked on together with appraisers? How will they be incented to participate in a common data platform, so that everyone benefits?

RETS Implementations

Continued improvements in the ease of setting up listing syndication and even accepting listing input from broker systems will be possible as RETS continues to evolve. I think these are core MLS functions, and will change the role of the MLS system as diagrammed below. A lot more detail on this subject is available in a separate paper, available from http://www.callclareity.com/MLSsyndication.cfm

MLS of Near Future

MLSs will also need to work to address the security of listing data either being syndicated or even exported directly from the MLS. Because of that latter element of the problem, use of secondary products will always leave a significant issue unattended – unless the solution is 'baked into' the MLS. None of the MLS systems on the market today have established effective controls for solving this issue, though Clareity Consulting attempted to get the ball rolling by sharing plans for such as a system with all the major MLS vendors back in 2004, in a document titled, "Protecting Against Illegitimate Use of Data by Legitimate Users: Processes of Data Licensing, Delivery, and Use Monitoring".

The core of the system, diagrammed below, is to include a process for data use licensing, request and delivery, and verification – all built right into the administrative user's view of the MLS. MLSs could get a handle on where the data should be via the licensing process, data and images would be individually watermarked (yes, I know that data watermarking is a tall order), and methods of efficient compliance management put in place.

data tracking

 

I've got to admit that I'm not sure the perceived cost/benefit model will ever make it likely that such a system would be built – but I'd like to see this issue addressed. Once weaknesses in MLS user authentication and protections against hackers are put in place, this area is the largest security challenge for any MLS.

Social Networking

Real estate is, by its nature, a social business - so another area where both standards and deeper integrations may come into play is in social networking. Various major social networking sites have explored development of a common programming interface (API) for social applications across multiple applications - for example the OpenSocial standard (http://code.google.com/apis/opensocial/).  If MLS functionality expands its capabilities toward social networking, it certainly would be interesting to see how the MLS could interact with other applications through such interfaces, opening up whole new possibilities of how real estate professionals interact with their colleagues and clients.

The Original NAR "Future of MLS PAG" Vision

Originally, the NAR "Future of MLS PAG" vision was to have a central back end data repository, allowing for front-end interface of choice, provided at the local brokerage, MLS or association, vendor, and franchise levels, along with a baseline front end available through the NAR. Diagrammed below, this wasn't a bad idea, though the MLS PAG has since evolved its vision toward something that has seemingly little to do with MLS.

MLS of the Future

I still think the original vision made a lot of sense, especially at the natural market region level, then being linked together into larger areas. Of course, most MLS systems are not currently architected to use separate back-end databases, but I expect this will change in the future.

Lastly, to facilitate the regional data share process, or even to make it possible for brokerages/agents to have their own custom data shares beyond a single region, MLSs will need to make it easier to automate creation of data mash-ups from different MLSs as much as possible. I imagine a data mapping expert system that facilitates inclusion of multiple data sources, automatically mapping data to a common set and "wizarding" corrections and additional mappings. Of course, the system would still need to reflect the data mapping into reports, statistics, and other parts of the system.

Conclusion

Clareity Consulting is constantly researching new ideas for MLSs.  Our expert consultants are regularly engaged in the product management and development process with leading MLS vendors and home grown systems. Through end-user surveys, interaction with MLS executives and staff (80+ of top 100 MLSs have been clients of Clareity), our annual Workshop and attendance at MLS system sales demos, Clareity is constantly taking the pulse of the industry, in terms of what features are desired in an MLS system. But Clareity goes beyond this research, and is always looking ahead.

One of my favorite product-development related quotes is from Henry Ford, great automotive pioneer, who said, "If I had asked people what they wanted they would have said faster horses." There's a lesson in that quote for MLSs that say, "We're member driven," and for MLS vendors too focused on the mantra, "We're customer driven." It's important to listen, but it's also important to innovate and lead.

Those who wish to keep the functionality of the MLS more limited may insist that the role of the MLS should be constrained to only those functions needed for the facilitation of cooperation and compensation between brokers. That is, of course, the core of the MLS, but it should also be recognized that the MLS is the core business platform for agents as well, and that the MLS may need to continue to expand to support their needs in a multitude of ways.

What has been described above may be of interest, perhaps may inspire, but it's up to you. We in this industry often passively ask ourselves and our peers, "What is the Future of MLS?"   I think we need to take a more active, thoughtful role. To reference a quote attributed to Allan Kay of Apple Computer, "The best way to predict the future is to invent it!" MLS vendors and regional MLS operators can create the future of MLS, both supporting and driving the way local and regional MLSs interact with each other and the rest of the industry, and enabling REALTORS® to interact with consumers in new ways, preserving and enhancing their value as well as the ongoing value of the MLS system itself.

 

About the Author

Matt Cohen is Clareity Consulting's Chief Technologist. With a dozen years experience in real estate technology, Matt has spoken at many conferences, workshops and leadership retreats internationally and is a well-regarded real estate industry expert on software design, product management, project management, data center reliability, scalability, and information and network security.

matt cohen

About Clareity

Clareity Consulting was founded in 1996 to provide information technology consulting to the real estate industry and its related businesses.  Clareity Consulting provides clients an independent and unique perspective. Clareity has successfully executed a vast array of projects, including:

  • Request for Proposals (RFP) for MLS, public records, broker systems, and Transaction Management Systems (TMS)
  • Regionalization and data share facilitation
  • Contract negotiation
  • Information security and business continuity audits
  • Executive Recruiting and Placement
  • Project planning and management
  • Strategic planning
  • Software and system design and review
  • Software scalability testing
  • Mergers, acquisitions and strategic alliances
  • Market research including surveys and focus groups
  • New product marketing and business plans
  • Product and integration specifications analysis

More information about Clareity Consulting is available at http://www.CallClareity.com

Single Sign-On Through RETS

Mar. 1, 2007
Tagged with: rets, single sign on, sso

Background

Real estate professionals are using more systems and applications than ever, and they don’t want to have to log into each one separately. The inconvenience and inefficiency of multiple logins are exacerbated when users have to go back and forth between one system and another. As a result, system providers such as MLSs, transaction management software, larger brokerages and other real estate application vendors have moved to provide login integration of commonly used systems as a convenience for the users. This is referred to as Single Sign-On (SSO).

In order to improve the security and efficiency of implementing SSO, it was critical that the industry’s major software vendors agree on a standard method for doing so. This is why in August of 2005 Clareity Consulting published a free white paper, “The Convenience and Security of Single Sign-On” and subsequently facilitated two meetings, in December 2005 and March 2006, where many of the major MLS and transaction management vendors met to discuss how to achieve SSO in the real estate industry. MLS vendor attendees included Rob Overman, CTO of Fidelity MLS, Dan Mills, CTO of Interealty (First American MLS), Chip McAvoy, CTO at First American Residential Group (MarketLinx), Mike Wurzer, CEO/CTO of FBS, Carlos Grass, CEO of Stratus Data Systems, Brian de Shepper, CEO of Tarasoft, John Hensley, CTO of Homeseekers, and Brett Weiner, CTO/EVP of Rapattoni MLS.  It was critical to achieve cross MLS vendor support and cooperation, because while MLS may not be the center of the universe, imagine the decreased value of SSO without MLS system integration.  In addition to the key MLS software leaders, Cendant, CREA (Canadian Real Estate Association), OSCRE (the international real estate standards group), and other software companies in the Transaction Management, CRM, neighborhood information and online mapping areas also attended and contributed to these meetings.  Paul Stusiak, technical co-chair of the RETS group, attended and represented the RETS working group.

This diverse and talented group of technical leaders in the real estate industry came to a consensus that:

·         Using an open standard such as SAML 2.0 will allow the vendors to cooperate– making it more efficient to implement SSO securely.

·         There was no agreement on, or even serious consideration to, using a proprietary product to accomplish SSO.

·         No single entity or group should try to monetize SSO or control it by making it proprietary because this will create conflict and control issues and be a non-starter for many organizations and likely to slow adoption of free, open standards based SSO.  (Microsoft Passport was discussed as an example of why a controlling or proprietary approach is likely to fail.  Today, even Microsoft is backing open identity management and SSO standards as Bill Gates mentioned during his keynote address at the RSA Conference in February 2007)

·         Clareity and the vendor group should work with the NATIONAL ASSOCIATION OF REALTORS® (NAR) to incorporate support for SAML into the existing standard for real estate software vendor cooperation – the Real Estate Transaction Standard (RETS).

SSO via RETS

In November of 2006, NAR provided a grant to Clareity Security to build an open source reference implementation for SAML. An initial implementation has been demonstrated to NAR staff, and Clareity Security will be providing a complete, documented SAML standards toolkit to the industry for free inclusion into real estate software products in May 2007. Though Clareity Security is creating this software, Clareity will not own it,  but rather it will be owned by the real estate technology community as part of the RETS standard.  Again, if anyone were to own or control a method of Single Sign-On interaction, most vendors will not agree to use it – and vendor cooperation is at the heart of the success of Single Sign-On in our industry.

Unfortunately, there are two or three organizations in our industry that are attempting to monetize or establish control over Single Sign-On via use of proprietary products and portal technologies.

Those offering proprietary solutions are troubling: they may actually claim to be using open standards, but that is not the same as providing an open platform using those same standards. This is equivalent to Microsoft’s use of the XML standard in their Word product – Word is still a proprietary document format that gets in the way of collaboration with those not using the Microsoft product. Again, providing a common, open, and royalty free, vendor-independent platform via RETS is what is going to allow vendors to cooperate and allow for Single Sign-On adoption.

Those trying to control Single Sign-On using a portal are even more troubling and the issues additional to those described above are myriad:

First, the portal concept assumes that the portal manager is going to maintain identity (and possibly role) for everyone using all of the systems behind it. Imagine a state or local association, or its vendor, managing identity not just for association members, but for all of the non-members including MLS affiliates, unlicensed assistants and virtual assistants, brokerage staff, and potentially even for people in entirely separate industries that service ours – such as title and mortgage. This is a nightmare and the reason that the “federation” of identity outside of the enterprise/corporate environment is extremely difficult and is not available today in similar industries such as insurance, financial services, mortgage banking, or health care.  In fact, several identity portal attempts in those industries have failed miserably. The real estate industry will not be any simpler and presents a huge challenge because it is about as entrepreneurial, independent, and highly fragmented as you can get.  

Second, changing human behavior to go to a different site, other than the web application where people normally go to start their daily work, is difficult and inefficient, if not impossible. Agents (along with brokerage staff, mortgage, title, appraisers, attorneys and others) need and want to start their day on the system of their choice – their starting point can not be dictated as it can be in a corporate environment.  For example, one simply can’t tell a broker that if they want their multi-million dollar Intranet or back-office system to have Single Sign-On functionality, their agents, managers, and staff would need to log in first through an identity portal they don’t control.  This is a non-starter and larger brokers and franchises react violently to this type of intrusion in their business.  Likewise, most MLS executives or CRM desktop application vendors rightfully believe their system should be the starting point for their customers to originate SSO.  Clareity believes the broker, MLS executive, and software vendor are all correct and that as an industry we need to make SSO work for all these stakeholders if we want them to adopt SSO.

Third, it has been suggested that portals could be supported by advertisements (or user fees) and provide profits or revenue sharing to the portal operators. This would be another deal breaker for brokers, because channel conflict with advertisers is inevitable. For example, can Lending Tree, Bank of America, and HomeGain advertise on the “Realtor” portal or can we exclude these kind of advertisers?  But if there are no ads, then where does the revenue come from to support the portal and deliver profits to the owner/operators? User fees?  SSO that costs money can be compared to a toll road.  How could anyone seek to build a toll road if there were many free roads that take users to the same place? 

 Fourth, a centralized portal is vulnerable to a Distributed Denial of Service security attack, or may become unavailable for other technical reasons. A large portal is a tempting target, even Microsoft could not keep their Passport centralized service up enough of the time to serve its function acceptably - and the last thing anyone would want is for all the systems to be inaccessible because one system – the portal - was unavailable. The expense to create portals that “will never go down” and the associated risks are unacceptable and needless. The SAML standard will leverage the less vulnerable “web of trust” which underlies the way SSO is achieved in our industry already today.

 Computer Associates (CA) published a White Paper in January 2007 that explains the business value of SSO.  This paper made it clear that trust cannot be mandated, but rather is established by companies that want to do business together or provide a convenience for their employees or customers.  Following is an excerpt from that paper explaining why SSO and federation of a user’s identity are most likely to succeed in non-centralized fashion:

 “Given the intense focus on personal privacy and control of digital identities, the existing identity infrastructures that can be found in today’s organizations and the high-value of customer information that is often housed within them, it is virtually impossible to expect organizations to collaborate on creating and maintaining a universal, shared point of identity information.  Requiring organizations to first merge and centrally manage their user’s digital identities as a prerequisite to federating their applications for use by those users, is a non-starter.  This is one of the basic requirements driving federation standards and why the term “federation” (implying collaboration between loosely coupled sovereign organizations) is used in the first place.”

 For a free PDF copy of the White Paper from Computer Associates, visit www.ca.com (http://www3.ca.com/solutions/Collateral.aspx?CID=66744&ID=271)

 Single Sign-On done properly, through RETS with SAML extensions, may enable the creation of portals, but does not require there to be a portal. There can and should be hundreds of SSO portals, or as we prefer to call them, “entry points” or “authentication points” nationwide – as many as appropriate to the types of users participating in the Single Sign-On initiative in any market.  MLS systems already serve as de facto portals (or entry points) and many MLSs already serve as the authentication point for Association systems, public records, TMS, CRM, and broker systems, and provide SSO today.  Now, it’s simply time for the industry to do it better by adopting and standardizing SSO via RETS.

Conclusion

Clareity Consulting initiated open discussion of Single Sign-On in 2005 because our industry was inefficiently implementing SSO in a variety of ways and not providing it as securely as it should.  The industry vendors needed coordination to make SSO simple, standardized, secure, efficient and scalable.  Today, many of the industry’s leading technology providers have already agreed to cooperate around Single Sign-On, freely, through use of free and open-standards SSO (SAML) incorporated into the industry’s standard, RETS. Clareity Security will be providing a complete, documented SAML standards toolkit to the industry for free inclusion into real estate software products in May 2007. Though Clareity Security is creating this software, this is not a product and Clareity will not own it, but rather it will be owned by the entire real estate technology community. With your support, SAML standards will become a valuable extension to the RETS standard. By using RETS, the use of proprietary, divisive, issue-laden and potentially expensive products can be avoided, and SSO can be achieved as securely and efficiently as possible. Finally, SSO via RETS will help drive the widespread adoption of RETS 2.0 and everyone in the industry will benefit from greater standards adoption. 
 

The technical details about SSO and RETS are described in the Appendix that follows:

Appendix – The Technical Details about SSO and RETS


SSO in its basic form just means that a service provider (such as a RETS server) will trust authentication credentials provided using the SAML standard by an identity provider (such as another MLS, a strong authentication server, or another RETS server). For RETS to leverage the SAML SSO standard, RETS 2.0 must support SAML tokens. Please note that when we use the term ‘token’ in this document, we’re not talking about some sort of physical security token, but something else entirely, a security ticket that is part of the SAML standard. Please note that SSO is a concept within a single application (such as a web browser) - It does not necessarily mean that a user can move from a web browser authenticated to the MLS system to a separate RETS client application without re-authenticating within the context of the RETS client.

 

With that groundwork laid, consider the scenario where the MLS system has two RETS servers. One allows queries only for property data; the other server handles all other classes of data (agent, history, photos). To pull meaningful data, the RETS client must be able to talk to both. So the RETS Client (RC) starts a transaction with server A sending a SAML authentication token containing its login credentials. At a given point in time, the RC needs to get a photo to go with a listing. So it sends a request to server A asking for a SAML SSO token and Server A replies with that token. The RC then sends this SSO token to server B during the login transaction. Server B validates the SSO token by one of the available methods (message integrity / signing / server to server verification). Server B then lets the RC make its queries for photos.

 

So what in this is above and beyond the existing RETS standard? The first is when the RC asks for an SSO token from server A. Server A must be able to understand that request, it's not really a RETS request, it's a SAML request. It might be that we have to add something to the RETS 2.0 standard to spell this out. Additionally, server A must be able to generate those SSO tokens itself, or via a trusted third party. Server B must be able to recognize the SSO token and take the appropriate action to validate it, whether that is verifying the signature, or by checking with the issuing server.

 

One could also have the scenario where there is an independent identity provider (such as an MLS) could generate the SSO tokens once a successful authentication happens. So an MLS could have a RETS 2.0 interface for authentication only. The real RETS servers would just have to be able to accept and validate the SSO tokens.

 

In summary, to achieve SSO via RETS, the RETS servers will have to be able to understand SAML tokens, and the OASIS standards to a certain extent. Your support of the inclusion of SSO standards extensions to RETS, along with the SAML toolkit that NAR's CRT will be freely distributing soon, will help achieve that goal.