= Overview of requirements =

The library is targetted to offer a central organized authentification system. Through using [http://en.wikipedia.org/wiki/Digital_signature digital signatures] we can asure that a new user just need once contact to the central organization and then can use this key on any server without further contact of the client or the server to the masterserver. Phase 2 of the project will be adding a same concept for approving stats between server and client, so that compromissed servers can be found much easier and so offer a concept to secure the integrity of stats and give a "ranked server" concept for any public servers ''TODO: More detailed Phase 2''.

== The players of the game ==

 * Client - The client of the user that actually displays the data of the game via awesome cool 3D engines which always kicks ass ;).
   __The client can be a cheater with modified source__

 * Server - The server where the client of the game connects to gather with the other clients.
   __The server can be compromised with modified source__

 * Masterserver - The only clean guy in the play. It is a central server (or a distributed trusted server concept) where the player "registers" his nick so that he can asure that his nickname is bound to this key. Actually its not required that there has to be a nickname saved with the key. It depends on the game, but because the player somewhere must see in game who they talk to, its highly recommended for easy approve.

== The problem ==

The problem that has to be solved is farly easy in explaining, we want to secure the player as who he is. You could think of a concept like Steam, which assures that a specific Steam_ID is exactly this player. But the problem about Steam is that it 100% works with a central server for all exchange. Also the servers who support this are not open source, this all together makes it secure, but only as long as Steam runs, it fails if Steam is down. Implementing such a loosy solution is farly easy for open source games, even with source, noone can block against a fully client <=> masterserver <=> server <=> client communication. But open source games, dont have the resources to handle a 100% available masterserver mostly. Even an outage of an hour could block out several players from doing what they normally do: Playing with their identity. Some still can play if they dont care about their identity, but the gameplay is hardly broken if "it doesnt care what you do".

== The solution ==

As easy as the problem is explained as easy can be the solution. We use [http://en.wikipedia.org/wiki/Digital_signature digital signatures] to guarantee any data from any point. We can put the way of working in the following simplified workflow:

=== First Time ===

  * Client generate key
  * Client gives public key request to Masterserver
  * Masterserver puts approved player infos and his public key into a signed package that identifies him and gives it back to Client

=== Per Connection ===

  * Client sends signed package to the Server
  * Server checks if package is really signed by Masterserver and if so, checks if the public key of the connection matches the one in the package. This way the server approves this way the informations for himself.

More exactly: [LibResurrection/UsageExample Usage Example for discussion]

== Using libs ==

Of course, we use any lib that can help our way, which is multiplatform so that it can be integrated very easy into the game engines. So far we plan to use [http://directory.fsf.org/project/libgcrypt/ libgcrypt] for the encryption and signing concepts we need.