Historical Materials

This page is for diagrams and other historical content that may inform the creation of UMA auxiliary materials. All of these materials may not be safe to use in their current form because they may clash with our current decisions about terminology, architecture, or both, but it's hoped they can inform the discussion. If anyone is interested in modifying any of these diagrams to turn it to a more modern purpose, ask Eve to help locate source files (largely in Keynote and OmniGraffle at the moment).

The following series of talks, listed from earliest to latest, may be helpful adjuncts in understanding the evolution in thinking:

Keynote (slides, video) at NZ Identity on the "design of everyday identity" and how to make identity data-sharing more usable and pleasant
Talk (slides) at Catalyst on the "care and feeding of online relationships"
Talk (slides, video) at Gnomedex on VRM
Keynote (slides, video) at EIC on ProtectServe
Technical session (slides, video, swimlane diagrams) at IIW8 on ProtectServe
Technometria podcast (audio) from 28 Sep 2009 on UMA
Data With Borders podcast (audio) from 26 Oct 2009 on UMA

parties-historical.png: This diagram shows how the first "leap" in thinking is to imagine that a person can impose data-disclosing terms on a website, and the second is to realize that a person or an organization can be in the disclosing position or the consuming position. (Read-write service access by the "consumer" is yet another leap, not made here.)

verbs-highlevel-historical.png: This diagram shows an analysis of the relevant verbs (actions) when imagining a discloser who can actively participate in the rules of disclosure. This view still reflects read-only disclosure vs. more sophisticated read-write access. This diagram reflects the assumption that the data being disclosed may need to be sourced from anywhere, not just from a single aggregated "personal datastore". Thus, it takes on characteristics of "user-centric XACML" – the policy enforcement point is conceptually separated from the policy decision point (though the PDP is colocated with the policy administration point and policy information point).

verbs-arch-historical.png: This is an early architectural diagram that goes one step deeper into what the verb-actions really have to do. It predates the particular version of verbs-highlevel-historial.png shown above, and assumed a colocation of a single "resource hub" with the policy decision point (here called a "publication agent"). However, separating these two pieces wouldn't really change anything else in the diagram except that you might have many "hubs".

symmetry-historical.png: This diagram brings together all of the above, showing that there is no inherent reason why something operating as a discloser's "agent" can't also operate as the agent when that same person is a "consumer". It is precisely for the reason that a single application might operate multiple protocol endpoints that there was a need to come up with a word that distinguishes the "relationship manager" application (a name that could be improved) from the "authorization manager" endpoint. (See this blog entry for a more fully fleshed-out argument.)