RLBob: SUNet ID and the Registry and Directory Infrastructure
Primary among RL “Bob” Morgan‘s (aka “RLBob”) many contributions during his time at Stanford Networking Systems, was being a key visionary and instigator behind the Stanford University SUNet ID project, as well as the underlying Registry and Directory Infrastructure.
The main use cases RLBob latched onto in the early 1990s were having a centralized institution-wide authentication infrastructure, and a “flat” email address namespace. Both use cases drive requirements for having a centrally-maintained yet delegated-management notions of person naming.
At that time, all email addresses at Stanford were relative to some particular system or host. So, you had to remember whether some Stanford correspondent’s email address was @forsythe.stanford.edu, or @leland.stanford.edu, or @networking.stanford.edu, or @whatever.stanford.edu. Additionally, one’s online name, or names, were invariably driven by either/both of the unix-based academic computing environment (up to 8 alphanumeric characters) or/and the administrative mainframe-based environment (a often impenetrable six-alpha-character-with-dot concoction, such as “bl.foo”). Good luck with having online apps decently leverage your actual meatspace natural name(s) in this sort of environment.
Now, this of course was a burden for users. What if you changed departments? What if you were affiliated with more than one department? Well, you had more than one email address and it was pretty much up to you to figure out how to deal with that (this is of course just one aspect of the raft of issues we had at the time with the existing, essentially ad-hoc system).
RLBob was always very conscious of usability for the common non-computer-literate folk. He believed strongly in the value to the individual of having one’s online persona map reasonably to one’s offline meatspace persona. To him this meant figuring out technologies, policies, and procedures such that one’s natural name(s) could be represented and leveraged online as (ahem) naturally as possible. Also, that changes to one’s natural names (as necessitated by real world events/needs) could be accommodated reasonably.
So, to try to shorten a quite long, nuanced, multi-faceted story, here’s the early 1996 versions of the requirements and design documents RLBob crafted. We used these docs to inform the overall multi-phase SUNet ID et al project (which was well along by that time)..
The modern present-day, user-facing SUNet ID description is here..
In the first phase of the project (as I recall), we crafted SUNet IDs (featuring various name forms, e.g., short and long) and enabled email@example.com email delivery. However, this did not account for all the various institutional repositories of identity data, and did not provide for mapping between them.
So in the second phase of the project, RLBob championed the notion of a Registry, having this definition..
“A registry is a service that serves the needs of applications for coordinated maintenance of identity information about a class of business objects.”
..E.g., some classes are: People, services, groups. A registry is a transaction-oriented service. Client applications use one mostly to enter and update information, I.e. a registry is write- and update-oriented. Read-oriented access is typically handled by other components of the overall system, e.g. the Directory.
And thus the “Registry and Directory Infrastructure” notion took shape.
Below is a case-history presentation about this system that I crafted for a conference in early 1999. RLBob, in his Enterprise Architect role, made significant contributions to the overall thinking behind the entire system, as well as key detailed design aspects. Note also that this was a large project with many contributors crafting various aspects, including architecture, of the overall multi-faceted system (see especially the Acknowledgements on slides 23 & 24)..
Stanford Registry & Directory Infrastructure
I am honored to have participated in this project and and been part of such a talented team.
See also the RLBob tribute page, as well as my other recent post about him and his recent passing..
RLBob Migrates to The Cloud