Blank (Media) Slate

A common problem when deploying wide-scale networked solutions is how to power the elements of the net. As reported in a MIT Technology Review article, Perpetua Power Source Technologies based in Oregon developed a solution for effectively powering small devices off excess heat.

According to their product literature, the Perpetua Power Puck generates it’s power using thermoelectric generator (TEG) technologies. It can convert low temperature differences into regulated voltages of 1.8 V, 2.5 V, 3.0 V, and 3.3 V. According to the MIT TR article, each puck is small enough to be placed in tight locations and can generate electricity with a temperature difference as little as 10 degrees C.

I was recently talking to some people at ISOC working with the OECD on research into developing reliable sensor nets. This type of solution plays right into this project as it can vastly simplify many of the power requirements. Assuming a use case in which a wireless sensor can be co-located with a hot water pipe, it is now possible to generate the required power to run the transmitter from excess heat. There is also often more than enough of a temperature differential just a few inches below ground in desert climates, making this type of solution a viable source for long-haul monitoring.

There’s a great discussion taking place on the OAuth list around how to make it easier to deploy.  It was started with a post by Kent Brewster lamenting the problems he ran into.  His post is a fun read, I’ve only snipped the top-level bullets:

• My Timestamp was Stale
• The Parameters in my Signature Base String were Out of Alphabetical Order
• I Forgot a Question-Mark between my Request and my OAuth Payload
• I Didn’t URL-Encode my Signature
• I Didn’t URL-Encode All Illegal Characters
• I URL-Encoded the Ampersands Separating my Method, URL, and Request Parameters
• I Didn’t Append an Ampersand to my Consumer Secret to Make my Signature Key
• I Used the Same Nonce, Over and Over and Over Again
• I Generated a Random Nonce, but (you guessed it) Failed to URL-Encode It
• And, Finally: I URL-Encoded my Signature Key

That post sparked a note by Chris Messina asking others if their experience is similar.  What follows, then, is a useful thread on what might help make it easier for others.

The reason I find this interesting?  Because, IMO, focus on this type of work is what will help move the ball forward.  Whether it’s OAuth, OpenID, SAML, InfoCards, or whatever, these are solutions that interface with real people doing real code.  The easier the deployment, the fewer mistakes and more time to focus on security over sytax, etc.

…and happier coders.

At the ID Workshop leading into the RSA Conference, we announced the impending formation of the Kantara Initiative. To those following the Identity Community, this wasn’t really ground-breaking news as we’ve been working on this for the past year or so (under various monikers). What was worth mentioning in the workshop, however, was that we’d signed a number of founding member organizations (including the Information Card Foundation, Internet Society, DataPortability Project, XDI.org, Project Concordia) and put out a call for more to join before the launch in a few months.  Oh, and we settled on the name.

After much (much) debate, the founders settled on the name Kantara as it is a Swahili word for “bridge” and has Arabic roots meaning “harmony”. And yes, we know that some people believe it should be spelled “Qantara” (while others want to add a trailing “h” on the end, too). In the end, there was strong support for the name as it blends key points of the group’s mission to:

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.

Beyond the announcement itself, the bridge-building we hope to facilitate already struck a positive chord throughout the RSA Conference. Of the meetings I attended, here are a list of them where Kantara was mentioned (either by the presenters or in audience questions):

• Fostering Collaboration and Opportunities in Identity Management
• Federate Access Policy, Not Identity
• Building Authorization into the Enterprise Identity System
• Cloud Computing and Identity Challenges
• Identity Management for the Cloud: Challenges, Opportunities, and Best Practices
• Identity and Privacy Models

In each case, the comments were positive and hopeful. Like opening a new birthday present, the IdM professionals were excited to play with the new group. Our goal, of course, is to make sure the Kantara Initiative lives up to our collectively high expectations. Taking a page out of the Concordia playbook, the initiative will provide neutral ground for all participants. There is no cost for participation, and all contributors are welcome. The playing field is level, and we’re excited to see what projects take advantage of the unique opportunity to have a truly open dialog.

The Tweet Race: As you can tell from the photo to the right, Eve Maler (a.k.a. @xmlgrrl) was apparently happy that her Kantara announcement Tweet beat mine. I’m relatively convinced, however, that she cheated by typing her’s in advance (only needing to hit “send” from the stage), while I had to type mine on the spot. In fact, her announcement blog post also won. Hmmph.

Sitting in a talk by Peter Neumann about “Identity and Trust in Context” at IDTrust 2009 he mentioned the use of attribute encryption within Attribute-Based Messaging (ABM). As I was unfamiliar with ABM, I found the following description from the paper “Using Attribute-Based Access Control to Enable Attribute-Based Messaging” by Rakesh Bobba, Omid Fatemieh, Fariba Khan, Carl A. Gunter, and Himanshu Khurana.:

