Building identity bridges with the Kantara Initiative

Do you “do identity” in any way, shape, or form? If so, you need to know about the Kantara Initiative, launched today at the RSA Conference identity workshop.

If you follow these things closely, you might have heard about a “NewOrg” getting started to bring lots of identity interoperability workstreams together, or an “IDtbd” group for identity harmonization with a name to be determined. Well, it’s determined now — and by the way, kantara, appropriately, means bridge.

In this video I outline my reasons for supporting Kantara:

If you support Kantara’s mission:

Foster identity community harmonization, interoperability, innovation, and broad adoption through the development of open identity specifications, operational frameworks, education programs, deployment and usage best practices for privacy-respecting, secure access to online services

…consider joining as a Member to help make it happen. If you’ve got hard-won knowledge about gaps in the identity picture, or clever ideas about solving problems, consider diving in to one or more of its groups as a Participant — it doesn’t cost a penny.

At the least, make sure to follow @KantaraNews on Twitter. This initiative will be buzzing with lots of activity very soon, and you won’t want to miss any of the goings-on.

The science of feeling peckish (part 1)

In the diet culture, it’s common to find people talking about “body weight set points”: Your body wants to stay at a particular weight, and fights your attempts to slim down by making you hungry until you top up your weight. I don’t have the heart to link to the huge number of sites claiming you can change your set point by doing things like controlling calories (sigh), but knock yourself out if you want to search for them.

The thing is, set points for body weight, blood sugar levels (a body “glucostat”), blood fats (a “lipostat”), and even body temperature have been tested in the scientific literature to try and explain how hunger works, and found lacking. What turns out to matter most for making you feel hungry vs. sated is the availability to the body of utilizable fuels, seen in toto.

On this subject, Gary Taubes makes this recommendation in GCBC:

Several variations on this hypothesis [about hunger and availability of utilizable fuels] were published from the mid-1970s onward by LeMagnen and others. The most comprehensive account was published in 1976 by Edward Stricker at the University of Pittsburgh, and Mark Friedman, then at the University of Massachusetts and now at the Monell Chemical Senses Center in Philadelphia. Their article, “The Physiological Psychology of Hunger: A Physiological Perspective,” should be required reading for anyone seriously interested in eating behavior and weight regulation. [GCBC, Ch. 24, p. 433]

Go ahead — click that link above. You can buy the article, if you like, for the low low price of US$11.95.

Or, don’t! This is where I demonstrate that carbgrrl has gone around the bend. I went and got the paper, studied it closely, and present here a layman’s summary of its arguments and conclusions. You’re welcome. :-)

(I’ll do this in two parts. Part 1 — call it Energy Metabolism 101 — is below the fold. I’ll provide Part 2, The Hunger, in a later post. As always, I will gladly accept all error corrections and pointers to research that disputes or usefully refines the information below.)

[...]

VRM and automation

Mark Wilcox surveys the VRM proposition and has a suggestion for handling one of its technical needs. Here are some thoughts in response to his. (I had some trouble getting my comment to “stick” on Mark’s site, hence the posting here instead.)

I would say that one of the requirements of VRM is providing an individual with a convenient way to update his volatile data at the many sites that (legitimately) need accurate data about him to provide valuable online service. Convenience means, for one thing, not forcing the individual to be personally present for each transfer, and this then suggests that automation would be a good thing. This need for automation, which is a small but vital part of the VRM picture, can also be seen as an instance of the larger problem in IdMland of getting data just in time, directly from an authoritative source, with the user’s permission but through a back channel.

I think Mark is probably onto something in terms of how a CRM system has to deal with indirection where it once merely had to store some information by value. Note that there are lots of ways to accomplish this, and some of them are routinely done today in IdM contexts.

For example, the Liberty identity web services framework (ID-WSF) involves web service providers (WSPs) that accept requests from authorized web service consumers for data. By default this is all SOAP-based (though there’s interesting work going on to RESTify it). It’s got a sophisticated notion of a Discovery Service for fielding and routing requests.

By contrast, the Mine! work and ProtectServe both take explicitly web-friendly and RESTful approaches, with data feeds being accessed through URLs rather than XML request/response messages being traded by web service endpoints.

