Net-Reliance was created in May 2000 with a goal to provide a trust service for B2B Internet transactions. The company did not survive the .com market drop, was unable to obtain sufficient funds and terminated operation in January 2001.
Here is a description of the company goals from the Concept and Design document:
NetReliance is a service-oriented solution that addresses the shortcomings in today's online business-to-business market, and is focused on delivering on the e-Promise. NetReliance will layer on top of the Internet and online B2B exchanges to deliver just-in-time information that allows businesses to make informed decisions before authorizing electronic transactions.
The uniqueness of NetReliance is that the trust decisions are based on a wealth of reliable information regarding the parties involved in a transaction. The NetReliance business model is based on the premise that trust is established through a history of relationships between relying parties, and is not based entirely on the validity of one's identity. NetReliance builds on this premise and has developed a service that can translate the "earned" trust into the electronic marketplace; delivering real-time information to applications so that informed authorization decisions can be made.
NetReliance assists organizations in obtaining appropriate information and using it to drive policies that control electronic commerce applications. NetReliance is not purely about authenticating individuals, nor is it just about providing warranties in the event of a misrepresentation or fraud. It is our understanding that once the misrepresentation has been committed and an organization has suffered a loss, the monetary reimbursement is generally insufficient to cover the possible long-term damages. NetReliance is about giving an organization the "ounce of prevention" it needs to mitigate the risks involved in Internet based electronic commerce. NetReliance accomplishes this by:
1. Authenticating parties involved in a transaction.
2. Validating the identity of parties through additional sources.
3. Authorizing parties involved in a transaction through a precise set of policies.
4. Publishing business information that can be used for just-in-time authorization decisions.
5. Providing transaction-monitoring services that can be used to build histories and drive transaction heuristics. Monitoring services can alert to possible infractions, and even deny the completion of a transaction.
6. Maintaining a signed audit trail of transactions for non-repudiation purposes and dispute resolution
To achieve these goals, the company intended to build an authorization and registration servers. Gens Software Ltd. was sub-contracted by Net-Reliance to build the Proof-Of-Concept system that consisted of both Authorization and registration servers.
The following chart can illustrate the concepts of the authorization server:

You can also see PPS presentation of the concept.
Our company built the following components of the authorization server:
1. Customer Web Server plug-in for Netscape iPlanet server and Weblogic Application Servers. (In the future we were committed to build the plug-ins to any customer web servers).
2. The plug-in redirects transaction to Java Servlet (PMPcustomer), which communicates via HTTPS protocol with the Authorization Server using proprietary Policy Messaging Protocol (PMP) XML protocol.
Prior to constructing PMP message, the servlet parses Trading Partner’s certificate and passes it to the Authorization server.
3. Weblogic was chosen as an Authorization server. We have written a Java Servlet (PMPauth) that communicates via HTTPS using PMP protocol with the PMPcustomer program and uses Blaze’s Rules Engine to decide whether transaction can be accepted or denied.
4. If transaction was authorized, PNPcustomer redirects it to the customer’s Application Server.
We have developed the following prototype PetrolNet website to illustrate Authorization Server capability. Actual demo is using Oracle database, LDAP and Blaze rules engine. If you are intersted, please give us a call and we will be happy to run the live demo for you.
The following chart can illustrate the concepts of the registration server:

You can also see an example of registration server in the following web pages .
Our company has built the web site described in above link. We were using LDAP directory to store data about customers and Blaze rules. To access data in LDAP we were using JNDI APis.
While using Blaze’s Innovator software we have discovered some problems with recursive rules and decided to build our own WEB interface to rule designer using XML and XSLT with Cocoon. This interface is a prototype only: we were unable to complete it due to the termination of Net-Reliance project.
The results of registration process, registration forms, should be legally binding documents. In the initial stage of the project it was decided to use XML forms to store the data.
We have evaluated a number of available XML Forms such as XFDL from PureEdge , XFA from JetForm and other that provides electronic signature, but since Net-Reliance’s requirements for the forms were not very sophisticated we were able within 2 weeks to create our own XML form language together with prototype XML Form Player (that display the following WebPage from this UserInfo.XML file) and XML Form Designer .
The UserForm.xml is an example of form description that can be “played” into UserForm.html page.