[MUD-Dev] [BUS] Account-management systems

[Christopher Allen]

ceo wrote:

> It all brings to mind Skotos's account system, and I suspect that
> Christoper Allen and co (and others on this list who have also
> developed similar systems?) have all this licked by now...from
> what I've seen e.g. the Skotos system handles a wide variety of
> games, under a wide variety of conditions - e.g. Skotos
> own-branded servers; Skotos-managed, but externally branded
> servers etc (IIRC - correct me if I'm wrong!) etc. In fact, the
> issue of "servers we manage, but which are re-branded by someone
> else" is also one that occurs almost immediately in the game I'm
> currently working on. This adds some more questions to the mix,
> like "How do identities mix across different-branded servers?".

> I'm currently most tempted by a 3-level identity system, where the
> middle-level is made up of non-intersecting sets of
> global-identities. I.e. A human player has a single account. That
> account can create a global identity in any one of the
> (separately-branded) planets (to stick with the islands metaphor
> from the beginning of this post). Each planet-wide identity can be
> used to control any local-identity on any of the islands of that
> planet...

> ...but worrying that it's either over-engineered (and wastes
> implementation and maintenance time), or else too constrictive
> (and will have to be replaced in the near future :( ).

> What are other people doing about this? I've categorized the
> possible approaches, but have I missed some out entirely?

We have done a lot in this direction at Skotos, and some good design
was done initially, but in fact a lot of it has been hacked in over
time as we learned things. I'm sure if we had to do it over again
we'd do it differently.

In fact, at this time we have four authentication systems:

  - Authentication into the userDB server via SSL pages (used at
  https://www.skotos.net/user/login.php)

  - Authentication via a short term hash stored in a cookie for
  games that can read cookies (our web-based games, prose games
  using Alice or Zellous clients -- our preferred most secure method
  as games never see passwords)

  - Authentication via confirming user name and hash of password
  between game server to userDB (non-web based games, or games that
  don't have clients that can r/w cookies or nonce, our less
  preferred method)

  - Authentication via a sync of passwords with a trusted server
  (which we hate, but we had to do under one circumstance)

One thing that we didn't do that I'd advise you to consider is to
have a persistent, but hidden, short unique root ID for each user
with just numbers and letters -- this allows the users to change
their login names, game names, high-score names, etc. It also
simplifies royalty and other forms of statistics and accounting.

For example:

  Skotos root-ID: 13F45AFD (reasonably short random number, not
  visible to user, but guarenteed to be unique)

  Skotos login ID: christophera (guarenteed to be unique among login
  names, associated with root-ID: 13F45AFD)

  Skotos verified email: christophera at skotos.net (associated with
  root-ID: 13F45AFD)

  Marrach Character 1: Daris (guarenteed to be unique only in
  Marrach, associated with root-ID: 13F45AFD)

  forums ID: Christopher Allen (guarenteed to be unique only in
  Forums, but associated with root-ID: 13F45AFD)

  forums ID: Marrach-Daris (guarenteed to be unique only in Forums,
  but assoicated with Marrach Character 1)

    etc.

Some of the problems that we've encountered would be addressed by
this. For instance, we had one early user register their login name
as "lady_luminous_of_the_shadows" which worked fine for a login name
and for our first game Castle Marrach, but as we added new games
caused no end of problems with each and every new game. Sometimes it
is account name length, sometimes it is the underscore characters,
sometimes it is used as the default name in a chat room (whisper to
lady_luminious_of_the_shadows "Wow, your name is hard to type."),
sometimes too long in a high score board, etc. But we can never
"rename" her account to something reasonable as that is the key that
is used by every game and the statistics and royalty system as her
'unique' id for the last three years. If instead we had a non-user
visible shorter unique name with a constrained character set, it
would allow each service that needed it to use different names for
her.

Related to this general problem of sharing ID information among
multiple entities, I've become involved with a group called ID
Commons (www.idcommons.net) which is trying to come up with
'federated' ID systems, ala the Liberty Alliance, but with more
privacy and user control. Don't know what will come of that effort,
or if Skotos will support it, but if you are starting a system from
scratch there are some good web pages there, in particular a links
page at http://www.glormf.org/links.html

I've enclosed in this email our notes on the "Skotos Associate Game
Integration" which explains a little bit about our preferred method
of integrating with external games. If you'd like more info, contact
Shannon Appelcline shannona at skotos.net. If there is more interest,
I'll try to wrestle out some more docs from our engineers.

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen <ChristopherA at skotos.net>       Skotos Tech Inc. ..
..                2342 Shattuck Ave Ste #512, Berkeley, CA 94704-1517 ..
.. <http://www.skotos.net>           o510/647-2760x202  f510/849-1717 ..


Associate Game Integration
==========================
Becoming a Skotos Tech Associate Game requires integration with the Skotos user
database at three points: usage reporting; account creation; and account
authentication. Each of these steps can be accomplished through interaction with
the Skotos user database via a simple TCP/IP-based protocol.


Usage Reporting
---------------

Skotos' royalty reporting system is robust; it has been successfully
tested for two and a half years over ten different games. It allows
users to play a number of different games, and calculates royalties
for each game by using a variety of criteria to assess how important
each individual game is to each individual player. By using
different criteria, the royalty reporting system accounts for
differences in gameplay between client-based games and web games of
all sorts.

Four fundamental factors are currently used as the criteria for
royalty calculation: how many hours a user plays a game each day;
how many days a user plays a game each month; how many consecutive
months a user has been playing a game; and how well a user says he
likes a game. These numbers are averaged, then on a per-user basis
assessed against the statistics for other games that the same user
played.

In order to calculate these stats we need regular usage information
to be reported each time a user is in your game. We suggest this
reporting be done from your server each time a user logs out or each
time he goes idle for an extended amount of time.

This reporting is accomplished through simple interaction with the
Skotos userdatabase via a TCP/IP-based protocol. For example, the
following report would show that user 'joeuser' played the character
'hercules' for 1234 seconds, starting at 87654321, unix time:

  cplayed 66 joeuser 87654321 1234 hercules

Though we prefer immediate reporting, we will accept aggregate
reporting over up to a 24-hour period.


Account Creation
-----------------

In order for royalty reporting to be meaningful, we begin the
integration with your game at the time of each player's account
creation. The following main steps are undertaken during this
process: (1) a user is verified as an existing Skoto user; (2) A
username is selected for the user on your service which is as near
as possible to his Skotos username, given differing name spaces at
the two sites; (3) the user's account (or possibly character) is
created on your site; (4) a specific flag is set in your user
database identifying the user as a Skotos associate player; (5) the
user's Skotos user name is recorded on your site for the
aforementioned usage reporting; and (6) a brief report is made to
the Skotos user database that the account was created. We suggest
not maintaining a separate password for the user, as discussed in
"Authentication".

Our preferred method for account creation is that it be done via a
PHP or CGI program that is hosted at our site and talks directly to
your account creation process via a simple TCP/IP-based
protocol. This allows us to do user verification internally. All you
need to do is provide a special TCP port or else a special
identifier which will annote the user as being a Skotos
associate. We typically pass a specially calculated cryptographic
hash so that you can verify the valid use of your port or
identifier.

Other possibilities can be integrated, if you prefer us to totally
hand off the account creation process to your site, but they tend to
make the process more complex for the user, which can result in lost
trial members, and thus we try and minimize it.


Account Authentication
----------------------

To maximize ease of use for players, and ensure that they don't have
to memorize a large set of passwords, we suggest that game-specific
passwords not be required for Skotos associate players. Instead we
suggest that the following procedure be followed upon player login:
(1) your client passes user name and password (or cryptographic
hash) to your server; (2) your server looks up user information and
realizes that player is a Skotos associate; (3) your server passes
user name and a cryptographic hash of the passwd to a Skotos server;
(4) the Skotos server returns information on whether the user is
still valid or not and whether the password is valid or not; and (5)
your server provides access to the client based on this information.

The actual authentication process typically involves one line of
text sent to the Skotos user database, and then the interpretation
of its simple result as success or error.


Conclusion
----------

Overall, the integration with the Skotos userdatabase for associate
games is fairly simple. Our biggest challenge remains making it easy
and intuitive for our users, but as we've gained experience in the
process, we've learned better how to mold the process to that goal.

More information on the exact protocols will be sent as we move
forward on an associate game integration process.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev