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)..

sunet.id.requirements
http://kingsmountain.com/doc/Morgan-sunet.id.requirements-1996-03-01.txt

sunet.id.design
http://kingsmountain.com/doc/Morgan-sunet.id.design-1996-03-01.txt

The modern present-day, user-facing SUNet ID description is here..

SUNet IDs
http://itservices.stanford.edu/service/accounts/sunetids

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 sunetid@stanford.edu 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
http://kingsmountain.com/doc/StanfordRegistryAndDirectoryCaseHistory-1999-05-11.pdf

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
http://identitymeme.org/archives/2012/07/13/rlbob-migrates-to-the-cloud/

A day or two earlier this week, RL “Bob” Morgan, a long time colleague and friend of many of us in the Higher-Ed, Identity, directory, University of Washington, Stanford, IETF, OASIS, Internet2 Middleware communities passed away due to complications from his long bout with cancer and treatments thereof.

Bob made positive contributions wherever he traveled and to whatever he participated in (notably his beloved family). I personally benefited greatly from his friendship and mentoring, and am going to miss him so very terribly.

Various of his colleagues/friends had been joking online with him about whether “this time”, his second stem cell transplant, was “an OS re-install” or whatever, and so he definitively cleared it up for all of us in his imitable fashion, with this blog post entitled “Metaphorically“ on “day zero” (21-Jun-2012)..

Just to clear this up, for all you computer people.
Last time was “re-install OS and restore from backup”.
This time is “install a different OS”.
Next time is “migrate to the cloud”.
Got it?

Unfortunately, “this time” and “next time” got conflated, and RLBob indeed has migrated to The Cloud. 🙁

Hey big guy, are you gonna help them deploy SCIM up there?

Tributes to RL “Bob” can be found (and posted) here:

https://spaces.internet2.edu/display/rlbob/Home