|
|
 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.
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.
|
|
April 28th, 2009 | 
Attribute-Based Messaging and SemWeb Overlap
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.:
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?