(MCA)So I learned a little this week about sockets and it has given me pause to think about the realities of 'success' in regards to MASSIVE the adoption of the protocols that I tend to talk about on this blog.<br /><br />They say a little knowledge is a dangerous this... well here I go... head first:<br /><br />DNS resolution has been under attack recently (last 6 month) from a <a href="http://lwn.net/Articles/289138/">new set of poisoning attacks</a>. One of the main reasons the attacks work is because DNS uses UDP and not of TCP. The basic fix that has been implemented is Source Port Randomization but even that has been brute force attacked.... so people speculate as to what else could be done. One idea was make every request twice and the answers MUST match (this is known as debouncing). Another option proposed is, just use TCP instead of UDP.<br /><br />So here's what I find interesting... The debounce option was rejected because it would double the amount of traffic on the DNS system; we would go from 2 packets on the wire to 4. It has been determined that the current DNS infrastructure is running at over 50% capacity so instantly doubling the load is simply not an option. SO... why not use TCP? Well, if you use TCP you have the 3 way handshake, then the query, then the response and then the fin and the fin ack.... 7 packets on the wire (and larger packets at that). So I find all of this fascinating in a purely academic way, this stuff is all new to me. (now I have a basis on which to go understand DNS Sec, that'll be next week's reading)<br /><br />Then I wander... is anyone doing the math? IF OpenID became ubiquitous, or InfoCards did, what would that look like at a packets on the wire level? Is there so much spare bandwidth and processing power now available that we don't have to worry about this?</content>
by =andy.dale at October 16, 2008 04:03 PM
There's a great thread going on about reputation on one of the lists I read. I tried to respond to the thread, which is something I NEVER do, but apparently it has been too long since I was active so it wouldn't let me.... So I'm weighing in here for any one to check if they like.<br /><br />Another definition of reputation:<br /><br />Reputation is the result of running an evaluation algorithm over a set of input data. <br /><br />Some sample input data:<br /><br />a) Number of sale transactions and number of complaints<br />b) Number of IM connection requests and number of IM spam reports<br />c) Ebay reputation, Credit score and number of points on my drivers license.<br />d) How much 100 people, selected at random, like Diet Coke<br /><br />The evaluation algorithm can be very simple or very complex.... Ebay's is arguable very simple and Fair Issac's has a very complex algorithm.<br /><br />Arguably the reputation of a reputation could be measured based on the quality of its input data and the quality of the evaluation algorithm. <br /><br />Reputation system attacks tend to attack the data input stream, or depend on a delay between input and output. (I've written on this in the past.)<br /><br />As identity providers I think our first line of responsibility to reputation systems is the CONTROLED delivery of quality input data that is surrounded by enough metadata about collection/storage/retention and "whatever else" that anyone can run reputation evaluations against that data and reach meaningful conclusions. I can then feed that (anonymized?) data into the reputation service of my choice which will likely be dependent on the context of my current activity.<br /><br />If I want an agent at my smtp gateway to 'decide' if a piece of information should be delivered to my inbox I don't care what the sender says about themselves, I don't want to go query a bunch of reputation services to see if they know anything about this sender (which ones would I trust?). I want to have access to a set of data, signed by a reputable source, how long has the account existed, how many mail have been sent, how many complaints have there been, registration info(made available for bootstrapping) that I can put into my personalized reputation algorithm.</content>
by =andy.dale at October 15, 2008 10:03 PM
Paul, sorry I can't help with the <a href="http://connectid.blogspot.com/2008/09/say-hi-to-dewey.html">fines</a> but I was very interested to see that you are checking out "that" kind of book ;-)</content>
by =andy.dale at September 24, 2008 04:03 PM
Well now the rubber is going to meet the road....<br /><br />The people that I now call associates, and my boss, know a LOT more than I do about the management of massive repositories of distributed data. So now I get to test some of the ideas that I've talked about here over the years...<br /><br />I now work at <a href="http://www.oclc.org/us/en/default.htm">OCLC</a>, the Library People. My job is specifically working on Identity Management and Authentication. These things obviously only make sense in the context of controlling access to information resources.<br /><br />As I learn the differences between what I have guessed is important and what really is important for the OCLC use cases I'll let you know how good or bad my thinking of the last couple of years has been. <br /><br />I will still be engaged in the standards process and will bring the OCLC needs to the table as concrete examples of massive distributed identity use cases.... I think this is going to be fun!</content>
by =andy.dale at September 23, 2008 04:03 AM
I was just telling a colleague in the identity industry that so many meetings are being planned for the Fall IIW, Nov. 10-12 in Mountain View, CA, that I’m not sure that there will be any time for anything else. And it always what’s NOT planned that makes it so unforgettable. What can I say? Don’t miss [...]
by Drummond Reed at September 20, 2008 11:06 PM
If you are reading this you probably know me and my work.<br /><br />Together with my team of awesome co-workers we have tried to help move the art and science of distributed identity management and distributed data sharing forward. I think we have done some good work and would like to think that we have contributed positively to the general progress.<br /><br />Unfortunately, as many of you know, advancing technology doesn't actually pay the bills and we can't pay the bills any more :-(<br /><br />ooTao as we know is going to go away. I thought that we had a purchaser for the company but it looks like that is going to fall through. I am devastated to think that body of knowledge and the body of work that we have built up over the last 4 years is just going to evaporate but it looks like that might be what happens. The entire ooTao team is now out looking for employment, including me.<br /><br />I am still looking to see if anyone, with enough money to pay us, wants to try to keep the team together and keep the work going but I'm not feeling very hopeful.<br /><br />So if you want to employ one or more people passionate and knowledgeable about distributed identity and distributed data... just let me know... otherwise, I'm off on the next great adventure.<br /><br />I hope I'll end up in a position that I can continue to participate in the standards work. No matter what I will continue to post here periodically about what I'm doing that is in any way related.</content>
by =andy.dale at August 09, 2008 10:03 PM
YAF? (“Yet Another Foundation?”) Some in the identity community have had that reaction to the announcement of the Information Card Foundation (ICF) today at the start of the Burton Catalyst conference in San Diego. As one of two members of the ICF board who also serve on the OpenID Foundation (OIDF) board (Mike Jones is the [...]
by Drummond Reed at June 25, 2008 01:30 AM
The interference of the W3C in the XRI vote at OASIS is unprecedented and disturbing. The W3C has rebuffed all efforts by the XRI TC to engage in any form of dialog about the technical merits of XRI. Despite repeated attempts by the XRI community to show the use cases that XRI is solving the TAG make vague statements like 'you can do everything in URL'... This statement is clearly and patentley meaningless without specifics....<br /><br />It all well and good that SOME of the stuff that XRI does CAN be done in URI/URL but without specifying a STANDARD way of doing stuff the ability to do it is next to useless!!<br /><br />There are parts of XRI that you simply CAN NOT DO with URI.... Like resolve an abstract identifier (urn).<br /><br />There are hundreds of millions of users with services that use the xri specs (OpenID being the best known). The ONLY reason W3C cares about this is they think they CONTROL the internet and here is a spec that OBVIOUSLY solves wide reaching problems and it's not theirs.<br /><br />In my mind this is as subversive as the Net Neutrality issue... W3C is cynically trying to stifle innovation for pure 'not invented here' reasons. <br /><br />rant rave grr huff.... This pisses me off... PLEASE.... if you voted NO on the xri vote spend some time on the phone with me and talk with me about why you voted no and why I think you are wrong! Before undermining LOTS of hard work by LOTS of smart people at least understand the technology.</content>
by =andy.dale at May 30, 2008 10:03 PM
<a href="http://connectid.blogspot.com/2008/05/verified-by-ootao.html">Paul's response</a> to my latest post put me in mind of Claudio in Act 2 scene 1 of Much Ado About Nothing...<br /><br /><blockquote>Let every eye negotiate for itself<br />And trust no agent; for beauty is a witch<br />Against whose charms faith melteth in blood. </blockquote>Paul is correct that I must qualify my posts more carefully.<br /><br />There is as yet no agreement on all of the mechanisms of claim and assertion exchange. While the ability to differentiate a self asserted claim and an issuer asserted claim in a managed infoCard is useful in some cases it is not the ONLY answer to the problem. The fact that I have a widely deployed client provider that wants to consume claims in this way is a pure Business Detail that should not impact the purity of the technical discussion. <br /><br />As Paul points out a Better way to do this would be for us to deliver an 'Email' claim with enough metadata about how the claim was acquired and how it was or wasn't vetted that the RP could make its own decision as to the veracity of the claim. I probably should have implemented it this way even though the RP was asking for something else.<br /><br /><span style="font-style: italic;">Post Script</span><br /><br />That was meant to be wry bitting humor... not mean... does it sound too mean?</content>
by =andy.dale at May 21, 2008 04:03 PM
ooTao's Managed InfoCards now include a verified email claim and verified i-name claim.<br /><br />If you want to consume these claims you will need to ask for:<br /><blockquote><span style="font-size:85%;">http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/emailaddress<br />http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/iname</span></blockquote>I have blogged previously about how you might <a href="http://xditao.blogspot.com/2007/06/validating-i-name-claims.html">validate an iname claim</a><br /><br />We are publishing our own 'white list' of claims providers that we consider 'trustworthy' in order to 'trust' the verified email claim. More on that soon.<br /><br />If you want to start consuming our verified claims at your RP just let us know and we can do some testing together.</content>
by =andy.dale at May 21, 2008 04:03 AM
I like InfoCards... I like the idea that I will not have to remember the usernames and passwords. I am confident the MS will work out how to solve the 'portability issue'... BUT.... I just went through InfoCard hell!! I'm still shaking as the adrenaline that built up is trying to drain from my body... this can't be good for me. Let me tell you what happened.<br /><br />After a long week at IIW and Data Sharing Summit and OpenSocial Spec meeting, I am finally checking in on the blogosphere at 5:30 am on Saturday morning and I see this really cool thread on <a href="http://www.identityblog.com/?p=986">Kim's blog</a>. It's all about the qualities of Distributed Data Management that I have been talking about for years, but, it's Kim and <a href="http://www.vquill.com/">Dave</a> and <a href="http://blogs.oracle.com/clayton/newsItems/viewFullItem$32">Clayton Donley</a>, who is the Senior Director of Development for Oracle Identity Management.... I get so excited, I have to add a comment and tell them about ooTao's work in the space (although Kim is meant to know :-) ).<br /><br />And that's when the problems started...<br /><br />I can use digitalMe on my mac to log into our RPs and even to <a href="http://self-issued.info/">Mike's blog</a>, but it will not work on Kims blog. I spent a while restarting things; browsers, selectors, OSs, this is just habit as a long-time Windows user, nothing helped.<br /><br />So I upgraded and downgraded the versions of DigitalMe and tried to log in to no availe. For any who care the error I get is: 'unknown option privfile... blah blah'.<br /><br />Then I remembered, my old XP PC that is now the kids, should still have InfoCard selector installed so I put aside my mac and power up the old PC. First attempt to login at Kims blog tells me that 'InfoCard isn't installed' which seems strange, since I remember installing it. So I poke around and find that I DO have it installed but I don't have any cards defined... I add a card... I return to Kims blog... I click and YES, the selector invokes and I can see the card and I select it... and I am asked if I want to be redirected to an error page... which isn't exactly what I want but, what the hell, I've come this far.<br /><br />The error page informs me that the temporal offset of the requesting token is larger than the requisit 300S. Those aren't the exact words but believe me the error message did not say... 'The Client and Server Clocks don't match'... So I unpacked the message and realized that I needed to change the time on the PC so that it matched Kims server within 5 minutes.. I just had to hope that Kims clock was close to right. So I changed the time a few times and yes.... finally... I logged into Kims blog and left a comment.<br /><br />Unfortunately by the time I got there, my enthusiasm and excitement for the topic had been morphed in to frustrated anxiety so my comment is no-where near the 'tone' I originally intended. There should probably be some joke I can make here about 'Claims Transformations' as this STS certainly transformed my claims... BUT... I have now been trying to write, writing, writing about this damn post for 3 hours...<br /><br />I think it was worth it though if I can finally get these guys to understand what it is we have built.</content>
by =andy.dale at May 17, 2008 04:03 PM
Google is announcing Friend Connect tonight, a service advertised to “help website owners grow traffic by enabling any site on the web to easily provide social features for its visitors.” Friend Connect employs OpenID and oAuth which is a good start, but how it puts them together is lacking vision and, disturbingly, may raise significant privacy concerns.
Google is a member of the Data Portability Working Group which is working on open standards that tackle difficult issues such as privacy, control and data exposure. Unfortunately, while Google is thus aware of the issues, it has instead chosen to create yet another closed system where the social graph and all of the key connections people make is contained on Google’s servers. Friend Connect provides its services in an iframe that makes integration simple - and thus will speed deployment - but limits flexibility. While undeniably powerful given Google’s ability to datamine net connections, this is neither open nor user-centric.
In creating Friend Connect Google seems to by throwing its weight around in the social network sphere in much the same way Microsoft does regarding web interface standards. In the latter case, Microsoft - knowing it owns nearly 90% (and shrinking) of the browser market - has the power to disregard internationally accepted web standards with respect to how elements are displayed on the page, causing headaches for web developers building to the standards. Similarly, Google - knowing it owns a huge (and increasing) amount of link data - has the power to create seductive services that sites will use while disregarding community-developed best practices that support full user control over how, when and with whom data is shared.
I have to close with a disclaimer that all this is speculation upon what I’ve been able to discover so far with respect to Friend Connect which, as of this posting, has not yet been released and thus not reviewed. One can hope that they listen to the organizations of the Data Portability Working Group and the privacy concerns they are working to address.
by =fen at May 13, 2008 05:41 AM
I was reading <a href="http://epeus.blogspot.com/2008/05/portable-apps-not-data.html">Kevin Marks post</a> that looks at <a href="http://ideas.4brad.com/data-hosting-instead-data-portability">Brad Templeton's post</a> about the interplay between data portability and behavior portability. As I commented on Kevin's blog I agree with them 80% but think that Brad's proposal has one flaw.<br /><br />I disagree that it is practical or desirable to create a centralized data store. I think there are a couple of issues with that model. The first is the security implications of having everything in one place... that scares me. The second issue is, I think key, to the success of this model...<br /><br />The 'place that I have access to all my data and can therefore run my OpenSocial apps', lets for the sake of ease call it my 'iPage' can and should provide me all of the user interactions I need to manage my virtually aggregated data. Specialized 'Widget Providers' should give me widgets that give me data domain specific user interactions through which I can specify my favorite music, food likes and dislikes, rental car preferences, etc... BUT there is a world of data that is collected about me, and should be FOR me, buy people and systems that are much better qualified to know and assert those things than I am... Like medical information, qualifications, financial instruments, transactional histories of all kinds, what was done to my car at its last service, etc...<br /><br />This is why we have BUILT a system that has a data abstraction (xdi/higgins) behind the OpenSocial container rather than a database. The abstraction can provide (bi-directional data access) data to widgets that is stored locally or data that is stored remotely (or a mix of both), the widget neither knows nor cares. <br /><br />Using OPEN distributed identity standards (OpenID, oAuth, ID-WSF, InfoCards, FOAF, XFN) and OPEN data abstraction standards (XDI, Higgins,XML,RDF)... This can be done today... we've done it... This truly enables VRM in a broad and flexible way.</content>
by =andy.dale at May 06, 2008 04:03 PM
If you read this blog you get to watch me struggle to articulate some of the important subtleties of working with XRI, XRDS and XDI. Check out this <a href="ftp://sandbox.myxdi.net/papers/context-sensitive-identifier-mappings.pdf">article</a> written by ooTao CTO Steven.Churchill which show very clearly who the real brains of this operation is.</content>
by =andy.dale at April 21, 2008 04:03 PM
I was recently contacted by Bob Wyman in regard to an earlier post of mine... the first question was:<br /><blockquote>Some time ago, you wrote:<br /><blockquote><br />SEPs in XRDS must be considered self asserted<br />claims and as such should not be trusted on their<br />face. Service Providers should publish the<br />mechanisms by which SEP claims should be validated<br />to be about a specific subject (authenticated<br />identifier). (ooo… I feel another spec coming).<br /></blockquote><br /><br />Did that spec ever get written?<br /></blockquote>I had to respond that I never did write that spec but offered to consider his use-cases if Bob thought it would be useful. He sent me these use cases:<br /><br /><blockquote>Well, there are two kinds of things that I would like to be able to validate. The generic issue here is one of XRDS spam...<br />1. If I'm hosting a blog for someone and there is an XRDS file with a SEP that forwards to that blog, how do I assure a third party that the XRDS file belongs to the person for whom I am providing blog hosting?<br />2. If an XRDS file contains a link to some descriptive service (perhaps an XML file that describes the business and claims that the subject is a "Pizza Parlor"), how do I make the assertion that I know the subject to be, in fact, a Pizza Parlor?</blockquote>And I responded like this.... NOTE: if you manage to read the whole thing AND find the intentional mistake... you win a prize (at least you may be entered into a random drawing and have your name honorably mentioned by me to my family over diner one night).<br /><br />I SAID: -<br /><br />First I have to give the disclaimer.... these ideas are just our thinking on the subject, we do not represent the XRI TC or any other body, blah, blah, you get the idea...<br /><br /><a href="http://thread-safe.livejournal.com/">John Bradley</a> and I spent a good couple of hours talking this through and have come up with 2 answers for you... One is the practical, how you should probably do it today kind of answer and the other is the 'doing it right' answer, which would mean taking on a lot more of our abstract thinking and an XDI server. The 'simple' answer still has problems that I will highlight...<br /><br />Use Case 1) How to assert at an arbitrary http endpoint (web page, blog) a relationship with a specific XRDS.<br /><br />The 'simple' solution is that the http endpoint support YADIS discovery to 'get' the desired XRDS. The claim in this case would be validated by reseprocity. The XRDS returned by YADIS discovery MUST have EITHER an 'EquivID' or a 'CanonicalEquivID' that is the URI of the original endpoint.<br /><br />The one problem with this 'simple' approach is if you as the service provider or the end user actually have the ability to put the EquivID element into the users' XRDS. If, for example, this was Blogger blogs and Blogger OpenID 2.0 XRDSs then you would have the ability to edit the XRDS and the blog to create the reciprocal relationship. If the use case is broader than that you need to fall back on other mechanisms for the 'other end' of the relationship to be established. The options there would be:<br /><br />a) tell the user to 'go edit their XRDS' - and wish them luck :-)<br /><br />b) Use XRDSPP (XRDS Provisioning Protocol) - which is partially specified here: http://dev.inames.net/wiki/XRDSP_Spec and partially specified here: http://xpp.seedwiki.com/wiki/xpp/specs and not yet implemented or deployed anywhere that I know of. (although it is the 'next thing on our list' as MANY use cases depend on its existence)<br /><br />Use Case 2) How to assert a third party claim in an XRDS.<br />I'm not SURE that I have understood your use case 100% so I will be verbose about the problem that I am solving in case it isn't the question you asked...<br /><br />What is not clear to me from your question is what an RP would be looking for in the XRDS .... Would they be looking for "what does Service XYZ know about this entity" OR would they be looking for "what claims are available about this entity" OR would they be looking for "Is the entity represented by this XRDS a Pizza Parlor?"<br /><br /><br />If the question is: What does 'this service that I trust' know about the entity represented by this XRDS then the flow would be:<br /><br />1) RP looks for the CanonicalID associated with the Authentication Service SEP that they use to authenticate this entity (if they interact with the entity using OpenID then they need the CID of the XRD that contains the OpenID SEP, if they have a 'signed document' from the entity they would use the CID of the XRD that contains 'KeyService' SEP (the place you get the public key)) .<br /><br />2) The RP presumably knows the URI of 'this service that I trust' so they simply parse the CID, AND THE SERVICE TYPE, to the 'trusted service' and the trusted service returns 'claims' about the specified entity. SAML would be an obvious choice for expressing the claims but one could use any format one chooses.<br /><br />If the question is: What claims are available about the entity represented by this XRDS then flow flow would be:<br /><br />1) Perform Service Discovery for a 'Claims' service (not yet formalized but we could make one up on the fly if we needed to).<br /><br />2) Perform Service Discovery for the AuthN service (like above) to get a 'Key' CanonicalID.<br /><br />3) Ask the claims service (assuming that the claims service has a well known API) about the entity by passing in the CID and the AuthN Service Type.<br /><br />4) Get back a list of claims... The claims should always be verbose and specific... not: 'this guy is over 18' .... but "Claim service A says - the guy who on this date and time had the credentials for the OpenID Service for CID =!abcabc is over 18". As per my blog post yesterday about "XRDS Caching" this claim could be cached in the SEP to optimize this interaction. Depending on how the claim is retrieved, from cache or from the service itself will dictate the level of crypto verification you might want to apply to the claim.<br /><br />If the question is: Are you a Pizza Parlor then the flow would be...<br /><br />1) Get the XRDS for the CID (no service selection) and iterate over the XRD level Type elements to see if anyone has claimed that this is a Pizza Parlor. The Type element of the XRD is an XRI that might me in the 'self issued' form.... "xri://+pizza.parlor" or it may be in the 'asserted' form... xri://@google*(+pizza.parlor). In the assert form, if you decide to trust the asserter, you can validate the claim by the same means as answering the first question in this use-case where google just became your 'trusted service'.<br /><br />AND THAT"S THE END OF THE SIMPLE ANSWER :-)<br /><br />So in fact the 'how it SHOULD be done' (according to Andy Dale) answer is a lot simpler if you can overcome one pre-requisite..... First install your XDI server... the rest is easy, really... if you want to know I'll write up how that would work.<br /><br />Did you spot the mistake?</content>
by =andy.dale at April 17, 2008 04:03 AM
Talking with <a href="http://thread-safe.livejournal.com/">John Bradley</a> yesterday we got into some best practice ideas for XRDS usage. These probably need to me formalized somewhere other than my blog as I think they are important, but here's a first brain dump for you...<br /><br />1) More abstraction in our Service End Points (SEPs) - Right now we have a tendency to put a uri in the uri element of the SEP. The problem with this is that if the service provider changes their coordinates (or any other detail about their service) they have to change all of their customers SEPs. What we probably want to do is in any given individual's XRDS is provide a pointer to the Service Provider.... Jane uses @xyz for this service.... @xyz is then dereferenced for the access details. If @xyz makes any changes to their service they only have to change the SEP at the @xyz XRDS.<br /><br />In MOST cases this can be achieved by using an Service Level Ref. In MOST cases the Canonical ID of the XRD that contains the final SEP is actually irrelevant so having many SEPs Ref to the providers' SEP works fine. In cases where the CID does matter (like in an AuthN service) we have to do something else.. An XRI in the URI element would do the trick but that is going to have to be handled by the application as the resolution client will not ''automatically" dereference the xri. However, all the app will have to do is make another call to the resolver while remembering the CID from the first resolution call.<br /><br />2) XRDS Level Chaching - There are several SEPs that we are defining that, in their simplest uses, only expose a single piece of information. Examples of these are the 'Key Service' where in most cases you simply want the current public key associated with the identifier, or the STS service, where you are simply looking for an assertion of who is the issuer of mCards for this xri. In these cases it is burdensome, especially if we add the abstraction I proposed above, to have to resolve the SEP and then invoke another service to get a single piece of information. We have found that it is convenient in these cases to cache the pertinent piece of information directly in the XRDS. This way you can optimize most discovery and validation interactions. If you find that the cached value is "not what you would expect" (does not provide a public key that matches the signature provided) you can then invoke the described service to find out if the signature used an older, revoked, compromised key.<br /><br />What do you think?</content>
by =andy.dale at April 15, 2008 04:03 PM
Well, RSA is over and we finally get to slow down again.... The last few weeks have been crazed finishing everything that we wanted to get finished to show at RSA. It is VERY cool... the iPage framework is an embodiment and implementation of a lot of the ideas I have been sharing here for the last 3 years. It is real user centric information management. It allows anyone to create a collection of claims from various places and then project them back out into the world progressively and securely. Over the next couple of weeks I will publish more information about iPages and how they work and instructions how to get one of your own. <br /><br />Watch this space.</content>
by =andy.dale at April 11, 2008 10:03 AM
If you're in the SF Bay Area next week, and you happen to be at RSA... You HAVE to come check out the ooTao demo!!<br /><br />We will be in the OSIS interop room all day Tuesday and Wednesday showing off our stuff... It is well worth stopping by.... You will get to see, what I believe is, the most comprehensive Identity 2.5 mash-up done to-date... And it looks pretty good too.<br /><br />See you there!</content>
by =andy.dale at April 05, 2008 10:03 AM
Nowadays I find myself orienting my entire year around IIW (the Internet Identity Workshop). DO NOT miss it if you want to seriously intersect with the user-centric identity community. This year it will include a follow-on Data Sharing Summit on May 15, illustrating how the focus is slowly moving to the most important capability enabled [...]
by Drummond Reed at March 10, 2008 06:16 AM
Ryan Janssen <a href="http://drstarcat.com/">wrote</a> his take on our conversation. On the whole I like it. I'm frustrated that we seem to be unable to build web sites that communicate what we do .... Rather than accept this as our shortcoming I think I should blame Ryan :-)</content>
by =andy.dale at March 07, 2008 05:03 PM
Ryan Janssen and I spent a bunch of time on the phone the other night talking about the history of my involvement in the ID space. He's also been talking with others, like Drummond, and is putting together a history on his blog: <a href="http://drstarcat.com/">http://drstarcat.com/</a><br /><br />So far his stage setting and perspective seems very fair and even handed... we'll see if I still feel that way once he's written about me :-)... Check it out, it's a good read.</content>
by =andy.dale at March 04, 2008 11:03 PM
Ryan Janssen pinged me via my contact page last week to ask if I had time to share the story of how I came to be working on XRI, XDI, OpenID, i-cards, Higgins, and Identity Commons. He reached me this afternoon and we talked for almost two hours. Boy, did it bring back memories. I’m [...]
by Drummond Reed at March 03, 2008 03:46 AM
It's not enough that I added <a href="http://connectid.blogspot.com/">Paul Madsen's Blog </a>to my blog roll. I have to tell you that it has become my favorite blog to read. Paul keeps it short and to the point, he is funny and insightful. It also sounds like he enjoys his kids as much as I do mine.<br /><br />What is more, <a href="http://xml.coverpages.org/ni2005-02-11-b.html">ID-WSF </a>is proving to be a surprisingly good read too!</content>
by =andy.dale at February 19, 2008 05:03 PM
Working together <a href="http://www.microsoft.com">Microsoft</a>, <a href="http://linksafe.name/">LinkSafe</a> and <a href="http://wingaa.com">ooTao</a> have developed the first Info-Card enabled i-broker. You can register for an i-name at LinkSafe and subsequently log in to any OpenID 2.0 relying party without ever entering a password. All of the security can be Info-Card driven.<br /><br />We have made the Ruby RP Module deployed at LinkSafe available under BSD license along with a simple 'hello world' app that demonstrates driving the module.<br /><br />The source can be found at:<br /><br />http://svn.ootao.com/svn/ootao/dist/standalone-rp/ <br /><br />Log in as guest/guest<br /><br />You can view the running test app on our test server at:<br /><br />https://ibroker.ootao.com:802</content>
by =andy.dale at February 12, 2008 05:03 AM
<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_7pOmUCsHPpQ/R7CITA9Gn7I/AAAAAAAAAAc/V_QZZDa6A-8/s1600-h/xri_xrefs.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_7pOmUCsHPpQ/R7CITA9Gn7I/AAAAAAAAAAc/V_QZZDa6A-8/s320/xri_xrefs.jpg" alt="" id="BLOGGER_PHOTO_ID_5165778632849137586" border="0" /></a></content>
by =andy.dale at February 11, 2008 11:03 PM
I thought this email thread was interesting enough to share with you all... I was asked in an email...<br /><br /><blockquote> I do not understand however, the statement about URIs having some intrinsic limitation or to bound by hard trees. A URI is an identifier. No more, no less.<br /><br />In as much as meaning can be expressed by statements and a statement can be expressed in RDF, which uses the URIs as an identifier's for the subjects on both sides of the statement predicates, is in no way a limitation on what can be expressed about those subjects or the relationships between them.<br /><br />Perhaps you can elaborate on the perceived limitation of URIs?</blockquote><br />I'm publishing my response for two reasons...<br /><br />1) Maybe my answer will help others with the same question.<br />2) So that other XRI folks can help refine my answer<br /><br />So this was my answer:<br /><br /><blockquote>You actually answered your question in your questions... URI is insufficient to describe the relationships between resources. In order to understand the context of an identifier you need RDF, or XRI. I believe that XRI and RDF solve different parts of the same problem and used together provide some pretty cool capabilities.<br /><br />XRI is a fully backward compatible extension of URI so nothing is lost with this approach. It does bring some useful additions for anyone that wants to use them. Here's a couple of examples:<br /><br />1) XRI Resolution spec defines 2 mechanisms for 'Trusted Resolution'. While you can turn trusted resolution off and use dns infrastructure as-is (nothing lost) you can turn on either 'ssl resolution' or full 'signed authority chain resolution' to greatly increase the confidence that the results of a resolution are what they should be. Given how easy it is to undermine the DNS infrastructure this seems important to me as we move higher value transactions around a distributed web.<br /><br />2) XRI's cross reference syntax lets you build your RDF tuples right into your address.<br /><br />XRI://(uri://my_subject)*(uri://my_predicate)*(uri://my_object)<br /><br />Here's an example directly from the w3c tutorial.....<br /><br />http://www.example.org/index.html has a language whose value is English<br /><br />Which it then breaks down to...<br /><br /><http:> <http:>[http://www.example.org/index.html] [http://purl.org/dc/elements/1.1/language]"en"<br /><br />could be expressed as:<br /><br />xri://(http://www.example.org/index.html)*<br /> (http://purl.org/dc/elements/1.1/language)*<br /> en<br /><br />although starting to slip in some more xri 'stuff' it might look like:<br /><br /></http:></http:>xri://<http:><http:>(http://www.example.org/index)*(@ISO639-1)*(+en)<br /><br />In this last example the subject is still expressed as and dereferenced as a URL, it's natural form. The @ in the predicate means that ISO639-1 is resolvable in the @ namespace (dereferencing it would likely return the same as http://purl.org/dc/elements/1.1/language). The addition of the + to +en indicates that it is resolvable in the + space, which can be used to do things like find synonyms... (in the next draft of ISO639 en became eng... these might be made synonymous in the + space).<br /><br />We have found that building indexes of xris that use RDF syntax is a highly efficient way to navigate semantic space. (I'm not saying that it should be the only way, just that it is a viable alternative to XML serialization of RDF. We store our XRI index as a native b-tree which we find to be much more efficient to process than RDF XML.<br /><br />I'll stop there as you might already feel like your at the wrong end of a fire hose spending way more time on this question than you ever intended. If you want to spend more time learning about how and why I feel XRI (and I haven't even started on XDI yet) is important and useful, just let me know.</http:></http:></blockquote>how'd I do?</content>
by =andy.dale at February 11, 2008 11:03 PM
As you can imagine. I have profiles in a LOT of Social and Business networking sites. This is part of my job, I look see who does what and how. The real acid test of my evaluation is whether I ever go back to the site and _use_ the account. If I do it's a rare thing and a good sign.<br /><br />One of the networks that I have used along the way is <a href="http://biznik.com/">BizNik</a> whose tag line has long been... Business Networking that doesn't suck. And I did use BizNik periodically and even went to one of their local networking events. One of my favorite features was the "who has been to your profile" feature. Something shared by LinkedIn but at LinkedIn you only get 'hints' of who looked at your profile.<br /><br />So this morning I get my 'weekly stats' email from BizNik and it tells me that my profile was viewed 7 times in the last week and I think to myself... "oh, I wonder who looked at my profile" and click on the link provided.... and to my horror.... I can no longer see the list! Now I have to pay $10 a month to see who looked at MY profile.<br /><br />Now understand the need to monetize a business... Believe me I've been failing to do it for years and maybe it's because I do NOT believe that the way to go about monetizing a business is by charging the users for value that they create!.... People go to MY profile because of the information I put in it, it's MY information. Yes it's BizNiks container but can't they just stick ads on the page like everybody else. In my world BizNik would work with me to improve my profile, drive more people to my profile, share that ad revenue with me.... Not try to charge me.<br /><br />So I guess that I will not be going to BizNik any more, it's not really a decision I make, it's an organic thing.<br /><br />I guess I'll just have to drive people to my i-page...</content>
by =andy.dale at February 06, 2008 11:03 PM
Identity Commons is a fascinating story — to my knowledge there has never been an “upside-down umbrella” quite like it. Without going into that here (it needs its own post), I encourage anyone interested in IC to check out the quarterly report just published by Chief Evangelist Kaliya Hamlin (aka IdentityWoman). And that’s just the [...]
by Drummond Reed at February 06, 2008 05:47 PM
A quick word about <a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL</a>....<br /><br />John sent me this link to an <a href="http://www.infoworld.com/article/08/01/15/sparql-semantic-web_1.html">InfoWorld article</a> that discusses the changes that will happen once the promise of the Semantic Web becomes reality.<br /><br />First, congratulations to everyone who worked on SPARQL. I have gleaned some understanding over the last few years what it means to try to get agreement and drive ideas to a finished standards proposal... it's hard.<br /><br />The title of this post sounds like I'm going to say bad things about SPARQL, but I'm not. SPARQL and the functionality that it will provide is very important and very valuable. I do think that it's important to put it in the context of the XDI and Higgins work that we are engaged in.<br /><br />RDF and SPARQL will provide more available structured data that can be incorporated into the DataWeb. However SPARQL only addresses a small part of the problems that I talk about on this blog. For example, SPARQL doesn't have identification, authentication and authorization built into it's framework. I think this is a shame; we have seen time and again that building the capability for security into a protocol is far superior to 'bolting it on' or 'wrapping it around'. <br /><br />SPARQL specifically leaves Update and Insert semantics as 'out-of-scope'. There are lots of use cases for which this is fine. However, there are also lots of use cases where you really need to push values back out.<br /><br />So SPARQL is great... we will definitely build a standard plugin so that you can consume data available via SPARQL from XDI. We will probably even build a SPARQL query engine on top of our XDI engine so that any public data available from XDI can be accessed via SPARQL.</content>
by =andy.dale at January 30, 2008 11:03 PM
Up till now I have had exclusive access to Steven Churchill's brilliant and clear thinking as we have been working together closely for years. Now you all have limited access too... Steve is now blogging. Check out his first post on a <a href="http://stevenchurchillsblog.blogspot.com">Simple Identity Model</a>.</content>
by =andy.dale at January 21, 2008 05:03 AM
Did you see this?<br /><br /><blockquote><span style="color: rgb(51, 51, 255);">[Twitter] <a href="http://pulse.plaxo.com/pulse/events/show/26848684/">Joseph Smarr posted on Twitter</a></span><br />You can now log into Plaxo with an iName! I just attached =joseph.smarr. OpenIDDevCamp rocks, as do John Bradley and Michael Krelin! :)</blockquote><br /><br />It's great having John on the ooTao team... Thanks all of you!</content>
by =andy.dale at January 13, 2008 11:03 PM
Last month, VictorGrey and KermitSnelson announced barx, the first full implementation of the XRI 2.0 draft specification (working draft 11, for those of you keeping track). I finally downloaded and started playing with it tonight; it's very nice. Most OpenID implementations are using a proxy hack to support i-names, but as real XRI implementations start to come out, we'll start seeing many more interesting applications. (MS5)
I've started to port barx over to Perl and will hopefully have it completed by IIW next week. Yes, I'm coding again. I've been sitting on a slew of year-old ideas that need to get implemented, and I'm tired of being a preacher instead of a do-er (at least when it comes to code). It's against my instincts, and I don't have enough of an audience to leverage the LazyWeb. (MS6)
Besides, I was starting to miss it. Over the last few years, I've built a reputation as someone who knows a bit about collaboration, not just about tools, and that's been really gratifying. It's also helped me feel okay about reminding people that I still know a bit about tools as well. Plus, a lot of things have been stoking the fire recently. I was managing the HyperScope project last year and the GrantsFire project this year, both of which are conceptually and technically interesting. I never stopped reading code, and a lot of my friends are developers. What really kicked things into gear for me, though, was stepping in as an emergency developer for GrantsFire and watching LinusTorvalds's git talk. (MS7)
I started playing with a bunch of ideas at once, but I'm focusing on GrantsFire and the DigitalIdentity stuff now. Stay tuned, and if you want to hack with me over the next few weeks, either face-to-face or remotely, ping me. (MS8)
Just finished installing OpenID into the IIW MediaWiki - please see http://iiw.idcommons.net/
This was much harder than it should have been, as there are multiple OpenID plugins that claim to work with MediaWiki, and several of these claim to work with the latest OpenID-2.0.0-rc5 but finally the new version 0.7.0 of the standard MediaWiki OpenID extension fit the bill perfectly after dropping back to the v1.2.3 library. A million thanks to evanpro and, of course, JanRain.
All that tech stuff aside, I’m excited to have the opportunity to attend the first day of the Workshop (I have other commitments for the the other two days. which I am actually happy for as they are paying my fare across the country). In particular, I want to explore the use of barx to support alternate XRI/i-name roots so that federations of running proxy resolvers can be upgraded on the fly to include new local roots, simply by distributing a new plugin. The value of this to the many grass-roots organizations I work with at CivicActions can’t be over stated.
I look forward to seeing many of my colleagues next week as they gather to move the state of the art of user-centric digital identity forward another step.
by =fen at November 28, 2007 08:15 AM
I’ve never been part of a self-organizing community as large or as effective as the Internet Identity Workshop. If you care about the emerging user-centric identity layer for the Internet - or even if you only only care about the applications that are possible on top of that layer (which frankly are a whole lot [...]
by Drummond Reed at November 13, 2007 02:23 AM
Last week I mentioned the Social Web User’s Bill of Rights that was drafted for the Data Sharing Summit last Friday and Saturday. When it was first posted, it included the phrase, “ownership”, as in “user’s should own their personal data”. Mary Hodder, the entrepreneur behind Dabble.com, Paul Trevithick, and I were initially wary [...]
by Drummond Reed at September 12, 2007 08:49 PM
Courtesy of bLaugh. Spotted by Barnraiser. (MCB)
Day one at the Internet Identity Workshop, or IIW2007, began with Eugene Kim - Chairman-elect of Identity Commons (”2.0″, now with rounded corners), asking those attending their first IIW to stand up - over two-thirds of the 150 or so people in the room stood up. This is a great trend - the word is getting out!
I have been away from the technical side of the identity world for the last two years, but it seems not much has changed. Yes, there are now over 90 million people who have an OpenID, but few people are actually using the darn things. In the breakout session on three challenges in the identity space, I led a group of eight people as we came up with a list that was similar to what we were asking at the first IIW two years ago in Berkeley:
What was great was to see the progress in the field, that came from two unexpected directions:
Doc Searls ended the day noting that “all the identities in your wallet were given to you by someone else” and that our job is to co-create the user-centric digital identity needed to take back our power.
In the Open Space sessions tomorrow, I expect I’ll be leading or co-leading sessions on Why XRI? and Grassroots Reputation. I’m looking forward to it.
by =fen at May 15, 2007 06:07 AM
Thanks to next week's Creating Space, CollectiveLeadership has been on my mind a lot recently. It's also been a key element of the new IdentityCommons. One of the issues we've been grappling with is decision-making. To understand why this is a challenge, you have to understand the underlying structure and philosophy of the organization. (M5R)
Ultimately, IdentityCommons is a CommunityMark that represents a set of values concerning DigitalIdentity. It's a name bestowed on the community of folks who care about UserCentricIdentity. If you care about this stuff, then you are part of IdentityCommons. There is nothing to join, and you are free to use the name and logo as a way of demonstrating your support of these values. (M5S)
Why this is such a powerful and important construct is a topic for another day. What's interesting about this particular community is that there's also a corresponding legal structure, a nonprofit organization that is in the process of being incorporated. This organization consists of community "Stewards" -- people appointed by the community to represent the interests of particular sub-communities ("Working Groups") and who are responsible for managing the tangible assets of the commons. There are rules for becoming Working Groups and Stewards, but they are extremely lightweight. (M5T)
All of the Stewards comprise a Stewards Council. Each Steward has an equal vote on all matters. There is a Chair, but that position is mostly facilitative. There is also a Chief Catalyst, someone (not necessarily a Steward) who is responsible for handling the operational duties of the organization and catalyzing action in the community. (M5U)
It's a fascinating, but delicate structure. The Stewards Council has an important leadership responsibility, but that role is distributed equally among all of the Stewards. How do Stewards exercise leadership effectively given this structure? Decision-making via voting is clumsy in many contexts, and yet that's the only process that we've actually defined. (M5V)
We've had a number of interesting conversations on the topic, and the latest discussion recently surfaced a lurker, MartienVanSteenbergen, who cited an interesting reference on holacracy. Martien quotes the following excerpt (emphasis his): (M5W)
Another common question is about the "possible votes" in integrative decision making. At first it can sound like there are two possible votes on a proposed decision -- "consent" or "object" -- though that's missing a key point. Consent isn't about "votes" at all; the idea of a vote doesn't make sense in the context of consent. There are no votes, and people do not vote. (M5X)
People do say whether they know of a reason why the proposed decision is outside the limits of tolerance of any aspect of the system, and then decision making continues to integrate that new information. This isn't the same as most consensus-based processes -- either in theory or in practice -- although it does sound similar at first, especially before an actual meeting that seeks consent is witnessed. (M5Y)
This quote is keying on the difference between CollectiveLeadership and consensus leadership. They are not the same thing. With CollectiveLeadership, you are acknowledging the multi-faceted requirements of leadership, and you are empowering those best suited to meet those requirements to fulfill that leadership role. You are not voting on every decision, which would be a sure path to disaster. (M5Z)
One of the ways this manifests itself is by making decisions "without objection." This is a technique from RobertsRulesOfOrder that JoaquinMiller brought to our attention. Essentially, you empower people to act, unless someone in the group objects, at which point an alternative process kicks in. Everyone still has a voice in the decisions, but it is a proactive rather than a reactive style, and it encourages action rather than stagnation. (M60)
I believe that when you have great collaborative process, voting is a rubber stamping process, even when the topic is controversial. In other words, the actual decision-making process starts well before any vote happens. Healthy deliberation results in SharedUnderstanding, which in turn helps to surface clear courses of action that navigate through the obstacles of contradictory ideologies. When there is pressure for movement (another pattern of high-performance collaboration), then people will rally around those courses of action. (M61)
Phil Windley blogged about FreeYourId.com, a full service OpenId provider that gives you access to services off of a single .name URL. This starts to give a taste of what i-names can do, though it is - while clever - somewhat simplistic. When you give someone a YourId.name email address, they can then email you forever, as long as you keep the email it forwards to current.
When you give your i-name, you can remain in control over what services others can access from it. So if someone - or some company - starts sending you messages that you don’t wish to receive (solicitations, spam, etc.) you can easily shut them off and they no longer can contact you via that vector. Add a layer, and you could allow messages into your inbox that are considered to be of high quality from some group you trust. Or you can provide authentication that you are someone’s “friend” as they move between social networks, but when the go to a network you don’t like, the authentication no longer works.
Such mediated services are a major aspect of what make i-names (and XRI) particularly interesting, and the OpenId folk have (IMO) wisely include XRI service discovery in the OpenId 2.0 specification, which is nearing completion. Because of the complete control i-names give their owners, they provide a simple and natural foundation for creating the next killer app: community mediated reputation services.
by =fen at March 09, 2007 06:29 AM
Yesterday the long-simmering process of birthing the second-generation Identity Commons reached a key milestone: the Stewards Council reached consensus on moving forward with formal incorporation (in Florida to save money, since Steward Dan Perry has volunteered to serve as counsel), set a budget, and began the process of soliciting donations so Identity Commons can become [...]
by Drummond Reed at March 08, 2007 10:01 PM
Last week, I wrote glowingly of TerrellRussell's work on ContextualAuthorityTagging. You can hear the man himself talk more about it on AldoCastaneda's latest STODID podcast (The Story of Digital Identity). (LYY)
At first, I was a bit surprised that they didn't talk much about ClaimID, which is Terrell's other cool project related to DigitalIdentity. I then realized that Aldo had already interviewed FredStutzman about ClaimID last year. On this week's podcast, Terrell alluded to his various projects converging. Poking around ClaimID today, I could see where ContextualAuthorityTagging could possibly rear its head. Exciting stuff. (LYZ)
Many of us celebrated when it was announced that AOL has embraced OpenID. Does that bring us any closer to the goal of secure, privacy protected user-centric digital identity that empowers users, leveling the playing field between them and service providers to the great benefit of both? (OK, that’s my goal, but maybe some of you may share it.) I say: no. In fact, it can and may have just the opposite effect, providing false security and tarnishing the concept of single sign-on (SSO) throughout the, uh, blogosphere.
What’s missing is the key element that the Identity Commons was originally created to foster: community. If I may get metaphysical for a moment, trust starts by knowing yourself, and then extends tenuously outwards from the mind/heart/spirit to those around us that we feel we know and connect with at some level, in some set context. Let me ask you: does adding 30 million people into your community make you feel all warm and fuzzy?
With the introduction of OpenID/i-name authentication into more community networks/web sites, reputation (and the associated themes of trust, accountability and privacy) is quickly being seen as an important factor in any healthy online ecosystem. It is especially critical when people can join a community anonymously (note that a working email address alone does not provide any useful measure of accountability - see e.g. Mailinator). A network devoid of accountability is of limited - if any - usefulness, for when spammers and trolls can share equal footing with responsible netizens, trust and the all-important feeling of safety and security that a healthy community provides is lost. Further, as the value of reputation grows, people will find it important to protect and grow their reputation, as it will become increasingly common to ignore comments by people with little or no reputation - after all, they could be spam-bots.
So how do you begin to trust people you may never meet? This is a much researched and fairly well understood property of social networks - that you can grow to trust the wisdom posted by Bob simply by the history of his (assuming Bob is a “he”) postings in a particular forum. Thus, Bob earns a certain respect, or reputation, within the community. As the community grows, reputation can diffuse; but too small a community can appear as a conspiracy and also not be trusted. But if one has a normal amount of reputation and is also to be found in multiple communities, this is another way reputation can grow.
With the introduction of OpenID, small communities (such as those I work with at CivicActions) will be able to provide a basic (perhaps “default” may be more accurate) reputation (or rating) service enforced by their society contracts. In our case, we can additionally provide a strong foundation for inter-community reputation growth and management since we foster the growth of several communities a month and have intimate knowledge of how the community sites are constructed (we build ‘em!).
Some Technical Details
To support inter-community SSO, we will create and maintain a centralized, secure repository of user information (a “profile store”) that contains e.g. user names and email addresses. (This is separate from the authenticating I-Broker (or OpenID Provider) that can authorize access to the profile information under user control. And while the XRI technology underlying i-names supports distributed identity and data-brokers with encrypted data stores, these won’t exist in the initial release.) The profile store will also manage data contracts (or “Identity Rights Agreements” (IRA)) that client sites (AKA “Service Providers”) will electronically sign in exchange for profile data (such as an email address). A simple IRA for access to a user’s email address might include clauses like:
We agree to:
- never sell, rent, trade or otherwise make available your email address to other parties that you have not explicitly agreed to;
- refresh our cached copy of your email address from the profile store before use, thus ensuring that we always contact you at your current and correct address;
- remove your email address from our servers should you request this (perhaps as part of leaving our community);
- …
Since the profile manager (and community I-Broker) are both maintained by CivicActions, and since we will be hard-coding the IRAs and profile sharing protocols, we will be a de facto reputation server as well. Over time, we will implement identity and data portability as permitted by the XRI protocol standards. We’ll do this not only because we are committed to zero lock-in and want to enable our clients and their constituents to move freely, but also because it makes sound business sense to allow the free flow of people and their ideas in - and out - of any space, thus empowering each and everyone to find their spot where they can shine.
Back to Reputation
As peer-to-peer OpenID authentication will enable Single Sign-on (SSO), there will be a much lower barrier to entry (and exit) to (from) our client sites. This will enhance the vitality of each community by enabling members to more easily find where they feel most connected and useful while not being concerned about (re-)joining, who has access to their email address, etc. Yet the use of a single identity across multiple communities will enhance each user’s ability to gain reputation and trust in others that have gained reputation.
The value of CivicActions reputation will have additional use/importance as we start to provide/consume reputation metrics to/from outside communities that we develop peering (trust) relationships with. Note that no centralized or globally defined namespaces are needed - that can all be done the same way we’ve always done it - personal and group-mediated introductions at the grassroots. By providing a sound basis for building trust and accountability, our reputation service can empower a global community that shares our values and helps (us and our clients) move the world forward.
by =fen at February 21, 2007 11:02 AM
Powered by Planet!
Last updated: November 21, 2008 05:03 AM