Attribute-Based Messaging (ABM) is the concept of allowing lists of messaging recipients to be formed dynamically by using an attribute-based recipient address. This approach brings the flexibility of attributes in enabling the sender to send targeted messages, which 1) enhances the relevance of messages to the recipient and 2) allows the sender to send confidential messages knowing that the messages would be delivered only to the intended recipients.

Basically, what this means is that a user wanting to send a message to unknown recipients would run a query against a system so it was only sent to people who match the selected attributes. For example, I could use an ABM solution to send a survey of IETF participation to colleagues who are members of at least three IETF discussion lists.

I immediately thought that this is the type of solution that fits squarely in the sweet spot of the Semantic Web. I could easily see that if the attributes are encoded using RDF, an ABM system would seem to be an excellent use case leveraging SPARQL. Looking around, though, I can’t find anyone working on this approach.

Does anyone have any examples of or suggestions for this idea in practice?

Buried in a post about OpenID user experience by Chris Messina is a concise bit of advice for users:

picking an identity provider should be like picking a bank or credit card provider: as a fourth-party service provider that advocates for your interest, since you’re their customer!

The “fourth-party” reference is to an article titled “Get ready for ‘fourth party’ services” by Doc Searls in the Linux Journal.

Personally, I’m not a fan of the introduction of this term for the new party around the table. I like to think that a “third party” working on the user’s behalf fits the bill just fine. Following an object-oriented mindset, the third party can adopt the properties relating to it’s responsibility in a transaction without being locked between two others (necessitating a fourth).

What I do like, however, is the concept Chris clarifies later:

Instead of agreeing to terms of service that disclaim all responsibility to you, the customer, I hope that competition in the identity space will lead providers to actually take responsibility for their services — charging good money for doing so. If your account gets hacked — no problem! — your identity provider can put back the pieces and make things right again! You could even take out online identity insurance in case your identity is ever stolen — so you can always get back to your life and recover your data without the hassle and interruption when it happens today.

To unpack this a bit, I see a compelling use case for identity providers emerging, possibly piggy-backing on the PCI Security work. So far, the first quote about picking an IdP is falling on deaf ears as users don’t really think about their choice. They use what they use and that’s about as far as it goes. What users need is a compelling reason to think in terms of choice, and the model Chris suggests might be it.

I spent some time helping to build an affinity card system with MBNA a couple years ago, and that process was telling. As it relates to this discussion, I can easily see that they would jump on the opportunity to capture a market like this. All that needs to happen is for someone to write up a clear business plan around the concept. In fact, I’ll bet there’s an MBA student out there somewhere looking for their thesis.

In a nutshell, here’s what I think this looks like:

1. Credit Card Company (C3) sets up a new product based on it’s current card-based account system.
2. C3 stands up a full service identity provider (possibly built using the Higgins Identity Framework)
3. For high value services, C3 executes federation agreements with key nodes.
4. C3 contracts with an insurer to cover losses due to ID theft / masquerading (rates most likely locked to the NIST levels of assurance as codified by the Liberty Alliance Identity Assurance Framework).
5. C3 then advertises the new product to it’s existing customers (ID validation fees waived as an incentive)
6. Users now have a reason to choose C3 as their IdP for all high value applications (and might as well use them for everything else, too).

C3 still has to convince it’s customers (and attract new ones) to see value in paying for a secure IdP. I don’t believe this is too far away from happening organically, so now’s the time for a C3 to start working on the product line.

Further, it’s distinctly possible that Id end points are going to force the issue by requiring verified identity assurance and security beyond what your run-of-the-mill OP can provide. Hence services like MyID.is (which has it’s own issues, of course, but that’s the direction). If a C3 gets in the game, I have a feeling they’ll be able to build a more effective federation of trust, even when used in an anonymous context.

For anyone interested in privacy, I highly recommend reading “De-anonymizing Social Networks” by Arvind Narayanan and Vitaly Shmatikov.

Here’s a snippet from the introduction:

We present a framework for analyzing privacy and anonymity in social networks and develop a new re-identification algorithm targeting anonymized social-network graphs. To demonstrate its effectiveness on real-world networks, we show that a third of the users who can be verified to have accounts on both Twitter, a popular microblogging service, and Flickr, an online photo-sharing site, can be re-identified in the anonymous Twitter graph with only a 12% error rate.

So, basically, what they’ve done is effectively identify matching Twitter and Flickr accounts. Abstracted, though, their algorithm points out that all they need to map the relationships is an undirected data graph (with indications a directed graph would improve the effectiveness). Graphs like this can be found everywhere, and is what drives the behavioral targeting industry.

With this algorithm running around now, I guess data brokers will have to work a bit harder to anonymize your data. Perhaps they’ll pinch some ideas from Alex Ntoulas at Microsoft and start injecting noise into your systems.