OAuth can be seen as an automation option as well, in that it enables services to become consumers of the output of other services on a user’s say-so. (ProtectServe is an extension/application of OAuth.) And this isn’t even a complete list of technologies that address this goal. The architectural choices run the gamut from push to pull, and include even hybrids/abstractions that are somewhere in the middle.

It will be good to get Mark’s further thoughts (and research from within Oracle) on how CRM systems can begin enabling VRM goals. Of course, the $64,000 question is more about business model shifts than technology shifts…

Relationship, authorization, make up your mind

Having been properly chastised by Paul for creating some confusion around the “relationship manager” (RM)/”authorization manager” (AM) terminology, I want to make amends, explain, and ultimately jump into the very interesting social-authorization discussion that Paul and George have been conducting.

In a nutshell, an RM is an application, and an AM is a ProtectServe protocol entity. An RM at a minimum has to serve as an AM endpoint but could also provide SP and even Consumer endpoints.

We’ve formally conceived of an RM app because data-sharing relationship management is only valuable if we have some app saving and applying a user’s desired policies, auditing and archiving a bunch of information, and other tasks entirely out of the view of other “computer entities” in the picture. A computer protocol is important for interoperability but, obviously, isn’t sufficient for success; app functionality and user experience have to be given equal prominence with interop.

A “minimum RM” could be represented like this.

The gray “archive” box stands for the pieces of RM functionality that don’t have a protocol-compliance job. Our mockup screenshots show how such an RM could be used — managing the access to calendars that live at a “foreign” online calendaring SP.

Of course, all these foreign SPs could host any sort of data on the user’s behalf. One of those SPs could be, say, a web app that helped you package up your various sets of resources (living wherever) into convenient Atom feeds. Any resources referenced in feed entries, or even buried inside other types of resources (like imgs inside HTML pages), might reside at different SPs, such that the Consumer would have to interact with a bunch of SPs in attempting access (just as it would have do GETs against a bunch of different servers today).

A fancier RM could be represented like this.

This RM serves as a ProtectServe SP endpoint, providing on-board serving/packaging of some resources, along with being an AM. For example, let’s say you self-host your RM at your blog, and your RM plug-in has a feature for storing “self-asserted” info right there. It also offers Atom packaging for, say, typical items needed during e-commerce account registration: name, default shipping address with phone number, and credit card data.

The RM might optimize the implementation of AM/SP interactions in the case of its “local” SP because everything’s internal to one app, but all “foreign” SPs have to be treated according to the formal protocol, and any auditing and archiving should be done for all SPs, including the local one.

Here’s an all-singing, all-dancing RM.

Now the RM functions as a ProtectServe Consumer too. This is much more futuristic territory, but: if it’s useful for a person to track the data she shares, couldn’t it also be useful to track the data that others have shared with her, and the terms she had to meet to get that latter data? If the protocol could successfully handle payment demands and receipts and such, we’d now have a peer-to-peer data-commerce network.

This deployment scenario offers one way to handle the social-authorization use cases being discussed by Paul and George. Bob’s RM (in the role of a Consumer) could interact with Alice’s RM (in the role of an AM) to register to get future authorized access to Alice’s resources (hosted at whatever SPs). Alice’s RM could perhaps become an OAuth (or ProtectServe!) Consumer of some SP that supports the PoCo API, which could — especially if extended in the way George and Paul have been discussing — help Alice manage her universe of potential data recipients in a standardized way. At the very least, her RM might offer on-board functionality to organize sets of Consumers by hierarchy, tagging, or other means, which could control authorization policies en masse.

One final note: Nothing in the ProtectServe protocol prevents a user from deploying multiple RMs, something that could be an important tool for empowerment, data portability, privacy, and so on. Depending on the use cases you want to cater to, however, this might have protocol implications; today our design doesn’t allow SPs to parcel out authorization tasks to different AMs for different subsets of a user’s resources.

Vitameatavegamin

Here’s a puzzle. Let’s say you’re trying to get your nutrition “in balance”. You’re told that there are daily reference values of macronutrients (like protein, carbs, and fats) that you should try to consume. Along with that, you’re told you should try to hit certain targets for micronutrients (like vitamins and minerals) as well.

But you’re not told that the one affects the other.

In the last century, anthropologists have had the opportunity to study cultures, such as the Inuit, whose diets consist of nearly 100% meat (along with trying out this lifestyle themselves), and nutrition scientists have tested such a diet several times. Aside from the weight-control and blood-pressure benefits observed, the subjects had no vitamin deficiencies.

