How does Fenrir simplify your work?

What does Fenrir bring to you as a developer?

Fenrir alone includes the functionality of:

• TCP
• UDP
• TLS
• DTLS
• OAuth
• Multicast

Plus a lot of other things that you would normally have to manage by yourself.
There is no retrocompatibility, but the tradeoff in features alone is more than worth it.

Data transport

Here Fenrir shines like no other.
TCP-like? we have it. UDP-like? sure. But that’s boring.
How about you get all possible combinations of transports:

Fenrir will also be able to do all the above on top of multicast, too.
Everything always encrypted and authenticated of course.

The combination of “Stream+Unreliable+Unordered” will probably make little sense, but it’s easy to implement, so we don’t see a reason to limit your choice.

Multihoming is included in every connection, for both user and service, so you can have roaming endpoints and use multiple connections at the same time without problems.

NAT traversal via TURN-like protocol is planned and will always be included: since all clients and services are required to contact the authentication server, we have an obvious central point where to implement it.
Your clients will be able to use this features completely transparently.

But is Fenrir Webscale?

Let’s be honest, the web has scalability issues.
That Fenrir resolves, of course.

In legacy applications whenever you connect to a fqdn (like:example.com) your browser or application will resolve the address and get a single IP address.
Then you have to do the same for authentication.
To scale this you need proxies, load balancers and redirects, all manually managed.

With Fenrir the dnssec will give you a list of all ips of the multiple authentication servers that are authorized for that domain.

We have both traffic weighting and failover at this very first level, before the initial connection.

After that, the authentication server will point you directly to the server you want.
Geolocation, traffic weighting and more can be done if the services give the necessary statistics to the authentication server.

We can make you scale beyond current architectures by avoiding proxies!

Authentication

The current standard for authentication is (unfortunately) OAuth.
As a developer you will have to manage different libraries for different providers, handle security tokens securely, implement and track authentication redirects and follow best practices that are not enforced everywhere.
2FA? Add it manually and differently on every service.
Password resets, token liveness, token revocation...

In Fenrir, you just don’t have to.
You get a connection: that connection is either anonymous or comes with the user’s details. DONE.

2FA? Both the service and the client can enforce it. Nothing to do on the application.

Aside from the mess that OAuth pretends hard not to be, and the extra development effort to implement it, your OAuth provider is always able to impersonate its clients, too.
This just can not happen in Fenrir.

A new standard, WebAuthN, is slowly getting more usage. Key-based, but without device or login tracking, synchronizations or warnings if your device is hacked and your keys stolen.
Bacause yes, we can instantly warn you in that case too.

Fenrir’s Theory was finished in 2016. It’s still easily a decade ahead of anything else.