Most people working in the identity field are generally resigned to living an invisible existence. Unlike when I was working for the New England Patriots (where I couldn’t walk ten feet without bumping into coverage of our every breath), toiling away on standards and specifications often receives little to no recognition. That’s why it was great to see the Liberty Alliance work getting props from Peter Stern, the executive vice president and chief strategy officer for Time Warner Cable.

In an article in Multichannel News, Stern talked about how its “TV Everywhere” initiative is ensuring their Internet video services can scale. Deep inside their strategy for the widest possible deployment is their embracing of Liberty Alliance identity management specifications:

Stern said Time Warner Cable has “embraced” the Liberty Alliance standards for creating and establishing users IDs. “We think we can create a scalable solution, without needing a common database across the MSOs,” he said. “The plan is to do this bilaterally, using open standards.”

While it’s not immediately clear which specific standards they’re adopting (it could be a mix of ID-WSF, ID-FF with SAML2.0), it’s clear they’ve evaluated them against their goals as quoted from the article:

• “We’re looking to create a model that’s friendly to cable, works for consumers… so if you’re paying for it in your living room, you can also watch it online,” Schwartz said.
• Stern emphasized that the authentication process for TV Everywhere must be very easy for customers and programmers. The user ID and password capabilities for TV Everywhere must be integrated so users can log in once, and access multiple programmers’ services.
• The system must also “deliver authorizations quickly — consumers don’t want to have to wait for several seconds, let alone minutes, to watch the content so we need to be sure we can build scalable system… across millions of requests happening on a regular basis,” Stern said.

It’s not the popular press (meaning the average user won’t know, or care, about this), but it’s great to see the word spreading about LAP’s identity management tools. Of specific interest to me is that Time Warner Cable is obviously paying close attention to the need to deploy highly scalable and interoperable systems that service end users without locking them into a proprietary solution.

It’s been a while since I’ve really been in the flow of posting, and most folks know why. The slowdown really started when the company I founded was shut down. While I was looking for a new gig, it was hard to spend time blogging when I should be chasing opportunities. Then after landing at ISOC, I was buried under the work needed to get up to speed.

Part of my job as an Outreach Specialist focused on the Trust & Identity community space, however, means I need to dive back into the flow of blogging. While dusting off my blogging tools, though, I realized the version of WordPress I was running was a tad out of date. It was missing a few of the newer features so I performed an upgrade and migration.

A downside of the change, however, was a loss of the previous post comments. I hope those who commented don’t feel offended. Otherwise, I believe I’ve pulled over a majority (though not all) of the past posts to the new home.

Thanks for hanging in there.

If you actively follow the identity space, you’ll already have heard about this, so feel free to click away (I won’t be offended). On the other hand, if you’re only a casual observer or are curious about IdM, read on.

This morning the Liberty Alliance (LAP) announced that the Internet Society (ISOC) is joining the LAP Management Board. ISOC will be joining other management board members from AOL, BT, CA, Fidelity Investments, Intel, Novell, NTT, Oracle and Sun Microsystems.

And according to my boss at ISOC, Lucy Lynch, “ISOC is eager to participate in Liberty Alliance’s well-established collaborative processes to help ensure that the specifications upon which these new technologies are built will promote continued innovation and serve the interests of all Internet users around the world.” And specifically, to join LAP in “promoting and developing the technical foundations of online identity and trust that will be crucial in supporting interoperable, secure and privacy-preserving applications and services on the Internet.”

Over the past couple of years there has been a noticeable increase in momentum around cohesive Identity Management solutions. ISOC working together with LAP is another step toward helping bring the stakeholders together. Undoubtedly, however, there’s still no clear direction for everyone around the table, but bridging across groups will benefit everyone involved (and those who don’t even know they’re a part of the equation).

It’s exciting to see Paul, Jack, =Drummond et al. at Parity releasing a useful customer app under their Azigo brand. They’ve taken the serious foundational work of Higgins and built on top of it a helpful I-Card application.

Their new I-Card offering is called “RemindMe“, and it’s designed to interact with sites you visit that include available membership benefits. By downloading the RemindMe I-Card (assuming you already have the Azigo Card Selector and associated Firefox plugin), you’ll start seeing overlays on various sites (like during Google searches) notifying you of available member offers.

For example, if you’re a member of AAA, you might not realize that the hotels you’re researching for your next trip will give you a discount. Azigo’s RemindMe I-Card will pop a notification into the search result page. Beyond benefiting members, the organization gains visibility as the overlay will appear for anyone with RemindMe, encouraging people to join to access the offer.

Based on a recent post by Phil Windley, it looks like they’re using the Kynetx Network Service to power the overlays. It makes sense to leverage their APIs and focus on the card management experience.

It’ll be interesting to see whether the I-Card model will take off, though. It’s going to be tough convincing people to buy into the experience enough to download a card selector application and then install various I-Cards. If they can hitch their wagon to a useful application, they should be able to go along for the ride, but they’ll need a compelling value proposition to overcome the download.