Why? As Gary Taubes notes in GCBC:

…[A]nimal foods contain all of the essential amino acids (the basic structural building blocks of proteins), and they do so in the ratios that maximize their utility to humans. They also contain twelve of the thirteen essential vitamins in large quantities. Meat is a particularly concentrated source of vitamins A, E, and the entire complex of B vitamins. Vitamins D and B₁₂ are found only in animal products (although we can usually get sufficient vitamin D from the effect of sunlight on our skin). [GCBC, Ch. 19, pp. 321-2; emphasis in original; footnote elided]

Well, what’s wrong with that? We can eat some meat to get vitamins, and also mix in some grains, veggies, and fruits for “balance”, right? Not so fast. It turns out that carbs compete with your body for vitamins.

Nutritionists would establish by the late 1930s that B vitamins are depleted from the body by the consumption of carbohydrates. “There is an increased need for these vitamins when more carbohydrate in the diet is consumed,” as Theodore Van Itallie of Columbia University testified to McGovern’s Select Committee in 1973. A similar argument can now be made for vitamin C….

[T]here is significant reason to believe that the key factor determining the level of vitamin C in our cells and tissues is not how much or little we happen to be consuming in our diet, but whether the starches and refined carbohydrates in our diet serve to flush vitamin C out of our system, while simultaneously inhibiting the use of what vitamin C we do have. [Ibid., pp. 325-6]

So what is the U.S. Food and Drug Administration trying to achieve when they give nutrition advice like this?

Beats me. But it sure seems like a funny way to execute on their mission.

ProtectServe draft protocol flows

In previous posts I’ve described the basic ProtectServe/Relationship Manager proposition and use cases. Here is a set of web protocol flows we’ve developed to support our goals. This design is definitely not fully baked, but we hope it’s suggestive and that it generates some useful feedback.

Keep in mind that the mockup screenshots shared earlier illustrate a lot more than just bare protocol interactions. In the flows below, dotted-line arrows reflect steps outside the protocol per se, and each one of those arrows hints at lots of activity that lives in the “application value-add” world rather than the “interoperable protocol” world.

The Players

The User (working through a User Agent) is involved in the protocol per se at two key points: personally introducing the Authorization Manager and Service Provider, and optionally exercising a “right of refusal” in agreeing to a contract to release data to a requesting Consumer. In addition, the User has several duties, like policy-setting, that take place out of band. In our mockups, the User is Alice Adams.

The Authorization Manager (AM) is the hub that keeps track of the User’s registered Service Providers and all of the Consumer services that attempt to retrieve User data. It also applies the User’s policies to this retrieval. In our mockups, the AM Alice has chosen is CopMonkey.

The Service Provider (SP) is a service where the User goes to create and maintain some content that she may want to share selectively. The SP gets introduced to the User’s desired AM and thereafter knows where to send authorization requests before releasing data to Consumers. In our mockups, the SP is an online calendaring service called Schedewl.

The Consumer is a service that tries to retrieve some of the User’s data (in the form of a web resource, which may itself reference many other resources that are possibly unprotected or served out of other SPs), on a one-time or ongoing (i.e. feed) basis. Before it can retrieve the data successfully, it needs to meet the contract terms that the User has chosen to demand for that resource. In our mockups, the Consumer is the 3rd National credit-card site, asing for Alice’s travel calendar.

The Steps

There are four steps, which we have numbered in zero-based fashion (natch). The links are to WebSequenceDiagram.com flows. This tool rocks!

• Step 0: User introduces SP (Schedewl) to AM (CopMonkey) – done once per SP/AM pair
• Step 1: AM (CopMonkey) provisions consumer key and access token to Consumer (3rd National) – done once per AM/Consumer pair
• Step 2: Consumer (3rd National) meets contract terms for access to resource (residing at Schedewl) – done if Consumer hasn’t yet met terms
• Step 3: Consumer (3rd National) is granted access to resource (at Schedewl) by AM (CopMonkey) – done every time

I’m putting the actual flow diagrams below the fold because they blow out my margins. Note that you may not be able to see all of the pretty swim-lane pictures inline, depending on what browser you use; in that case, click on the step links above. [UDATE: Or if you're reading this post in a feed, try going to the real web page.]

[...]