Customer-facing websites and services expose a massive threat surface by leaving themselves wide open to the Internet. The accepted thinking is that a public application, website, or service by definition has to be open to any and all connection requests that can then be authenticated or otherwise validated.
This thinking is WRONG.
It leaves you vulnerable to attack from anyone that has Internet access and the ability to scan it to detect the APIs and applications you are making available. Coupled with the existing security paradigm of “connect, then verify”, you have an enormous number of users, with a large proportion of bad actors, now connecting to your environment.
REL-ID instantly "cloaks" all of your public-facing APIs, services, and applications. Only requests that pass through the stringent series of steps described below are even aware that your services are available for consumption. This has the immediate effect of taking your posture from one that lets every connection request come through for validation, to one that is significantly stronger and validates every request before your back-end ever sees it.
Instead of relying underlying protocols with known vulnerabilities, REL-ID establishes a bulletproof channel based on split symmetric keys that are unique for that user, app, and device to access that service. This renders the channel invulnerable to snooping and even sophisticated "Man-in-the-Middle" (MITM) attacks. This bulletproof channel persists even if you use Content Delivery Networks (CDNs) or Value Added Networks (VANs), and serves as the foundation for your clients to communicate and trasact with you safely and easily.
The heart of REL-ID's security model relies on the generation and distribution of unique keys that have a 1:1 relationship between the user/app/device and your service at Internet scale. This key, unkown to the user, represents a massive enhancement to the traditional multi-factor authentication model of Something You Know + Something You Have. The key represents a third and much stronger factor: Something You Have But Don't Know. Because the user doesn't know what their key is, it cannot be maliciously obtained using Credential Harvesting or any of the other common types of Credential Compromise.
REL-ID only accepts connection requests from devices that are Trusted and Trustworthy. During the initial registration process, REL-ID generates a unique device fingerprint for the customer's device and adds it to its database of Trusted devices. In addition, anytime a connection is being requested, REL-ID also validates that the device not only matches that fingerprint, but is also currently Trustworthy -- that it hasn't been rooted or jailbroken, and that it isn't running malware. If both those criteria are not met, which is virtually impossible for an attacker to simulate, then any connection request from that device will be instantly dropped.
REL-ID further narrows the attack aperture by only accepting connections from trusted apps. Unless the app fingerprint can be successfully validated to ensure that it is in fact your app on the user's device, and that the app hasn't been tampered with in any way, REL-ID will instantly drop the connection attempt.
The last crucial piece that slams the window shut on your attack surface, is strong (and seamless) user authentication. Using the unique and unphishable credential mentioned above in conjunction with the user's biometric authentication factor, REL-ID cryptographically verifies that it is in fact a known and trusted user that is trying to transact with you. This is the final and ultimate link that ensures that your threat surface is minimized to the ultimate degree possible.