The Diamond Framework
Why?
As we all try to make sense of identity technologies, we go through a process of fitting what we’re learning into our own mental map. It’s a lot of work. In the hope of possibly be of use to others I’m sharing my personal map. It consists of four actors and the six interconnections between them.
Four actors
Across a variety of identity technologies for identification, authentication, data sharing, authorization and so on there exist to varying extents four main kinds of actors. All of them are digital. The human user has been omitted in the interest of simplicity. If it were included it would be shown as interacting only with the user agent (U).
- U – A local user agent. It may just be a browser. Or it may include an OpenID, WS-*, password or SAML IdP, selector client. It may include a local personal data store. It works on behalf of the user.
- R – A relying Website or Web service or a local application. This relying agent performs some service and/or provides access to some resources. In the non-local cases it is usually an agent of some organizational or individual entity other than the user.
- P – An Internet service (or local application) providing a specific service (e.g. a calendar service), an identity provider, an attribute/claim provider or an authorization provider. In the non-local case it is usually an agent of organizational or individual entity other than the user. Examples include a Plaxo Portable Contacts service, an OpenID OP, WS-* Security Token Service, or a SAML IdP
- A – A cloud-based agent that works on behalf of the user. It may act as an authorization manager to which you delegate authorization services. It may provide a service discovery service. It may provide storage of self-asserted identity data (sometimes called a personal data store). It may provide linkage of partial identities (attribute sets) across data sources. It may provide schema mapping of identity attributes and social relationships necessary to achieve data portability. It may provide an auditing service. It may provide Cloud Selector functionality (tunneling WS-* functionality through OpenID AX extensions). Finally, it may provide other “sync” services such as information card synchronization services (to synchronized cards across our browsers and devices). Various subsets of these functions are sometimes referred to as a relationship manager. I sometimes refer to the entire bundle as a personal identity agent.
Each developer community has chosen to name these same four actors different things. For example, in Oauth the “R” is called a “consumer”. Or in SAML the “R” is called a “service provider.” Here are some examples:
Actor OpenID SAML WS-* Oauth VRM ProtectServe Higgins ID-WSF U Browser Browser or local app Browser + Selector Browser Browser + [Selector] Browser + [Selector] Browser + [Selector] Rich Web or local app R Service Provider Service Provider Relying Party Consumer Vendor Consumer Relying Party Web Services Consumer P OP IdP IdP STS Service Provider Third Party Service Provider IdP STS Web Services Provider A n/a n/a [future: CardSync] n/a 4th Party Authorization Manager Cloud Selector, Identity Data Service, CardSync ID-WSF Service Architecture/COT
Six interaction paths
As you can see there are a total six interaction paths between the four actors. Each path is named by the letters of its start and end. For example, path PA is the path between P and A. Similarly, PU, UA, etc.
So that’s the basics of the framework. With it we can more easily compare technologies and protocols like OpenID, Oauth, WS-*, ProtectServe, VRM, etc. I’ll begin to do so in future posts.
8 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Thanks!
[Reply]
Comment by Gerald Beuchelt — May 18, 2009 @ 3:39 pm
Paul, this diamond is wonderful. I love using just letters to move the focus from semantics to the underlying architectural requirement. This could be a very excellent tool for the community to get to the heart of common requirements/solutions.
One suggestion: in the A column for WS-*, I’d put the term “Cloud Selector” since it’s been applied to that role.
=Drummond
[Reply]
paul Reply:
May 28th, 2009 at 3:48 pm
Here’s why I didn’t include it. As I’ve done here, lately I’ve been using the term WS-* to refer to the technology whose scope is limited to OASIS IMI TC’s initial work item specifications (although not necessarily furture work from that TC).
By contrast “Information Card” technology (especially as implemented by Higgins) embraces multiple protocols including new profiles of OpenID protocol as used by a Cloud Selector. Thus if we added an I-Card column, that column could and should include a Cloud Selector in the “A” row.
[Reply]
Comment by Drummond Reed — May 18, 2009 @ 6:04 pm
Good effort Paul, but surely we need to think of more than 6 paths – there’s lot’s of cases of using 3 and even 4 of the points at a time, in different permutations.
[Reply]
paul Reply:
May 28th, 2009 at 3:37 pm
Oh, absolutely. Any given use case will likely involve multiple paths.
[Reply]
Comment by David Kearns — May 18, 2009 @ 6:19 pm
Paul– This is an interesting abstraction and set of observations! Unpacking what could be behind the “A” entity will no doubt be an interesting exercise — it could perform many different functions on behalf of the user.
Perhaps I can now use your formalism to better explain my thoughts wrt r-cards. The relationship being catered to most explicitly in ProtectServe is UR (mediated through A). For example, each R is bound by some contract in getting data that U has permissioned it to have (coming ultimately from some set of P’s). If I understand r-cards correctly, each one represents a UP relationship, not a UR relationship (the latter would involve, say, wielding a card over at some R, to which both the U and the P may have contributed data). I believe many R’s will need a set of data whose pieces are individually hosted by more than one P, which is a need not currently fully served by the r-card notion. In short, there are multiple relationships going on here.
The picture also interestingly highlights that there’s room for more user-driven contractual stuff. For example, ideally it should be possible for the user to specify a contract for each P to adhere to in sharing data on U’s instructions, and for the user to specify a contract for each A to adhere to in mediating U’s interactions.
Looking forward to more in-depth discussions with you — I’ve enjoyed our conversations in Munich and at IIW immensely!
[Reply]
paul Reply:
May 28th, 2009 at 4:05 pm
You are correct that r-cards in that they are not about the UR relationship.
There are two kinds of r-cards: those that are about the UA relationship and those that are about the UP relationship. I used to call the UA-related r-cards “self-issued” r-cards, but since the tokens are signed by A not by U, perhaps I should call them agent r-cards. The UP r-cards are called “3rd Party” r-cards.
You wrote “I believe many R’s will need a set of data whose pieces are individually hosted by more than one P, which is a need not currently fully served by the r-card notion.” My response is this. An agent r-card can be part of the solution. It can aggregate attributes from multiple Ps and make them available to R’s. In so doing it is acting as a information broker.
The reason I say “part of” the solution, is that a couple of challenges remain. First, without Idemix/uProve type zero knowledge proof technology the broker breaks the chain of trust from the attribute originating P to the R.
The other challenge is that (at least in the WS-SecurityPolicy and OpenID worlds) there’s no way for R to express the desired semantics. I’ll post about this separately, but there’s no way to have the R list the attributes (claims) that it requires/desires and for each individual attribute list N trusted issuers of that specific attribute.
[Reply]
Comment by Eve M. — May 23, 2009 @ 6:23 pm
Hi Paul– Okay, I understand agent r-cards and 3rd-party r-cards now. Very cool.
Note that in ProtectServe we haven’t in any way privileged the protocol interactions of a “service provider hosted at the relationship manager” — that is, the relationship manager application acting as your authorization agent can also choose to offer integrated P endpoint services, but this could be one of many Ps where you’ve chosen to store self-asserted stuff. This is one way in which your notion of A is more complex than ProtectServe’s attempt to define RMs, AMs, and SPs as distinct things (though the concept of an “agent” is obviously very useful!).
I don’t understand why an A that “aggregates attributes” from multiple Ps must necessarily break the chain of trust without a uProve type of technology. If you have the flexibility to interact with attribute authorities somewhat dynamically vs. having to pack everything into a long-lived token that must be used with many Rs, here are some ways it could be done, I think:
- Store-and-forward: Serve as an interim R (proxy R?) that consumes signed content/assertions from the original P (allowing the original P to remain blissfully unaware of which other Rs are accessing the content besides this A-and-interim-R, and allowing ultimate Rs to authenticate the data’s origin)
- Feed aggregation model: Store only a URI pointer to the original content residing at P (mediating the ability of ultimate Rs to access the URI by applying U’s policy), such that Rs can satisfy themselves that they’re talking to an authoritative party
- Full identity-enabled service model: Go whole-hog with an ID-WSF-style Discovery Service model and store a web service endpoint to the P (still mediating Rs’ access in the style mentioned just above)
Agreed on your other challenge… It’s getting to be a perma-problem by now in a lot of architectures (which makes me think: it’s Concordic!). I’m looking forward to your further thoughts.
[Reply]
Comment by Eve M. — May 29, 2009 @ 10:52 am