The Tao of XDI

SXSW

2009-08-24T09:27:00.001-07:00

If you have a chance; check out this proposed session for SXSW:http://bit.ly/vuPu5. Have you noticed that when you search the internet you probably don't see results from the stuff that you pay for (subscriptions, stuff available through your local library, etc...)? this panel will discuss how we could fix that... If you think that would be useful.. go give it the thumbs up.

Accountability

2009-07-20T07:24:00.000-07:00

I have written about reputation in the past and continue to evolve my thinking on the subject. I had an interesting interaction last weekend with Lillie Coney of EPIC while on a panel together at ALA. Lillie described the legal frameworks that exist to both protect and circumvent our privacy as a lawyer and a privacy expert she described the steps necessary to strengthen our privacy position in the law. I found myself pushing back on Lillie; expressing that Reputation systems are just as important as systems of accountability for privacy as legal frameworks. If we had more time I think we might have had an interesting discussion on the subject.

Here's the summary I reached in my head: I do not deny that the legal system works to protect our privacy interests at certain levels. However, as an individual with a compaint against a large company I have very little recourse. For me to take action, personally, against a large corporation is prohibitavly time consuming and costly. I believe that robust reputation systems can help give me a way to have a voice.

We know that there are places that the legal system works. We know that there are places that reputation systems work. There is a gap between these 2 places where very little works. Lille was explaining how we fill that gap with legal framework. I propose that we can also fill that gap with well constructed reputation systems. I don't think this is an either-or situation; together these things can provide robust protection and accountability that is available to everyone.

My point is that while those of us who think about reputation recognize the importance of the legal frameworks, I'm not sure that the people who work on the legal frameworks recognize the importance of the reputation systems.

What do you think?

Is anybody out there

2009-06-12T10:07:00.000-07:00

It's been a long time since I blogged :-( and even now I'm just asking a question...

Now that I am actually implementing SAML stuff, specifically Shibboleth (mainly web sso). What book would you recommend I buy?

THANKS

What is SSO

2009-03-03T07:48:00.001-08:00

One of the hottest issues in Identity Management is often referred to as SSO; Single Sign-On. However it is a horribly misunderstood and misused term. I will try to give a brief overview of what SSO is and isn't.

What most people mean when they say SSO is the user experience of accessing multiple services and systems but only having to 'log-in' once. On the face of it SSO sounds great but there are some pitfalls that we have to be wary of. If we aren't very careful, the 'ease' of SSO is bought at the cost of privacy.

The type of SSO that I am going to explore is the "HTTP Redirect" SSO mechanisms that are widely deployed for SSO on the web. This includes OpenID, Shibboleth (Web SSO), SAML (WebSSO), FaceBook, Yahoo! and Google, to name a few. These protocols differ in many details and have different strengths and weaknesses but they all share the same underlying HTTP Redirect mechanism. The basic pattern is this:

1. Jane navigates to a web-site and she wants to log-in using a username and password that support SSO.
2. Jane clicks on the 'login' button on the page.
3. Jane has to tell the web-site who her SSO service provider is. This is known as the Where Are You From problem, otherwise known as WAYF. More about WAYF in a moment.
4. Once Jane has told the web-site who her SSO service is; a HTTP Redirect is sent to the browser to send Jane off to her SSO service.
5. At her SSO service Jane is asked to provide her UserName and Password.
6. If Jane convinces the SSO service that she is, in fact, Jane, then she is returned (via HTTP Redirect) to the original web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
7. The web-site and SSO service communicate in such a way that the web-site can validate that this is really SSO service XYZ talking AND if it knows and trusts service XYZ it can go ahead and accept that this is Jane.
At this point we have performed 3rdParty Authentication or Federated Sign-On NOT SSO.

8. Having done what she came to do Jane now navigates to another web-site.
9. When Jane arrives at the second web-site she is NOT recognized as being logged in. This site has no knowledge who she is or that she has logged in somewhere else before. If Jane wants to access 'protected' resources at this web-site she is going to have to click on the log-in button.
10. Again Jane will be asked Where Are You From and she will select her SSO service provider.
11. The web-site will then send Jane off to her SSO provider asking... "Who is this?"
12. Because Jane logged into her SSO service just a few minutes earlier the SSO service doesn't ask Jane for a UserName and Password this time, it immediately returns back to the web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
13. The using the same trust validation as above the web-site can now believe that this is Jane

And Jane only logged in ONCE... that is SSO.

Jane still had to click on login twice and still had to provide her SSO service twice but she only Signed-On a Single time.

There are variations in this flow, OpenID nicely shortcuts the double SSO service provider selection BUT you have to type in your UserName twice.

The most common expectation of SSO that is not satisfied by the flow described is "why didn't the second site just 'know' that I had already logged in and who I was?" Apart from the fact that would be technically difficult the answer is actually that REALLY you wouldn't want that behavior... Once I explain why:

If SSO worked that way, when you logged in once, everywhere you went on the internet would know who you are. Not just an IP address, they would be getting a message "here's Jane". All of the web-sites on the web could talk to each other and work out EXACTLY which sites you visited and which ones you didn't. That is generally considered to be a terrible breach of privacy. In order to avoid this privacy leak clicking 'login' remains an explicit action that the user must take. The action no longer means: "I want to enter my username and password" but now means "I'm OK telling this site who I am."

There are ways for 'closely connected' sites to shortcut this experience. Handing a user from their Local Library System to the Consortia Meta-Search interface; a handoff that is between trusted parties; Janes identity CAN be passed from one service to the other providing the 'seamless' SSO that we would love to have. But you can't be sure that Jane was OK being identified at the second system unless you make the action explicit. As a service provider you have to make very careful choices between seamless SSO and user privacy.

Rather than going on now:- You can tune in later for "SSO using Pair-Wise Identifiers to protect your privacy", "How and Why OpenID is different from Shibboleth Web SSO" , "Why you MUST trust your SSO service provider because they know a lot about you"...

Please ask questions if I haven't been clear... Please let me know if you think I have said something misleading or wrong... I'm just trying to start a conversation here.

IDM 101

2009-02-10T09:59:00.000-08:00

I am now blogging at http://worldcat.org/devnet/blog/ I am going to be posting a series of posts that introduce basic Distributed Identity Management concepts, as I understand them.

I can't decide if I should double post those posts here as well:

reason to post here..

although it is all basic stuff I am interested how much my understanding and articulation of the basics aligns with your understanding.

reasons not to post here..

if you want to read the stuff over there... you can just get that feed too.

What should I do?

What's in a claim?

2009-01-26T09:21:00.000-08:00

The use of infocards does not dictate a specific authorization pattern. There are at least 3 authentication patterns at play that I can see... Identification, Roles based and Claims based... We can, and do, use all three of these interchangeably and simultaneously. I will explain what I think these three patterns are:

Identification:- Provide a previously know ID that relying party can resolve to a user record that has all of the additional information needed to make permission decisions. In this case only one claim is ever needed... the ID as one assumes that ALL other information is in the user record. The major problem with this pattern is that sharing the same ID between different relying parties is often impractical and definitely bad from a privacy standpoint. Using pair-wise PPIDs does not really satisfy the Identification pattern as all you are enabling is the ability to say "this is the same person as logged in as before" but not get a lock on a user record (unless you do a mapping at each RP which is probably the BEST application of this pattern).

Roles Based:- (See: http://en.wikipedia.org/wiki/Role-based_access_control ). With Role Based Access Control (RBAC) you don't need to know who the 'Subject' is; you trust the IDP to enforce policy and assign the roles and the RP simply has to present the functionality and access based on the roles provided. The major, known, problem with classic RBAC is that it fails to address either resource or person specific access control. There is lots written about this failing so I will refrain from going into details :-).

Claims Based:- With this pattern all of the information that is needed for the RP to enforce policy is presented to the RP by the IDP. This includes not only the claim values but how the claim was established. Sometimes knowing that the IDP is willing to assert something to be true is enough to trust it, at other times you want to know that the 'Over 13 years old' claim was based on a more rigorous check than... "they checked a box that they are over 13". Claims based authorization becomes especially powerful, IMO, when you take claims from multiple claims providers so that you can do uniquely specific authorization and service delivery at each RP based on a Claims Network.

Classically websites have used 'Identification' to authorize users. A user logs in and the relevant record is found in the database. RBAC has been widely deployed in Enterprise type settings or in 'tight' federations; where the IDPs and the RPs can collude to agree on Role names and Role interpretation. Claims Based authorization is the solution that is growing to address the needs of a distributed authorization framework or 'lose' federations.

Roles are probably defined in the context of a 'vertical' (industry, community, academic practice, etc..). Claims are the raw data about the subject and 'tend to be' as objective as possible so that the consumer can apply its own policy.

I personally believe that Claims Based is a powerful way forward and should be embraced, however, we also need to be realistic and pragmatic. In cases where there is a known tight relationship between the IDPs and the RPs mixing these 3 patterns together seems expedient. There is no point going to great lengths to build zero-knowledge identifiers if you KNOW that each relying party is going to then require an email address (unless you are also confident that the users have mechanisms to deliver and manage zero-knowledge email addresses).

SO.... specifically....

* I think that the Library Community is homogeneous enough that we can define so mutually agreeable Roles, like the ones you suggested.
** Faculty (Academic libraries)
** Staff (all types of libraries)
** Student
** Adult
** Young Adult
** Juvenile

* Where needed, service providers can establish mappings between PPIDs delivered by the infocards and internal IDs for Identification.

* ILL and Electronic Resource Delivery (eBooks) will require Claims Based authorization to augment the Roles so that the systems know not just that the user is a patron, but that they should have access to 'this specific eBook' from 'this date to that date'.

So the delivery mechanism that we are using, ws-* / Information Cards, IS a Claims Based framework, BUT, we are using the framework to deliver claims to enable all 3 authorization patterns.

Do you agree?

The winner is:

2009-01-20T13:56:00.000-08:00

As you know, I have been trying to decide how I think we should model the ‘roles’ claims for the ICF’s pilot Library Card project (see my last post: The Claim Game). I have talked, emailed and blogged with a bunch of people who have opinions on the subject and have come to the following conclusions.

Off the point for a moment: There seems to be some consensus that if the policy description and interpretation step that goes on between the relying party and the ‘selector’ was richer then we may have better options open to us. However, today the Information Card specification is what it is and I don’t recommend putting a hold on our project in the hope that it might change.

The options that we have are either to have a single ‘roles’ claim that contains a list of the roles that the user has been granted, or, to have separate claims for each role. The separated claims could be on different cards but I see that option as being basically the same as option 2.

Having thought about this a bunch I think that the better option is option 2, a separate claim for each role. This will force us to formalize and standardize the role names, which is not ideal, but, it provides the best privacy protection and ultimately the smoothest user experience. While the user experience may be a little more complicated on the face of it, I believe it is superior because it will be predictable.

With this option the presence of the claim indicates the assignment of the role. The value of the claim is basically ignored, as it is in the selectors’ card selection process. If a resource indicates a specific role or set of roles that must be present to gain access; only cards capable of satisfying the policy will be presented as selectable cards.

I look forward to hearing why I am wrong :-)

The Claim Game

2009-01-06T12:13:00.000-08:00

I-Cards provide a mechanism to deliver claims to relying parties (RPs) . The first i-card claims that we all became familiar with were the ones built into the CardSpace v1 client. While one COULD build an RP that asked for claims that were not one of this standard set the chances of finding a user with a card that had any other claims was pretty slim.

We are now entering the next stage of i-card evolution and adoption where we want to start to extend the list of claims. I am finding that the simple patterns established by the first claim set makes this issue seem more trivial than it is.

The pattern that I personally, mistakenly, thought I was seeing in the WS-*, InfoCard, dance was:

RP says to Card Selector: “I want a nickname claim”
Card Selector says to User: “Pick one of these cards that has a nickname claim”
User selects a card and the nickname claim from that card is sent to the RP.

My misunderstanding was the assumption that the communication between the RP and the selector meant that I would only be able to select a card that would result in a successful transaction. Not only is this not true it is looking to me like I may get very little guidance from the selector as to which card I should select.

In my nickname example above just having a nickname claim may not be enough to... for example... post a blog comment. The value of the claim may be null... The RP may tell me that someone with a different PPID has already used that nickname. And Nickname was an example that I picked as 'the most trivial self asserted claim'. When you get into claims of higher value this problem becomes more apparent. Try registering to leave a comment on Kims blog: All it requires is an email address claim BUT that email address is then validated via an email round trip (as it should be), my point being that the fact that the selector says a card can satisfy the policy of the site only gets me so far.

SO... I foresee, or fear, this user experience:

I navigate to a web site and see the i-card logo and click on it to 'login'.
The Card Selector pops up with... lets say... 5 cards highlighted.
I consider for a moment which one I want to send... and pick number 4.
The site then tells me that the VALUE in one of the fields is unacceptable (wrong issuer, non-unique, not a member of the formal options,etc..)
So... I try another of the cards that are highlighted and that one fails too.
So... I try another one... or did I try that one already?

Not only is the experience nasty, I just submitted 4 sets of data to one RP in a VERY correlate-able way.

So how do we avoid this pitfall?

It is possible that all of this can be solved in the selector, maybe it already is and I don't know it, PLEASE let me know if it is! The in-selector solution would be that the RP can communicate more of its policy to the selector so that the selector can make smarter decisions based on claims values and claims metadata not just the presence or absence of a claim in the schema.

Meanwhile... I have a problem... and I'm not sure what the solution is. Here's the problem:

I want to issue a Library i-card. One of the logical claims that one makes about the holder of a library card is what roles they play at the library; note that I say roleS not role. It is very common for an individual to have multiple roles at the same Library; they may be staff and a part-time student, faculty and staff, faculty and alumnus, etc...

So how do we model this in an i-card?

There seem to be 2 solutions; have one claim that returns a multi-value response OR have a claim for each possible role.

The first option; a single claim called 'library-roles':

In this case the RP always gets to know all of the roles of the current user even if all they needed to know is if they had a specific role.
I could have 4 cards highlighted in my selector but find that none of them deliver a claim that can actually satisfy the RP (after i have given them a LOT of information about myself).

On the other hand:

In the vast majority of cases the user only has one library card and it will either work or won't work.
The RPs are likely to be libraries and therefore trustable anyway?

In summary of option 1... can seriously compromise privacy, but that's OK.... if you don't care about privacy.

Option 2 is have a claim for each role. With this option you can maintain privacy but at the cost of usability. As I navigate the RP site I will be repeatedly prompted for 'another' card (could be the same one) as I move to parts of the site that require different roles. In this case I progressively give up privacy, if I want to, in order to get access to functionality. This again assumes that the presence or absence of the claim is actually more important than the claim value, which in this case is always assumed to be 'true' in order for this scheme to make any sense.

If you have managed to get to this point in this diatribe.... I would love to hear which option you think I should use... Or is there another option I haven't thought of?

Resolution Revolution

2008-10-16T06:52:00.000-07:00

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.

They say a little knowledge is a dangerous this... well here I go... head first:

DNS resolution has been under attack recently (last 6 month) from a new set of poisoning attacks. 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.

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)

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?

Is this reputed to be a reputation?

2008-10-15T09:23:00.000-07:00

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.

Another definition of reputation:

Reputation is the result of running an evaluation algorithm over a set of input data.

Some sample input data:

a) Number of sale transactions and number of complaints
b) Number of IM connection requests and number of IM spam reports
c) Ebay reputation, Credit score and number of points on my drivers license.
d) How much 100 people, selected at random, like Diet Coke

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.

Arguably the reputation of a reputation could be measured based on the quality of its input data and the quality of the evaluation algorithm.

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.)

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.

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.

I did my best...

2008-09-23T22:46:00.000-07:00

Paul, sorry I can't help with the fines but I was very interested to see that you are checking out "that" kind of book ;-)

The next stage

2008-09-22T20:03:00.000-07:00

Well now the rubber is going to meet the road....

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...

I now work at OCLC, 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.

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.

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!

The times they are....

2008-08-09T14:05:00.000-07:00

If you are reading this you probably know me and my work.

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.

Unfortunately, as many of you know, advancing technology doesn't actually pay the bills and we can't pay the bills any more :-(

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.

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.

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.

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.

A Wag for the TAG

2008-05-30T09:36:00.000-07:00

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....

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!!

There are parts of XRI that you simply CAN NOT DO with URI.... Like resolve an abstract identifier (urn).

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.

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.

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.

Let every eye negotiate for itself

2008-05-21T06:59:00.000-07:00

Paul's response to my latest post put me in mind of Claudio in Act 2 scene 1 of Much Ado About Nothing...

Let every eye negotiate for itself
And trust no agent; for beauty is a witch
Against whose charms faith melteth in blood.

Paul is correct that I must qualify my posts more carefully.

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.

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.

Post Script

That was meant to be wry bitting humor... not mean... does it sound too mean?

The Claim Game

2008-05-20T12:40:00.000-07:00

ooTao's Managed InfoCards now include a verified email claim and verified i-name claim.

If you want to consume these claims you will need to ask for:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/iname

I have blogged previously about how you might validate an iname claim

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.

If you want to start consuming our verified claims at your RP just let us know and we can do some testing together.

Did Info Card help?

2008-05-17T07:54:00.000-07:00

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.

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 Kim's blog. It's all about the qualities of Distributed Data Management that I have been talking about for years, but, it's Kim and Dave and Clayton Donley, 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 :-) ).

And that's when the problems started...

I can use digitalMe on my mac to log into our RPs and even to Mike's blog, 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.

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'.

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.

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.

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...

I think it was worth it though if I can finally get these guys to understand what it is we have built.

iPages a go-go

2008-05-06T07:47:00.000-07:00

I was reading Kevin Marks post that looks at Brad Templeton's post 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.

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...

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...

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.

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.

Steve does it again...

2008-04-21T08:31:00.000-07:00

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 article written by ooTao CTO Steven.Churchill which show very clearly who the real brains of this operation is.

More on Claims and XRDS

2008-04-16T18:49:00.000-07:00

I was recently contacted by Bob Wyman in regard to an earlier post of mine... the first question was:

Some time ago, you wrote:

SEPs in XRDS must be considered self asserted
claims and as such should not be trusted on their
face. Service Providers should publish the
mechanisms by which SEP claims should be validated
to be about a specific subject (authenticated
identifier). (ooo… I feel another spec coming).

Did that spec ever get written?

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:

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...
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?
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?

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).

I SAID: -

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...

John Bradley 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...

Use Case 1) How to assert at an arbitrary http endpoint (web page, blog) a relationship with a specific XRDS.

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.

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:

a) tell the user to 'go edit their XRDS' - and wish them luck :-)

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)

Use Case 2) How to assert a third party claim in an XRDS.
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...

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?"

If the question is: What does 'this service that I trust' know about the entity represented by this XRDS then the flow would be:

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)) .

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.

If the question is: What claims are available about the entity represented by this XRDS then flow flow would be:

1) Perform Service Discovery for a 'Claims' service (not yet formalized but we could make one up on the fly if we needed to).

2) Perform Service Discovery for the AuthN service (like above) to get a 'Key' CanonicalID.

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.

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.

If the question is: Are you a Pizza Parlor then the flow would be...

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'.

AND THAT"S THE END OF THE SIMPLE ANSWER :-)

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.

Did you spot the mistake?

XRDS patterns

2008-04-15T07:37:00.000-07:00

Talking with John Bradley 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...

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.

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.

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.

What do you think?

wow...what a week

2008-04-10T22:03:00.000-07:00

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.

Watch this space.

Check it out...

2008-04-04T23:25:00.000-07:00

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!!

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.

See you there!

Kind words, on the whole...

2008-03-07T08:14:00.000-08:00

Ryan Janssen wrote 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 :-)

looking back...

2008-03-04T09:48:00.000-08:00

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: http://drstarcat.com/

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.

Short and sweet

2008-02-19T07:05:00.000-08:00

It's not enough that I added Paul Madsen's Blog 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.

What is more, ID-WSF is proving to be a surprisingly good read too!

Open Source Ruby InfoCards RP Available...

2008-02-11T18:14:00.000-08:00

Working together Microsoft, LinkSafe and ooTao 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.

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.

The source can be found at:

http://svn.ootao.com/svn/ootao/dist/standalone-rp/

Log in as guest/guest

You can view the running test app on our test server at:

https://ibroker.ootao.com:802

why xri 2

2008-02-11T09:38:00.001-08:00

why xri

2008-02-11T09:01:00.000-08:00

I thought this email thread was interesting enough to share with you all... I was asked in an email...

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.

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.

Perhaps you can elaborate on the perceived limitation of URIs?

I'm publishing my response for two reasons...

1) Maybe my answer will help others with the same question.
2) So that other XRI folks can help refine my answer

So this was my answer:

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.

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:

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.

2) XRI's cross reference syntax lets you build your RDF tuples right into your address.

XRI://(uri://my_subject)*(uri://my_predicate)*(uri://my_object)

Here's an example directly from the w3c tutorial.....

http://www.example.org/index.html has a language whose value is English

Which it then breaks down to...

[http://www.example.org/index.html] [http://purl.org/dc/elements/1.1/language]"en"

could be expressed as:

xri://(http://www.example.org/index.html)*
(http://purl.org/dc/elements/1.1/language)*
en

although starting to slip in some more xri 'stuff' it might look like:

xri://(http://www.example.org/index)*(@ISO639-1)*(+en)

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).

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.

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.

how'd I do?

Business Networking that _didn't_ suck...

2008-02-06T08:53:00.000-08:00

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.

One of the networks that I have used along the way is BizNik 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.

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.

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.

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.

I guess I'll just have to drive people to my i-page...

All that glitters...

2008-01-30T09:07:00.000-08:00

A quick word about SPARQL....

John sent me this link to an InfoWorld article that discusses the changes that will happen once the promise of the Semantic Web becomes reality.

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.

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.

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'.

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.

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.

Open Source Brain

2008-01-20T16:54:00.000-08:00

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 Simple Identity Model.

I-Name news

2008-01-13T09:57:00.000-08:00

Did you see this?

[Twitter] Joseph Smarr posted on Twitter
You can now log into Plaxo with an iName! I just attached =joseph.smarr. OpenIDDevCamp rocks, as do John Bradley and Michael Krelin! :)

It's great having John on the ooTao team... Thanks all of you!

Relationships are real

2008-01-08T13:36:00.000-08:00

In my previous post I touched on the question of what is a Map. In our world, today, computers tend to make the distinction between the 'real world' and the representation of the world 'fuzzy'.

If I have an interactive 'map' of my water system and I redirect the water flow from that map; which came first.... Is the physical system now simply a representation of the virtual model? Is it a physical 'memory' of the state that I changed on my computer or is it the other way round? If the 'map' and the state of the valves in the water system are 'out of synch' which is right? My intention was to redirect the flow, therefore the 'map' is right and the water is flowing wrong. I need to fix the valve so that it correctly represents the map... or do I?

Conventionally one would assume that the map represents the physical state and that 'instructions' either successfully change the state or not. The map should be a representation of state not the authority for it. The software has the capability to 'poll' the physical networks state such that if the state changes the map can 'auto-correct' to current conditions. Depending on the completeness of the software we just have to hope that the physical network never gets into a state that it doesn't know how to represent.

But here's the fuzziness again. If the valve has a processor and a network connection (which it would have to have to respond to instructions) it can also 'poll' the system for what it's current state should be and auto-correct. So at what point is the physical system just solid state memory?

Another example I have been thinking about is gerrymandering. Does that districting map dictate where people vote or does it represent where they vote?

This makes my head hurt!!

All of this is not JUST mental masturbation; I'm trying to work out what comes first a 'map' of the social graph that establishes our relationships and is 'portable' or is there some other manifestation of relationship that the social graph is a portable representation of.

Here's my conclusion...

Relationships are real. Directed relationship objects MUST be reified in the identity network. Maps of the social graph will show different aspects (attributes) of both types of top level entity; entities AND relationships. Like interactive maps of the physical world where you can layer utilities, streets, satellite pictures and geo-political attributes to communicate (makes portable) the state of a given physical area. The 'social graph' is a map that communicates (makes portable) the state of some entities and their relationships.

An important quality of the 'portable social graph' is that each 'map' only represents a sub-section of reality. I would expect different people might have access to different 'maps'. I would expose different sub-sets of my entity and relationships data to different 'mapping authorities'.

So this leads me to the conclusion that before we can really address social graph portability we need a better understanding of what relationships are.

In systems that I have built that have reified the relationship object I have found the following qualities necessary...

Relationships are unidirectional and COMPLETELY controlled by the 'root' end of the arc.
Relationships are no different from any other 'claim' that I make about you, totally unsubstantiated. (good mapping authorities MIGHT only show reciprocated or verified relationship claims)
Other people are ALWAYS interacting with one (or more) of my relationship objects NOT with my entity object. (that's the point of reifying the relationship)
Relationship objects contain several different types of data...

Data that I keep about you, that is mine, only mine and is never meant to be shared. Stuff like "this guy tells really bad jokes" or "it's not in his profile but I know his home phone number is XXX"
Pointers to the data about me that I want you to have access to. (in my world, it is the relationship object that dereferences the pointers NOT the 'other' entity).
Pointers to (and caches of) information that you have exposed to me about you (and sometimes others).

XFN or FOAF are ways for me to expose a sub-set of my entity and relationships to PUBLIC mapping authorities. They are but a map of something a LOT more complex that needs to be given a lot more attention.

(of course xdi has all of this solved... if only you would all just use it :-) )

Social Graph Portability

2007-12-12T06:38:00.001-08:00

There's a lot of talk these days about social graph portability so I guess it's time that I explore the xri based idea that has been running around my head for the last couple of years. This post probably isn't going to go into any more depth than I have already thought about but I hope it will inspire me to go think some more....

The basic idea is this... I am =andy, you are =steve, I can create any number of directed, typed, relationships to you by using the extensibility of the =andy namespace....

=andy*(=steve) establishes a generic relationship.

=andy*(+friend)*(=steve) establishes a friend relationship.

=andy*(+trusted)*(=steve) establishes an actionable relationship.

Let me point out the thing that I think are cool about this...

These entries MUST have been added and/or removed by the entity that controls the =andy name space.
Typed relationships can take advantage of the 'dictionary' space (xris that start with '+') and therefore solve a lot of the semantic mapping issues.
By creating this entry in my name space this relationship has its own i-number, I have very literally reified the relationship. The relationship can have metadata, services and any other quality of a top level entity.
The target of the relationship can USE this identity; =Steve can assert =andy*(+trusted)*(=steve) as their identity... the fact that xri resolution for this succeeds 'prooves' that =andy established the relationship... You can xri resolve =steve for whatever flavor of authN service that you are interested in so the 'user' can 'proove' they are =steve... I AM =steve who has a (+trusted) relationship with =andy.
Group management IS relationship management =andy*(+family)*(=richard).
Relationships are STRONGLY directed. An assertion about a relationship with =steve means only as much as you decide to put on it. Did you know that me and Bill Gates are best buddies and that I'm married to Angelina Jolie?

A couple of problems with this as it stands:

It is ALL public. Maybe once I have finished reading the ID-WSF Service Discovery Spec I'll have a better idea how to mix and match the public and private parts of this in a more privacy protecting way.
There is no native xri way to query the graph. Even if I wanted it to be public there's no (currently speced) way to get all of =andy's +trusted people.

Despite the obvious problems, I think the strengths still make this something worth exploring and the problems something worth trying to solve. Part of why I like this approach is that using some simple wildcards lets me address and permission based on the graph in the same syntax...

When I sign up for the genealogical service it is understood that write rights are granted to =andy and =andy*(+family)*($children) and read rights are given to =andy*(+family)*($descendants)
I can send a message to =andy*(+trusted)*($all)

I guess that what I'm trying to say is this.... I don't see the Identity Layer and the Social Graph as 2 separate things. I think it's well accepted that any meaningful abstract identity system MUST reify relationships as top level objects. It must be an Identity AND Relationship layer....

We must not get confused between the world and the map of the world. It's great that with todays technology we can create these interactive maps that let you:

show all the houses and the roads
now turn off the roads and show the electric grid
now only show the sewer lines

But that isn't what exists... the connections between the house and the grid are real and solid. When we talk about the Social Graph we need to be clear if we are talking about the map of the graph or the actual reality it is meant to represent.

Option 5

2007-12-10T16:35:00.000-08:00

I was reading this post in Phil's blog, as I do, and had to get this thought out of my head...

Phil says:

There are basically four options for deployment, as far as I can tell:

Sell software that gets installed on customer hardware
Package your code onto a hardware appliance and sell the box
Package your code onto a virtual appliance and sell the appliance
Sell a hosted solution
All of these have advantages and disadvantages and each is appropriate in different circumstances.

Phil goes on to describe some of the pros and cons of each of these options... It's a good read. There is however another solution; well it's not really another solution, it's really just a variation on 4... But it doesn't have the problems described in Phil's post....

5. Have Wingaa host it.

Now this also has pros and cons like any of the other solutions... but is an option. Wingaa is all about High Availability, High Security and Non-Intrusive Identity Service Hosting by specialists in Privacy and Trust. That is our business... We want to take the support calls, keep the geographically disperse secure data centers in hot fail over mode. We want to persist all that PII and take on that liability, that's the challenge that we have set ourselves... Don't get me wrong, we plan to charge you for it. Security and availability and lots of liability insurance doesn't come cheap... but if you have a business that needs those qualities we can probably do it as inexpensively as you can do it yourself, without you having to do the work.

There are business for whom this fundamentally isn't an option, but there are also business for whom this is the perfect solution. You have the killer business idea, THE next social app, we have the capability to not only run it for you but to run it in an environment that can be trusted to protect the privacy of each individual above ANY business imperative. You can deploy quickly and cheaply into high production value mode without the burden of the upfront cost. You can look instantly credible to enterprise partners.... they'll say... oh, you use the Wingaa network.... GREAT!

Wow... what started as a simple observation that maybe we could help, in some cases, just became a my marketing guys worst nightmare.... Andy runs wild with words. (I think maybe the fever has come back)

What WIngaa Does....

2007-12-09T21:19:00.000-08:00

So the message on the Wingaa site still isn't simple enough. I'm going to try to fix that this week.

What Wingaa does is host services for other companies. There is more and more demand on internet companies to offer their customers more and more services. We help companies satisfy that demand with minimal cost and effort on their part.

That's a start... let's see what ends up on the site.

Looking good...

2007-12-05T07:17:00.000-08:00

The Wingaa website has been launched. Check it out at www.wingaa.com

XRI utils

2007-12-02T23:05:00.000-08:00

One of the things that I look for with new technologies is tools and utilities being developed that will make the technology easy to use. This week 2 such utilities have appeared...

Markus Sabadello of Parity and @freeXRI has developed an XRI Resolution Client for the iPhone... You can learn more about it and download it from here.

I also shared with a couple of people... and now with you, this Mac Dashboard Widget that lets you look into an XRDS document without having to remember the proxy resolver syntax.

If only it were that simple...

2007-11-21T07:49:00.000-08:00

Both Kim and Paul picked up this post by Francis Shanahan about the fragmentation of our online information. The center piece of his post is his diagram representing our information spheres... here it is:

I like the diagram in as much as it STARTS to show the problem we face. I dislike it because it implies a structure and solution that WAY over simplifies the problem.

Consider these 2 questions and you'll see what I mean...

Think about the next level out beyond the blue boxes... the attributes. You'll notice that there is massive duplication of information all around circle. This diagram totally fails to represent the interconnectedness of the data. The DataWeb is NOT a set of nicely ordered hierarchies and diagrams that lock us into that way of thinking, I think, do us a disservice.

While this diagram neatly implies that the blue boxes can be canonically categorized it is simply not true. My guess is if we gave each of you the job of categorizing the blue boxes you would come up with not only different groupings but different semantics for those groupings. Don't get me wrong; Francis's diagram is as valid a projection of order onto the mess as any. My complaint is that, we, the people trying to solve these problems must not get lulled into only seeing one dimension of this problem.

I think about the problem like this... Each of you do your version of Francis's diagram but include all the lines between the blue boxes that have data duplication. Also don't limit yourself to only putting each blue box as a child to only one green box... embrace the fact that World of Warcraft is a community, a social network and a gaming site. Once I have gathered all of you diagrams I make them all semi-transparent and put them on top of each other. That diagram is a fair representation of the DataWeb.

An interesting thing to notice is that the lines that go around the outer rim of the diagram are not, on the whole, subjective. We can build a 'rule' that says if two data points have the same value and the same update rules then they should be linked. In other words the lines at the third level should juxtapose fairly well from one persons diagram to the next. Notice that the linking rule is based on values not on labels as the semantic issues in looking at the labels adds another level of complexity.

So.... to the point.... What Francis described is exactly what I have been talking about for the last 3 years. If you take Farncis's diagram, with my radial additions, and put it into a linear form instead of radial, you get exactly the graphs that I have been drawing for years. Three levels, lines going up and down the levels and lines going across the levels. This is no coincidence; there is a fundamental 'truth' about that representation that is much like, in my mind, Kim's laws. This truth is not me, or anyone else, saying 'you must do it this way' it is us trying to point out "this is the nature of the DataWeb". What we have done, and I would be happy to spend time with any of you showing you this in detail, is specified a syntax for describing, precisely, the relationships in that web. Relational databases NEEDED ERD in order to get wide adoption, if people couldn't simply communicate, capture and represent the data models they were working with how could they ever build large complex systems. We need not just an abstract data model but a clear way to graphically represent that model.

Andy in the news

2007-11-13T11:09:00.000-08:00

who knew... Dale, of ooTao said stuff

XDI Update

2007-11-01T09:23:00.000-07:00

What a year... I just looked back and saw that the last time posted something that was really about XDI, on this XDI blog, was in March… That’s crazy!! Now in my defense I have posted quite a bit on XRI and XRDS and these are necessary building blocks to the realization of the XDI DataWeb.

So, here’s some of the news and my current thinking…

First and foremost… we have cut the 1.0 Version of our DataWeb Server!! This is the server that we have deployed as part of the Kintera Project (that you can read about in earlier posts). This feat is doubly amazing because of the magnitude of the problem that we are trying to solve and the fact that this year Steve Churchill has been working solo on this project. Steve has performed a Herculean task in building, deploying, supporting and documenting this project… He is a one man team of 20. THANKS STEVE!!

NEXT…

We implemented a plugin framework in our DataWeb server that lets anyone build plugins to access legacy data stores. It works great BUT it is something we made up. We are looking at replacing our plugin framework with Higgins IDAS (Identity Attribute Service). IDAS provides a ‘standards based’ interface definition for ‘Context Providers’… plugins to access legacy systems.

I have started thinking about the qualities that are 'lacking' in IDAS in order for it to be able to replace our plugin framework.... not that it does’t do, what it does, well... just that there are other things that it 'could' be made to do... that it doesn't now.

With the assumption that IDAS implementations sit 'close' to the underlying systems, on the same LAN, caching should not be needed, at least for the classic network latency optimization considerations. Caching could be used for fault tolerance and system failure scenarios but that's a whole other issue. Caching can reduce IO but the problems of keeping that cache in synch far outweigh that consideration if we solve the other problems that I talk about here. In theory, the data is 'right there' so duplicating it SHOULD not be necessary.

What we do need is the ability to 'find' stuff.... Find all of the Digital Subjects whose home city is 'Oakland'. What you DON'T want to have to do is:

1) Traverse all Contexts to see which expose 'Home City' attributes about their subjects

2) Traverse all Subjects in the identified Contexts to query and test the Home City attributes

While caching would improve this problem it is far from a good solution... we don't want to be doing mass traversals, ever, at query time.

What we want to do is pre-determine which attributes are going to be 'search criteria' .... yes.... you MIGHT want to search on any criteria, in which case you have to take the hit of searching without an index... they haven't even solved this in RDBMS world... you can build SQL queries that take days to run and then add a couple of indexes and run them in minutes. Once you have determined the uses cases… add the indexes. (compound keys and simple ‘set’ math across multiple indexes can give you significant flexibility and power)

Executing a search against an index results in a list of pointers to Subjects that meet the search criteria. It should NOT result in a list of pointers to the attributes themselves… remember you are unlikely to query… get me all of the home cities for all of the people whose home city is Oakland… You probably want to query something like; get me the email addresses and names of everyone whose home city is Oakland. (We do NEED to support ‘complex’ matching logic… startsWith, endsWith, greaterThan, beforeDate, etc…)

The next problem is optimizing the data access… The ‘easy’ way to process the results is to iterate over the list dereferencing the pointers… our experience has shown that this royally pisses off the DBAs…. What I mean is, if the ‘Context’ is an RDBMS then the iteration approach results in executing “SELECT email, fullname FROM people WHERE userID = ‘XXXX’” as many times as there are results in the set. This is slow and, as I said, not popular with the DBAs. You need to be able to package your query into “SELECT email, fullname FROM people WHERE userID in ‘XXX,YYY,ZZZ,ABC’” and then parse the results back in your ‘client code’. I put ‘client code’ in quotes because I don’t mean that this is done by the application coder but it should be done at the IDAS implementation. As an application developer I want to be able to say to “IDAS…. Get me all of the emails for people that live in Oakland and get back a list of emails” and never have to care that half of the emails were in Oracle and half were in PeopleSoft. BUT, I want to know that only 2 calls were made across the network (I have had to PROVE this to our customers in order for them to accept our DataWeb Server, they really care about this).

That’s my first pass at ‘what’ we need to do…. Next we have to work out ‘how’ within the existing IDAS spec :-)

Ohhh… and robust distributed transactional management. I will add others as I think of them.

Wingaa takes flight

2007-10-20T08:11:00.000-07:00

After months of background work Wingaa is finally born. Patrick Audley and John Bradley, recently of Cogneto and the ooTao team are glad to announce that Wingaa is finally launching.

Wingaa means 'My name is...' in the Central Alaskan Yup'ik language.

Wingaa will continue the work of ooTao in bringing together strong authentication and user-centric services, making them readily accessible to everyone.

ooTao will continue to develop core technology and provide professional services in the identity space.

OpenID and you

2007-10-07T21:56:00.000-07:00

John Bradley posted this great post about how to use your i-name at OpenID sites that don't have i-name support yet... It's a great tech tip for those of us that like to tinker. For the rest of you, don't worry; the new OpenID specs have full i-name support and will be deployed very soon.

Adopting Evolution

2007-09-27T10:19:00.001-07:00

In my bitchier moments I have been heard to say… “OpenID; brought to you by people who didn’t want to read the SAML spec”. I truly believe that the process of enhancing OpenID from supporting its original use cases to supporting a wide range of internet scale activities of varying values will eventually see OpenID evolve to be a fully compliant SAML definable profile.

So I have been asking myself; why has OpenID grabbed so much popularity while SAML, a much more mature, academically respected, ‘robust’ specification has been largely ignored by the cutting edge web 2.0 community…. an image came to me that I think might be profound, at least for me, and this blog seems like as good a place as any for me to try to get it out of my head.

I'm imaging a perfectly planned city… you bring together the best minds in social and urban planning and have them design and build the perfect city. Then you ask people to move to it… it’s big and empty and impersonal, its very perfection is off putting and intimidating. Meanwhile, just down the street there is a collection of mud huts with lots of people milling about, drinking beer and having fun. People are flocking to the village and it’s growing rapidly. The urban planners that built the city say; but don’t you see, you will need all the infrastructure that we have built in order to continue to thrive as a community, you’ll need police, medical and fire services, you’ll need schools and water pumping stations. But still people flock to the village to be part of growing something new and exciting. The villagers say; if we need police, someone will step up and become a police man, if there’s a fire we’ll get together and put it out. The inevitable outcome of the growth of the village seems to be a less well planned version of the planned city. It will, by inevitability, have many of the same features, some less well executed and some surprisingly better than the planned city.

To me, and maybe it’s just me, I know I would much rather be part of the village than move into the city. I might not want to re-invent the wheel but internet identity is a large complex and subtle system, like a city, it isn’t a wheel. Internet identity is going to have very organic qualities… I’m wondering if the growth, the evolution of the organic system isn’t the magic source that will actually humanize internet identity… I think it might be necessary that we start with simple organisms that can evolve, branch and each branch succeed or fail based on their efficacy in their ever changing environment. If two teams of engineers looked out over an early version earths eco-system and one designed ‘the perfect organism’ and the other designed an ameba capable of rapid reproduction and innovation which would you bet on for long time survival?

I’m not saying that the SAML community isn’t also receptive, open, innovating and evolving, they are. I repeat my original statement that I do think that SAML is more mature and ‘robust’ than OpenID… I’m simply trying to understand the juju that OpenID has (at least in my opinion).

now you're talking...

2007-09-27T09:29:00.000-07:00

Just been sent this link... a must see if you are very serious about social networking

OpenID 2.0 discovery (with 1.0 compatability)

2007-09-17T15:29:00.000-07:00

This is how we are doing it in our client libraries... does it look right to you?
(click on the image to see a readable version)

New RPs

2007-07-05T10:25:00.000-07:00

Well the first of the Geffen Artist web sites have gone live as OpenID 2.0 (WD 11) relying parties. If you have a little time go login and play around… we would love to hear your feedback about the integration and user experience. The first 2 sites are:

http://www.rooney-band.com

http://www.evefans.com

More news...

2007-06-25T17:35:00.000-07:00

I don't think I shared this with you-all...

GEFFEN RECORDS OFFERS SIMPLE SIGN ON FOR MUSIC LOVERS

ooTao, a Leader in Open Identity Management, Partners with Record Label

June 12, 2007 (Berkeley/Los Angeles) – Geffen Records, has partnered with ooTao, a leader in Open Identity (Open ID) management, to make it easier for music lovers to log on and connect with all their favorite artists, such as Snoop Dogg, Mary J. Blige, the Cure, Nelly Furtado, Trevor Hall, and Ashlee Simpson. The new “Single Sign-On” launches June 18 and will be expanded to include other Geffen artists as well as new services for fans.

Lee Hammond, Director of New Media for Geffen Records, has been working with ooTao President Andy Dale for almost a year to make it easier and more secure for fans to log on with a single user identification, or i-name. Says Hammond, “We love the promise of OpenID to reduce registration barriers for newcomers to our properties as well as make it easier for current audiences to crossover to new artists’ content.”

Artists love the new feature, too, said ooTao’s Dale, because music lovers no longer have to sign off and sign in again every time they want to see what’s happening with an artist. Using the same i-name, says Dale, fans can sign into the Geffen site and read about and listen to the music for their favorite artists without leaving the site.

More is in the works, adds Dale. “After this initial phase goes live on June 18, we expect to continue working with Geffen to leverage these identity standards and bring music lovers truly innovative services that allow them to get closer to the music and the artists.

ooTao (ooTao.com) is an engineering development company specializing in distributed data sharing and identity management infrastructures. Its founding partners are leaders in developing standards for Open Identity management.

#####

Expediting XPP

2007-06-13T08:10:00.000-07:00

I am hoping to quickly and painlessly work up a basic 1.0 spec for XPP (XRDS Provisioning Protocol). This should be simple and easy to implement. I am going to drive the process and try to get the spec done in the next month… then people can use it, or not.

If you want to be a part of this open process add your name to the people section on the front page of the xpp wiki at http://xpp.seedwiki.com. I will organize a conference call for the middle of next week for anyone that wants to play with me.

Validating i-name claims.

2007-06-08T07:27:00.001-07:00

There will be many ways in which people will assert claims over the internet and depending on the nature of the claim and the identity of the claimant we will have to do different types of validation. I’m talking about claim validation in a dynamic trust environment, in a distributed identity network. There is no assumption of a prior relationship between the asserting party (AP) and the Relying Party (RP).

When I talk about validating a claim what I’m really talking about is; is there a way for the RP to be sure that the AP can be trusted for this specific claim. When I say ‘this specific claim’ I mean 2 things;

1) that the AP is trusted by the community to make this claim type (just because they are trusted for one claim doesn’t mean they should be trusted for all claims)

2) that the identifier about which the claim is being made has indicated that this is their designated AP for this claim. (I think this is only an issue in some claim types)

Specifically I am starting with i-name claims and I will explore this from an InfoCard perspective. This is a totally valid way to authenticate ‘ownership’ of an i-name although the mechanism is totally different from an http redirect authentication protocol like OpenID, BBAuth, Google’s SAML implementation, etc… In the http redirect case the i-name is the identifier and therefore validation/authentication of ownership is the point of the entire interaction. In the InfoCard case the i-name is just another piece of metadata associated with the PPID. Self asserted claims about i-name ownership should never be accepted.

So here’s what an RP should do when they get an i-name claim via InfoCards…

Perform SEP resolution to find the designated ‘InfoCardService’ published by the owner of the i-name. The only AP that should be acceptable for claims about that i-name should be that entity. This should be enough validation. (Obviously you are checking the crypto to make sure that the AP is who they say they are.)

In order to defeat this validation a would-be spoofer would have to have subverted the XRI resolution and inject their own SEP; if the RP is using the http proxy resolver this can be achieved by subverting the DNS layer. Once I start to assume that DNS is compromised any validation starts to fall apart… so either use a local resolver in trusted resolution or some other mechanism of trusting your resolution infrastructure if you deem it necessary… personally I’m not sure that the value of the i-name claim in this context requires a particularly high level of paranoia. In the InfoCard usecases it’s the PPID that is the identifying key, and any additional services derived from the i-name should be separately validated anyway.

Final word on XRDS… for now

2007-06-05T08:08:00.000-07:00

So while posting a comment to Phil’s blog on this thread I finally hit upon the thing that I have been trying to say in a clear concise way… Sorry you have had to watch me formulate this idea in real time.

The simple statement is this:

SEPs in XRDS must be considered self asserted claims and as such should not be trusted on their face. Service Providers should publish the mechanisms by which SEP claims should be validated to be about a specific subject (authenticated identifier). (ooo… I feel another spec coming).

Even More on XRDS.

2007-06-04T11:18:00.000-07:00

Phil Windley picked up the XRDS conversation with a great post. I just want to reiterate my concern about misunderstanding of XRDS usage. You may have all already groked this in which case I apologize for the redundancy but I want to make sure that this is really clear.

The problem is this:

Lets say that I have 2 services listed in my XRDS, an OpenID authentication service and a photo service. I go to a dating service and log in using my OpenID. The dating service now looks for a photo service in my XRDS and finds it and presents the photos found as photos of me. The danger here is that because I logged in using one service listed in my XRDS that there is the impression that the there is some validation that the photos really are of me, this simply isn’t true.

All you can derive from the fact that multiple services are listed in a specific XRDS is that one of the entities that have access to edit that XRDS want to associate that service with that identifier. Service endpoints in XRDS documents should be treated like any other self asserted claim.

At this point I want to give a big thanks to Steven Churchill, ooTao’s CTO. I recognized this vulnerability of XRDS and discussed it with Steve, he then went ahead and solved the problem at least as it pertains to i-name resolution and services in XRDS. His solution is now a part of the XRI resolution specification, lookup Canonical ID verification.

Some things that do work:

If you know that services use the Canonical ID as their ‘key’ then you can use canonical ID verification to ensure that the same i-number is the subject of both your authentication request and your service access request. Assuming the service has authenticated and validated the user correctly when the service was provisioned you can use this mechanism to create trusted service bindings. The trouble here is knowing which service providers to trust, both in intent and implementation.

A simpler case that does work is the case like EZIBroker’s Claim Services. In this case the semantics of the services itself asserts the relationship between the services and the identifier. This works equally well with URLs or i-names (I think). A user authenticates (demonstrates their access to the credentials for a given identifier) using a specific OpenID identifier. The relying party then looks up the ‘claims service’ (could be WS-*, SAML, AX, XDI, etc…) The assertions that are generated by the claims service specifically assert the claim and the related identifier. For Example: signed {=andy is over 21}. If you find this claim from a service in =andy’s XRDS then it makes a lot of sense… If you find it from =jim’s XRDS you know there may be a problem. (of course if =andy and =jim resolve to the same canonical ID then it’s all good). A service that presents the claim; signed{this person is over 21} is obviously not useful in the context of an XRDS unless there is an additional authentication step that lets the user assure the Relying Party that they are ‘this person’.

NOTE: The EZIB claims service will be providing one-time opaque identifiers that can be used with claims so the relying party only need know that !2003!1928.2746 is over 21 and !2003!1928.2746 is the person logged in. This will satisfy some of the privacy concerns but not all, we are not claiming that we are building a zero knowledge system.

More on XRDS

2007-05-30T21:46:00.000-07:00

In trying to answer Saronson01’s question I seem to fall into a total flow of consciousness that might make no sense to anyone but me… sorry. I will try to frame this more clearly soon. Keep the questions coming as that is what fuels the fire...

Saronson01 asked

When "adding" services to an XRDS document how are the services used, viewed, etc.? It seems that there is a missing piece regarding how a service is actually "consumed." How would the i-name @images*andy utilize a flickr feed?

Now I think I understand the question.. but if I’m answering the wrong question restate and I’ll try again…

For the sake of this answer I am going to refer to i-names but this is mainly true for any identifier that can be resolved to an XRDS. The reason I say ‘mainly’ is that i-names assume an abstraction between the human friendly i-name and the persistent i-number (canonical ID). The i-name resolution infrastructure supports both trusted resolution and CanonicalID Verification. These are qualities not shared by URLs that resolve to XRDSs. Once we start to use the richness of the XRDS for discovering services other than OpenID for URLs we will have to explore the security implications of these differences.

The simple pattern for XRDS usage is this:

I go to some application… it may be a web app or it may be a thick app… doesn’t matter.
I enter my i-name into the app.
The app knows what service it is looking for so it performs Service EndPoint (SEP) resolution for the service it is looking for and gets back the needed information about that service, where it can be found and how it can be accessed.

The most common current usage of this pattern, today, is to find authentication services, i.e. To enable SSO. In that case the ‘type’ that is looked for is http://openid.net/signon/1.0

So to answer your question… why would I put my flickr feed into my XRDS. Here’s my answer…

I create a new Web Application that creates Flash photo albums for use on MySpace… It uses OpenID to authenticate people. A person comes and logs into my new service using their i-name. Once they have authenticated I need to know where to find their photos.. I could ask them, but if they have configured a service of type http://photo.feed/1.0 then I don’t have to ask them I just know… In fact if I know someone’s i-name I can look up their photo feed (just like I can look up their authN service) for whatever purpose I want.

Yes, XRDS is public, so you only want to put services that you are happy people knowing about related to your publicly know identifier.

Putting stuff in the XRDS rather than in AX (or XDI) makes sense when you are happy the information being public and you want the optimization of using a very light weight ‘resolve’ protocol on top of high availability backbone infrastructure.

The SEP schema (part of an OASIS spec) is specifically designed to describe this type of data. Sometimes there is goodness in using well defined, domain specific, schemas rather than abstract ‘can describe anything’ schemas.

Although resolution is designed to be public, we have devised several mechanisms to terminate public resolution in private realms for privacy and security reasons. These are useful for specific use cases.

Using i-names with CID validation and trusted resolution you can authenticate a user via OpenID and then access a service that they have in their XRDS (with the CID as the primary key) with a very high level of confidence that the service is truly related to, or providing information about the entity that authenticated. (Assuming that you trust the service, but that’s a whole other issue).

EZIBroker is in the process of building and rolling out an Age Claims Service that can be associated with an i-name… Any relying party who can provide the right credentials to the age claims service may have access (under the users control) to age claims about that i-name owner. The XRDS provides the glue between finding the authN service for the user to know they are who they claim to be (ok.. have access to the credentials for that account) and the Age Claims Service that provides necessary claims for the i-name user to buy their beer on-line.

Making use of the XRDS

2007-05-28T07:07:00.001-07:00

The XRDS (eXtensible Resource DescriptorS) document is an XML document that you will find behind every OpenID 2.0 identifier, both urls and i-names. The XRDS contains a list of ‘Service End Points’ (SEPs ) that describe the services associated with the identifier, where they can be found and how they can be accessed. Notably the most important SEP from the OpenID 2.0 (yadis) standpoint is the authentication endpoint that tells the relying party where the OpenID service can be found.

Remember that XRDS was originally brought into the OpenID as part of yadis; a mechanism designed to provide interoperability between OpenID and LID, 2 http redirect authentication protocols that both use URL identifiers. Yadis, and therefore XRDS provided a way to describe which authentication protocol was associated with this particular url. Once we know that a specific URL can be resolved to an XRDS we can associate any number of services with that URL… SAML authN, XDI, Higgins Context Provider Factory Class, Flikr feed, reputation service, age claims, etc… All of this is a given for i-names but OpenID urls have the capability as well.

The problem is this; XRDS documents are XML documents, not particularly complex ones but XML none-the-less. Imagine my mother… I bought an i-name for her… I believe she can remember that Gillian.dale is her name (shameless i-name plug: no I don’t know that she could deal with any url for of her name reliably). So, she has her i-name and uses it to log into services that accept openID 2.0, she now only has to remember one username and password and I get a lot less support calls.

What happens when someone wants to sell her a new service? Lets say that someone launches a better authentication service (and I know a bunch of people working on that). They do not want to tell my mother to go edit her XRDS… if her OP even gives her access. So years back, I spec’d (with help from others of course) an XRDS provisioning protocol. It’s a very simple http redirect protocol… Mum goes to a new service and wants to get it… she clicks on the ‘get this service’ link… the would-be service provider looks into her XRDS for the provisioning endpoint… and redirects her to it together with the SEP details for this new service… Mum now sees a dialog, from her own OP (with all the same phishing controls that she is used to at her OP for logging in) that says… “Service X wants to become you new service provider, do you want to continue?” … this makes total sense to her as she got this message as a result of saying “get this new service”. Assuming she tells her OP to go ahead and add the service it can now add the SEP to her XRDS and she has a new service (probably something to do with grandkids).

Now I never completed the XPP (eXtensible Provisioning Protocol) spec as no one seemed to care enough about it... So here is that first draft, if anyone out there wants to work with me on finishing it I would love it. I wrote this originally for i-brokers but it would be trivial to generalize it to any OP.

CAPEC

2007-05-23T10:35:00.001-07:00

If you build software that is meant to be secure you might find the CAPEC site as informative and useful as I do.

Distributed Computing

2007-05-02T19:45:00.000-07:00

I came across The Eight Fallacies of Distributed Computing today attributed to Peter Deutsch. The list is:

1.	The network is reliable
2.	Latency is zero
3.	Bandwidth is infinite
4.	The network is secure
5.	Topology doesn't change
6.	There is one administrator
7.	Transport cost is zero
8.	The network is homogeneous

I'm glad to say that these are all issues that we have explicitly addressed in our xdi work, except maybe, number 7 that I don't really understand.

People who like this blog will also like:

2007-04-05T10:17:00.000-07:00

Mike Jones at Microsoft has started blogging. Mike is one of those really nice, quiet, brilliant people that I have the pleasure of working with from time to time. He is deeply insightful about technology in general and digital identity technology specifically. I will be watching his blog and know I will learn from it.

The quality of data is not strained

2007-03-31T15:01:00.000-07:00

“The quality of data is not strained; It droppeth as the gentle rain from heaven Upon the place beneath. It is twice blessed- It blesseth him that gives, and him that takes.”– A bastardization of William Shakespeare.

I am often faced with the question; “Why don’t we just do this with our Web Services?” Generally when I’m asked that question it’s in relation to what I call Dataweb technologies. When I’m asked it in other contexts it makes even less sense.

There are many answers to this question and different ones tend to resonate with different people. One of the main qualities of the Dataweb that I strive for is the richness of interaction that one gets when accessing data, through ANSII SQL that is in a well designed schema. This is a quality that you only grock if you have spent time writing database reports or very data intensive apps. Those of us that have been there know that extracting information from a well written schema is a joy. In fact, given a little imagination and a reporting tool you can learn stuff from a well built data set that you didn’t know you knew. This phenomenon fueled a whole industry starting back in the mid 80’s when ODBC first hit our radar. We still build big data warehouses that we troll and derive new information and stats from, but only inside closed systems.

Back in the early 80’s all the data was locked up on the mainframes and we started writing PC apps that needed to access that data. Each time we wrote an app, we wrote a data driver to access the data we needed off the mainframe. There was very little reusability and no appreciation of the ‘value of data’. Then, along came ODBC, the first widely adopted manifestation of ANSII SQL, and everything changed. Now, you built an ODBC driver that could access your mainframe and went to town, you never had to write another custom driver again. This was the inflection point where we discovered that using a fluid, abstract, data access mechanism let us learn new things from the data we had already collected. The difference between those custom data drivers and the ODBC data access paradigm was that the drivers tightly bound the purpose of the access of the data to the mechanism for accessing it, while ODBC (SQL) provided an abstract mechanism that didn’t care what the data was or how it was going to be used. These qualities were inherent in the way we thought about those custom data drivers; when we designed and built them we built interface definitions getUser(), getInvoice(), etc… We used method invocation to access the data we needed. SQL provided us a way to query any schema in any way and ‘try new stuff’ without having to re-program our data access layer.

Given my example of getUser() and getInvoice(), what happened if I wanted to find out if there was any correlation between geographic region and annual total purchases… I was basically stuck waiting for the mainframe guys. With SQL in place I could slice and dice my 2 table schema (users and invoices) any way I wanted. I could look for patterns and play to my hearts content… but it wasn’t really play, it was the birth of business intelligence. Now that I could work out the profile of my best customers, I could target other people with that profile to become my new customers. How’s that as an unexpected outcome from a higher level of data access abstraction?

The way that we conventionally use Web Services today is not just akin to those old data drivers, it is the same thing. We know this, it’s inherent in the names of the protocols that we use, XML RPC, Remote Procedure Calls; method invocation. getUser() and getInvoice() would be very reasonable methods to see defined in a WSDL.

Now sometimes you need the quality of RPC, you don’t want people to be trolling through you data and deriving all sorts of stuff, you want to keep them on a tight leash, so use conventional Web Services. I call this integration pattern ‘application integration’, not data integration.

The protocols that support the Dataweb, XRI, Higgins, XDI, SAML, OpenID, WS-*, etc… provide mechanisms to access a distributed network of data with the same richness as if you were accessing a single data source via SQL, but with more control. Imagine doing a database join between two tables, now imagine doing a join between two heterogeneous, distributed systems… wouldn’t it be cool.

The qualities of an abstract data layer are; a well defined query language that can be used to access a well defined abstract data model that in turn returns a persistence-schema agnostic data representation. These qualities are shared by SQL, XDI and Higgins.

When contemplating a data abstraction for a distributed data network there are some other things that we have to add to the mix; trust frameworks, finer grain security, social and legal agreements, network optimization, fault tolerance, to name but a few… And that is what I spend a lot of my time thinking about.

So I hope that this describes somewhat why Dataweb technology is different from conventional Web Services implementations, although they run on the exact same infrastructure.

It is interesting to note, and I may be way off line here so if you know better please correct me, from what I’ve seen: SalesForce agrees with me. What I mean by that is that their new generation Web Services are some of the most abstract interfaces you are likely to see in a system that derives so much of its value from its programmatic interfaces. (Along with Kintera who we are working with). The only downside with the SalesForce approach is that it’s proprietary, which is a shame, when there are open standards that, appear, on the face of it, to satisfy their requirements. (SalesForce, I’d love to hear from you if you want to talk about this.)

Higgins IdAS and XDI

2007-03-14T06:18:00.000-07:00

The more I look at the Higgins IdAS the more I recognize that it is the part of the puzzle in the Higgins world that maps fairly closely to what I call the XDI Engine. They both present abstract data interfaces that are meant to be put in front of legacy persistence. I have been telling Paul for a while that I think that IdAS is going to need indexing capability to be really useful. I realized, not long ago, that we need to replace the ooTao specific ‘plugin’ engine with an IdAS implementation. I am seeing more and more that once xdi takes into account the Higgins IdAS use cases and Higgins IdAS consumes the xdi use cases as sub sets of the complete ‘dataweb’ use cases that an xdi engine and an IdAS implementation are going to end up being pretty much identical. I watch the Higgins-dev list and learn and hope to contribute where I can.

In that light I am going to start putting more Higgins musings on this blog as well as xdi stuff.

Here is a thought provoked by a current discussion on the Higgins list:

The way that we are dealing with systemic and semantic mapping in xdi is by introducing an xri abstraction into the mix... attribute types are xris, generally in the '+' namespace, known as the 'dictionary space', like +email, or +first.name. Unlike the '=' and '@' namespaces the '+' namespace is not a rooted space, but I'll get back to that.

So in xdi land, any attribute name is resolvable in dictionary space to a dictionary entry, a dictionary entry may include a bunch of different stuff, including:

synonyms (both semantic (street and rue) and systemic(phone_number and phoneNumber))
schematic constraints (+address = must link to 1 or 2 streets, 1 city, 1 state and 1 zip... I KNOW that +address is a bad example because it's not a global construct)
validations (validation lists, real expressions (masks), executable validation scripts (different implementations in different languages))
UI implementations (for building rich UIs for arbitrary attribute types; +eye.color may provide a color picker that limits color choices to natural human color range as dcom, .class, xul, etc...)

So, in xdi land, as we build indexes of the various contexts (one of the primary 'qualities' of xdi is indexing the contexts it knows about so that you don't have to go trolling 200 contexts to find the attribute that you need about a given subject); rather than indexing the attribute type '+email' we index the canonicallized i-number that the i-name resolves to.. +!3215.2154.1254.

example:

xri://=andy/+email, 'andy's email address', points to a specific attribute in a specific context but what we persist in the index is xri://=andy/+!3215.2154.1254

Now when anyone wants to do a get against the index they can search for xri://=andy/+email or xri://=andy/+e_mail or xri://=andy/+Email or xri://=andy/+doar.hashmali (transliteration from Hebrew) and get back the desired record because the type is always resolved back to the i-number. On set operations the xdi engine checks the validations and schema constraints of the type before parsing the operation back into the 'context provider' to persist the new data.

I said that the '+' space is not rooted, so how does it resolve? Well, just like with English, you can look up a word in whatever dictionary you want, you might prefer Webster’s, personally I like the Oxford Standard. This quality lends itself to supporting a seamless continuum of global, community and personal dictionaries so you can be as precise or as vague with any given term as you like. A person can specify the intended dictionary for a given type: @ootao*(+email) would be ootao’s definition of +email and IS resolvable in the global @ namespace.

The early dictionary implementations that we are working with use a folksonomy approach to building the communal knowledge… anyone can edit the dictionary. So if your system uses a field name for an attribute that hasn’t been mapped yet, you just add it to the dictionary. Once one person has added the ldap schema and one person has added the vcard schema the world now knows that +cn, is the same as +fn and they are both instances of +!3211.5485.3656, which is also +full_name, +person.name, etc…

I’m not saying we have all of the problems solved. Off the top of my head I don’t know how we would express the transformation between givenName, sn and cn… But I could propose a few suggestions if anyone was interested.

More on CardSpace and XRI

2007-03-13T21:01:00.000-07:00

I like CardSpace. I finally got it installed on my XP machine at home and have used it to log into Kims Blog. Installing it wasn’t as easy as I would have liked, it was a big download, a long install and then I had to get ‘special’ tech support in order to get it to work (by special I mean I had to call someone I know over at MS, in that department to help me). Now it turned out that it was an ‘obvious’ problem but on-line help was not easy to find and the error messages were not helpful. All I had to do was install IE7… another big download and install… BUT… that’s the price we pay for security :-)

I have seen CardSpace demos for years now, and have pondered the paradigm shift in the user login experience and have always liked it… Now that I’ve tried it I like it even more!! As a user experience this makes a lot of sense to me… and with some xri and xdi integration this thing could really rock :-0

There are 3 places that I would like to see xri and xdi integration into the CardSpace world. These opinions are based on a deep knowledge of xri and xdi and a pitiful understanding of anything beyond the basic mechanisms of WS-* that make up the CardSpace. I will try to explain the use cases and the properties of the interactions that I am looking for as I talk about these integration points and if there is alternate (better?) ways of solving the same problems I would love to hear about it.

Integration 1: Portability
One problem I still have with CardSpace is that my cards seem to be bound to a specific machine. If I create self issued cards at home and at the office and log in to Kim’s blog from both places; how do I get recognized as the same person?

In the Higgins project HBX card selector the Card Store is not on the client machine, it is ‘in the cloud’. I think that using i-names to bootstrap authenticating me and finding my card store would make CardSpace better. I want to walk up to any machine that is CardSpace enabled, enter my i-name, authenticate (using the multi-factor mechanism of MY choice) and have trusted resolution (not spoofable like DNS resolution) find my Card Store and let me use my cards. Now, I only have to log in once using my i-name, after that I just pick cards. Because I only have to log in once I’m fine jumping through a few multi-factor hoops to make sure that the authentication is solid. That would be cool!!

Integration 2: I-Name Authentication
OpenID is great a way to authenticate an i-name… but not the only way; I really like the ease of picking a card to login. BUT just because a card says “my i-name is =andy” does NOT mean it should be trusted. This is just the same as on Kim’s blog, my card asserted my email address but I still had to go through an email validation…you can’t trust self asserted claims!

So who should be able to make claims about i-name ownership… whoever the i-name owner wants…who the relying party is willing to trust… and here’s how that can work:

EZIBroker (an ooTao business) is about to start offering managed cards with i-name assertions. We hope that through our XDI.org accreditation and our general reputation we will become a trusted provider of assertions. But that isn’t enough… The owner of the i-name needs to ‘show’ that they have selected EZIBroker as their token service. They can do that by adding a Service Block of type “managed card’ to their i-name record (XRDS). So, a relying party, on receipt of an assertion that the ‘bearer’ of this card is the rightful user of the i-name ‘=andy’ should do 2 validation checks… 1) They should check that the asserting party is who they say they are and that they are trusted by the RP to make the claim and 2) They should perform xri resolution to check that the XRDS for that i-name does, in deed, designate that Token Service as the claims provider for that i-name (the theory being that only the i-name ‘holder’ can change the XRDS). XRI resolution should be performed by the RP anyway to persist the i-number as well as, or in stead of, the i-name.

Integration 3: Pointers as Data
This is close to the heart of my real passion… distributed data management. When an RP asks for an email address I want to be able to return either an email address OR a pointer to an email address. Today if an RP asked for an email address and got back an xri (or uri) I would expect it to be upset… and that’s why we need integration. There are use cases where you want to push the data to the RP, but there also use cases where having the RP be able to pull data on demand can be very useful (like current temp in your location so we know how much beer to deliver). In XDI land the response to any request can be one of 2 things… data or a pointer to data. In card space land the response can only be data (as I understand it). If the response is a pointer to data then the RP has to know how to dereference the pointer.. of course you want the protocols that support the pointer to protect privacy, have fine grained security, have link contracts, have pull and push cache syncornization… be xdi :-)

So at a REALY high level those are the 3 points of integration that I am interested in seeing between XRI, XDI and CardSpace. (The 4^th one that I have talked about on the TC calls is really an integration with the Higgins IdAS service not CardSpace so that will go in a different post).

I will dig into these more as time lets me… I’ll let you know when you can get i-name cards at EZIBroker i-brokers.

2007-01-25T08:37:00.000-08:00

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports... All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb... I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify 'Joe'; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted 'this is my i-name' should NOT be trusted); presumably XDI.org could publish that list.

So in summary... I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

XDiggins

2007-01-17T21:01:00.000-08:00

What is XDiggins? It’s what you get when you smash XDI and Higgins together at high speed. Last week Drummond Reed, Paul Trevithick and myself had the opportunity to get together and explore this synergy in some detail with a specific client use cases to explore.

The use cases that we were looking at were those presented by the establishment of ‘Wiser Commons’. The Wiser Commons is a group of nonprofit organizations who are willing to share information in order that all of them can provide better services and be more effective in their missions. The commons, lead by NCI and Jon Ramer of Intera, provided the excuse that Drummond, Paul and myself have been looking for, for years, to come together to try to ‘rationalize’ our various standards into a working solution.

Paul, Drummond and I spent 3 days together. The first day we spent with a small group of ‘techies’ from the commons discussing requirements. The second day we secluded ourselves and talked tech and the third day we presented a proposed initial architectural approach. Over the next couple of weeks I will dive into the details of the approach we are proposing, here on my blog, for all to see. Meanwhile, there is one main thing that is worth mentioning that I think is very exciting…. We did it!

The 3 of us finally achieved a level of understanding of each others work that we were able to build a single proposal that all three of us could agree to, endorse and understand. The single most startling thing that I came to understand is how similar our work is. Many of the ‘problems’ that we were having in understanding how Higgins and XDI should work together were not because they were incompatible but rather because they are so similar. The 2 efforts are deeply, profoundly, validatingly similar in their underlying models. There are certainly nuances that differentiate the 2 bodies of work but now that we are able to appreciate the big picture similarities we simply have plug the best-of-both together to get a working solution that transcends both and removes the necessity to choose between them.

Watch this space for upcoming details…

More Adoption

2006-11-03T08:14:00.000-08:00

It’s really starting to happen, XDI nodes are starting to spring up. This press release that went out yesterday illustrates that real businesses are seeing the value of doing this stuff ‘right’.

Another node in the XDI DataWeb

2006-09-15T21:34:00.000-07:00

The Netgroup of University of Rome Tor Vergata have brought up an instance of the open source XDI server to further their project to develop user-centric self-reconfiguring radio equipment (E2R project)

Check out these links:

G.Bartolomeo, S. Salsano, N. Blefari-Melazzi authored the paper: "Exploiting Access Control Information in User Profiles to Reconfigure User Equipment" - International Workshop on Ubiquitous Access Control (IWUAC 06), July 17, 2006 - San Jose, California, USA
The PDF
The PPT

It’s cool stuff and very exciting for me to see people using xdi to solve real-life problems.

Week at the knees

2006-09-15T21:21:00.000-07:00

What a week!! Not enough that it was Digital ID World so ‘everyone’ was in town. In honor of Digital ID World we ran our $5 i-name promotion. The promotion got picked up by Slashdot… and we survived, with our servers intact. We were hoping to sell 100 i-name during the promotion; we sold almost 1000. Additionally, I had some great meetings and participated in some great sessions at IOS (Identity Open Space, day one of DIDW).

It’s really starting to feel like we have pushed the ball to the top of the hill and it’s about to start rolling down the other side… It’s going to pick up size and momentum and smash into the identity silos blowing them apart (or they can open their doors and let the inevitable roll through, but once those doors are open they aren’t going to be closed again).

…And once we have distributed identity then we can manage distributed data… XDI, here we come.

Put a LID on it

2006-09-15T21:05:00.000-07:00

Great to see Drummond and Johannes getting together jammin’ to the XDI groove. As you may remember we did an XDI/LID integration demo about a year ago with Johannes’s help.

I Want My Name Now

2006-09-09T09:28:00.000-07:00

I have talked lots about i-names and promised value of an abstracted global unique identifier. We are slowly but surely inching our way toward realizing that value. On Monday we will hit XDI.org’s base service compliance deadline and you will see all of the current i-name registrars (I-Brokers) offering the authentication, contact and forwarding services. If you already have an i-name be sure to go to your i-broker and configure your services so that you can start to use them.

If you don’t have an i-name yet, or if you want more, this would be a great time to jump in. In celebration of the services launch and the Digital ID World conference we are running a three day promotion that lets people buy i-names for just $5. At that price I think it’s a no-brainer to buy a name just in case these things take off. If they don’t, you’re out $5, big deal. If they do take off you’ll look like a genius. How many time’s have you wished that you’d got into the .com space earlier?

Go to www.iwantmynamenow.com on Monday, Tuesday or the first half of Wednesday to get your low cost name.

You should ph-off

2006-09-08T09:11:00.000-07:00

Just for fun I built a FireFox plug-in to help protect OpenID users from phishing and Pharming attacks. The idea for this plug-in first came from Nat Sakimura one of the xdi.org board members and I was finally launched into action when Dick Hardt said "the solution is that we need 'something' on the client" the other week at an OpenID tech workshop. Now, I don't know if this is what Dick had in mind but it should raise the bar for a would-be phisher to succeed if it's used right.... Go on, ph-off

More on OpenID

2006-08-03T07:11:00.000-07:00

If you are in the bay area next week... or could be... check out this 3 hour workshop that will introduce what can be done and what is being done with OpenID. David Recordon, Mr OpenID, will talk about OpenID implementation; I will talk about i-names in OpenID and, if I have time, will show a quick demo I have of simple profile sharing using XDI that uses OpenID authentication.

On another note; have you heard about the $50,000 OpenID code bounty? If not, check it out.

I-Names and OpenID

2006-06-17T12:36:00.000-07:00

How exciting, I think I qualify as the first person to ever log into an OpenID site with an i-name. While I did have the honor of doing the first tests, I want to thank Kevin, Brian and Larry from JanRain who built the server and helped me install and configure it. I also want to thank the ooTao team, Steve, Barry and Frank who did all the work to get our i-names infrastructure to the point that the OpenID integration could work. It was an amazing collaboration of a bunch of very smart and very dedicated people.

I have to say, having typed in my OpenID url to authenticate a bunch of times, using my i-name is a really cool alternative. It’s easier to type, and the display name is a lot cleaner, it feels a lot more like a label that represents _me_.

Launch approaches and I think there are going to be a lot of these really cool ‘firsts’ with i-names. In the next days, weeks and months we are going to see a proliferation of i-brokers and i-services that embrace the user-centric vision. I’ll let you know about these as they become available.

Back to work, lots to do for the launch on Tuesday.

Link Contracts

2006-04-27T12:17:00.000-07:00

There are all of these lawyers running around the identity space getting involved in the technology issues... here's my revenge:

I know we are going to be talking a lot at IIW and the Berkman Conference about policy and standardization of data sharing agreements so I thought I would get this thought out of my head. This document basically says that I think we need to differentiate between several different types of agreements that need to be standardized to build a robust, dynamic, trust framework in which overlapping circles of trust can evolve. When the discussion focuses on “the data sharing agreement” I am often unclear about which one is being talked about.

XDI Workshop

2005-12-06T12:45:00.000-08:00

Yesterday ooTao hosted an XDI Workshop that dove into details of i-name single sign-on (ISSO) and talked at a higher level about XDI data sharing. The slide show is available here. The wiki that we used to publicize the workshop can now act as a place for us to continue to explore XDI implementation issues; linked from the wiki I have also setup a yahoo group for XDI developers.

YABP – Yet Another Blog Post.

2005-12-06T11:04:00.000-08:00

I just want to point you at the work going on at YADIS. If you are interested in XDI then you should be interested in YADIS. YADIS provides capabilities discovery that is not only compatible and interoperable with the XRI specifications but shares several dependencies. Here is a summary of the latest YADIS F2F. For the full YADIS story go here.

GR Mapping

2005-11-08T23:48:00.000-08:00

For you implementers out there here is an excellent article written by Steve Churchill, ooTao’s CTO, that gives a concrete example of how we executed our first successful Graph/Relational mapping implementation. This implementation utilizes the plugin architecture that our XDI Like (no spec) server supports.

I fought the law...

2005-11-04T08:31:00.000-08:00

So, I went out on a limb and coined a law a while back:

The value of a transaction between 2 parties should never be greater than the reputational collateral exposed by either party.

While at IIW2005 I had the opportunity to chat with Allan Schiffman of CommerceNet we got to talking about reputation and so I rolled out my law… he very nicely pointed out the flaw in my thinking; My law assumes that, like in the real world, people can only be in one place at a time, doing one thing at a time. My law breaks down if a user can build a $10K reputation and then enter into fraudulent $5K transactions with 100 people at the same time such that the latency of the reputation system is greater than the time needed to complete the transaction. It’s a great point.

I think this drives a change to my law but doesn’t completely invalidate it. There are 2 ways that I need to mentally adjust my thinking to accommodate this new reality;

Think Small. Reputation systems that are designed to operate within the size limits of workable human groups will be much more effective. For social accountability to be meaningful you need social collateral not just reputational collateral.

Add latency to reputational transactions that mirrors the latency of the reputational feedback mechanism. For example; when I agree to buy a laptop from you for $500 bucks you put your ‘seller’s reputation’ on the line, I get the right to effect your seller’s reputation by 100 points. That 100 points should be put ‘on-hold’ the moment that we agree to consummate the transaction and should only be freed once the transaction is completed to the satisfaction of the buyer. Another would-be buyer might now see the seller’s reputation as 400, with 100 on hold. This would reduce the latency of the system to almost 0 and limit ability for a seller to over-use their reputation. I think. This is just one way to negate the latency effect, I can think of others, it’s basically just having awareness of this problem and implementing _some_ solution to mitigate or remove the risk.

So maybe I can simply change the law to:

The value of a transaction between 2 parties should never be greater than the available reputational collateral exposed by either party taking into account the latency of the reputational feedback mechanism.

I think I need to strengthen that; I’ll work on it.

Easy is Hard

2005-10-19T13:11:00.000-07:00

I got this quote at the bottom of an email from Luke Kanies of reductivelabs; I love it.

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are 'obviously' no deficiencies and the other way is to make it so complicated that there are no 'obvious' deficiencies.
-- C.A.R. Hoare, Turing Lecture "The Emperor's Old Clothes" CACM
February 1981, pp. 75-83.

It makes me wonder; I have long loved the quote:

I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.
- Oliver Wendell Holmes

And have long strived for, and I believe periodically found, the simplicity on the other side of complexity. But, did I, or is it that if you stare at the same complexity long enough it starts to LOOK simple to you. When people tell me some of my work is too complex, I have to believe them, not discount their opinion because it LOOKS simple to me.

let them go, and if they love you...

2005-10-19T09:44:00.000-07:00

I talked about this in the interview but for my own sanity need to get it down on paper. One of the arguments against giving users control of their data and control of their relationships is that businesses and organizations would ‘lose control’. There is a fear that all of an organizations members (customers) would cut them off and they would be left high and dry with no affiliations left.

First let me tell you what I mean by ‘giving the user control’:

I am using a very simple use case; rather than the organization keeping my name and my email address, they just keep my i-name. Whenever they want to contact me they look up my email address, it doesn’t matter how many times I change it, as long as I don’t revoke their permission to see it, they can get my current email. I do have the right, and the ability, to revoke permission (as I should).

Here is why I think the fear is fallacious:

The ADMA (American Direct Marketing Association) says that mailing address data ages, becomes bad, at a rate of 15% a year. I couldn’t find statistics on email address aging but you have to assume that it ages faster than mailing addresses given how much easier it is to change email address than move house. So lets assume that email data ages at a rate of 20% ( and I think that is low). So, today, an organization can expect to lose 20% a year of their relationships simply due to the inefficiencies of the infrastructure. By adopting an identity centric architecture (ICA) an organization can eliminate this attrition completely. So what about the people that ‘opt-out’; well, they weren’t interested in your stuff anyway, clearly. If over 20% per year of people that have established relationships with you jump ship; you have a deeper problem that needs to be addressed. So, the net is, you have more people, more relationships, and they are known to be of a higher quality.

I think this is profound; by respecting your constituents, and empowering them, you end up with better relationships with more people. So you save above the line because you have a more efficient information system and you make more below the line because you have more, better qualified, relationships.

Sound Byte

2005-10-18T07:40:00.000-07:00

Aldo Castañeda interviewed me yesterday for his new series “The Story of Digital Identity::AudioArchives”. You can check it out here. I don’t think I ramble TOO much.

horse and car

2005-10-14T10:10:00.000-07:00

I had the opportunity to spend some time at the N-TEN conference in DC this week. It was very interesting getting immersed in the world of the people that we want to adopt the stuff we are working on. I was amazed at the ‘state-of-the-art’ that was being presented; they have a long way to go. My analogy for the day was:

They are all talking about how to better tether their horses to their carts. I tried to tell them about cars… They wanted to know how you tether a horse to a car.

The experts that were speaking were introducing the concepts of Web Services and Messaging (Pub/Sub). I was trying to tell them that those are the OLD answers to their problems. There needs to be a real paradigm shift. It’s going to take some time, and a lot of work. The glimmer of hope; there were a few people there that really got it. Together with those few people I think we can move this stuff forward by leading by example.

Do you respect me?

2005-10-03T14:42:00.000-07:00

As a follow on to the previous post; an interesting thing happens as the ecology evolves. When a vendor chooses to accept a given level of DSA (Data Sharing Agreement) they can (they don’t have to!!) register the fact with IDC(Identity Commons). This would enable them to get informed if that DSA was changed. It would also enable IDC to, with the vendors permission, publish a registry of vendors, or service providers, that accept that level of DSA. I could therefore choose my service provider, for any service, by searching the list of providers that are going to give me the highest level of control over my data. I think that’s cool!

Do you trust me?

2005-10-03T14:30:00.000-07:00

I have talked a lot about Link Contracts lately, so why stop now. As I have said, Link Contracts are composed of several, signed, parts. Some of the parts are network enforceable and some are not. The non-network enforceable bits are meant to be enforced in some social system of accountability. These non-network enforceable bits are what I refer to as the ‘Terms and Conditions’ of the data sharing. The bit that says “You may not sell my data. You may not use my data for any purpose other than the original purpose of this agreement”, that kind of stuff. The problem with these terms and conditions is, they aren’t meant to be network enforceable or, therefore, machine understandable.

So if we don’t do this right this is what happens:

I address an email to you with your i-name. My email client asks your authority for your current email address. Your authority returns a response that says; you can have that info if you agree to these terms and conditions. My client is meant to sign these terms and conditions and return them to your authority in order to get the data I require. SO, the problem is; I don’t want to read some terms and conditions every time I do anything that involves someone else’s data. You know I’m not going to read it anyway, but I don’t even want to have to do that extra click. I mean, who knows what’s in those terms and conditions? What’s to stop you from adding some line 20 pages down that says “By signing this agreement you agree to pay me $500”. If this is how it worked, the Dataweb would be broken before it even started.

So… what do we do?

Rather than us all writing and using our own DSA (Data Sharing Agreements; terms and conditions) we will use ones provided by ‘trusted third parties’. I can read IDC (Identity Commons) Standard DSA #5 once and setup a preference that I am always willing to accept data under those terms. So in future when I ask for your email, you will say “under IDC DSA #5 (version 1.3)” my email client will simply sign the contract and send it back.

Now, the reality is, I’m probably not even going to read the IDC DSAs but that’s the point of having it provided by an organization that is ALL about trust. I know that if IDC publishes this DSA under their name… it must be ok. Ultimately there may be other organizations that provide DSAs that we can all trust, or at least use; Visa, HIPAA, SEC, etc…

For now we need to bootstrap this ecosystem. I have worked with Owen of IDC to outline three basic DSAs that can get us started;-

1. Basic – This one will put some simple constraints on the consumer of the data to ‘respect’ the owner’s privacy. This is the first real step toward giving the individual some control over their virtual self. It will include:

No selling my data

No giving my data away

Only use my data in the context in which this agreement was forged

Upon request or discontinuation of this agreement you will anonymize or remove my data, remove all PII (Personally Identifying Information) and any contact channel information (address info). I call for anonymization as an option as companies must have the ability to execute their operational reporting and auditing.

2. Wild West – This is for the organization that wants to take advantage of the higher quality data source that the Dataweb provides, but cannot, for technical, business or other reasons, conform to the restrictions of the Basic DSA. Accepting this agreement would be no different from filling out a registration form at a service today, just easier for all concerned.

3. Full Empowerment – This agreement is for the truly forward thinking organization. Under this agreement the requester of the data offers reciprocation. They say they will give you a copy of your transaction records in exchange for having access to your data. In practice this would mean that I give netflicks access to my contact info and they will, automatically, programmatically, give me a copy of the list of movies I have rented ( and how much I spent, and how long I kept them and all that good stuff). When the contract ends, I still have a copy of that information that I can take with me to my new movie rental provider.
I characterize option 1 as individuals having privacy statements instead of organizations. Option 2 as, status quo and option 3 as the next step in the evolution toward a fully empowered consumer.

Ultimately, I believe, option 3 evolves to a point where vendors simply use our repositories as the place that they keep the data about us. By giving us that level of control, and trust, and respect; why would we go to another vendor?

Please let me know if you think we need another DSA, or that I am totally off base!!

Under Contract

2005-10-01T11:07:00.000-07:00

A key component of XDI is the Link Contract. The Link Contract is a digitally signed document that specifies the details of the data sharing agreement between the owner and the consumer of a set of data. There is various network enforced aspects to the contract but there are also social aspects of the contract. Lets break it down a bit.

If you look up Contract in the dictionary you get something like:

An agreement between two or more parties, especially one that is written and is subject to a system of accountability.

In most cases the system of accountability is the legal system. While Link Contracts could be written to be legally binding, we are still a long way from digital signatures being broadly accepted, especially automated ones. It is my belief that we are going to be much better served grounding our accountability in a reputation system. A mechanism by which quantifiable feedback is routinely provided when transactions end (or fail to end). The reputation system will have to be subtle and flexible. If I say something bad about you that might have implications on you, me, your community and my community. If I go around bad mouthing people all the time people need to have the queues to stop listening to me. Or, am I the people’s advocate who goes around outing bad guys, so people assign a good reputation to my negative opinions… ah, so much to work out :-)

identitainment

2005-10-01T06:45:00.000-07:00

Have you seen the ACLU Pizza movie? It’s funny. However, it paints a picture of how the world might be if ‘we’ (all the people I am working with) fail. As a counter point I wrote this story; how things might be if we succeed. It’s just a bit of fun.

spam-a-lot

2005-09-30T22:27:00.000-07:00

Well, it happened. I started getting comment spam. I'm going to turn off the comments and just use my i-name and contact page. That's life.

Do you know Dick?

2005-09-30T17:14:00.000-07:00

So, I finally got around to watching the movie that Dick Hardt made of his OSCON presentation. It’s very cool. I agree with almost every word he says. Of course, the devil is in the details. My opinion of the relative merits of the various protocols and standards that he mentions, I will save for another day, but I do want to disabuse you, the reader of this post, of one incorrect statement that Dick makes in his presentation;

XDI and XRI, have a very simple and open (OASIS based) APIs that include no specific transport binding specification. However, the current implementations (Java, .net and I believe, python) are all SOAP bound for a matter of convenience (and as a matter of practicality for the uses for which these efforts have been implemented). So, to state that they don’t “do web services’ is just plain wrong. (Other implementations that are bound to http and tcp will be coming soon for your personal identity service, but that’s for another post)

So, if you do know Dick….. please let him know. ( of course, I may have misunderstood what he was saying, in which case let me know).

Digital Birth Control

2005-09-29T08:43:00.000-07:00

It is an oft asked question; “how do we keep the bad guys out?” Out of our pristine identity meta-system that is.

One of the answers that concern me is that the ‘point of friction’ should be when acquiring a name. Before a community gives you a name, they should check if you are a good guy. If you prove to be a bad guy then it’s the provider of the name that must take action to fix the situation. I think this is a bad solution. I think that the same friction that will keep the bad guys out will also keep the good guys out, I think there would be privacy issues and I think that this would put an undue and unreasonable burden on the providers of names. Name providers can’t be running background checks and arbitration boards to adjudicate accusations of malfeasance.

So, how do we ‘keep them out’? We don’t. We just don’t transact with them, neither socially or financially. It’s all about reputation.

I have never stated a law before, and I’m sure someone has stated this before, but here we go, =andy’s first law:

The value of a transaction between 2 parties should never be greater than the reputational collateral exposed by either party.

I expect people that I interact with to have, and to expose, some history. That exposure only need be as great as the value of the transaction that they want to engage in with me. If they want to send me a message, show me that you have a good messaging reputation. If you want to sell me something, I don’t care if you spam or not, show me that you have delivered goods, in good condition, in the past. If you haven’t sold anything in the past, show me that you have a good messaging reputation and a good blog comment reputation and show me a third party asserted mailing address and… good enough, I’ll buy it.

So the bad guy comes along and he’s going to stand out like a sore thumb because he can’t show any history. I am obviously going transact with him with suspicion and care.

But, I hear you cry, how does a newbie gain respect in this virtual society? Well, there is special services setup for just that eventuality. Places, like Opinity, that will validate your email address with a human test, or enable you to expose your Ebay reputation to another context ( and trust that it is really your Ebay reputation). These trusted purveyors of reputation will give you, not only the ability to bootstrap your reputation, but a place to build it and manage it’s exposure.

And finally, it doesn’t all have to be good. I would accept a message from someone that has interacted with 50 people but had bad reports from 2 of them long before I would accept a message from someone that presents no history. Real people have good days and bad days, they make mistakes, they go out on a limb. Real people should have rich complex histories and reputations. The bad guys will not, they will either have no reputation or it will be flat and weird because they found a way to hack some part of the system to boost one aspect of their reputation.

It is vital that we have a rich, distributed, network of reputation that works in many different ways because, coming back to =andy’s first law, the investment in gaming ALL of the systems would be so great that it wouldn’t be worth blowing it on a any single transaction that is worth less than the initial investment anyway.

New DataWeb Service

2005-09-09T16:11:00.000-07:00

This is not exactly an XDI post but it touches on XDI and is all about identity and data sharing so I don’t feel too bad. One of the reasons I have been so quiet over the last couple of months is because I have been building business plans and strategies rather than thinking about core XDI architecture. The result of all this planning is DataTao.

DataTao (a working name) is going to be an interoperable data hub for user controlled data. DataTao is primarily about programmatic access to an individual’s data and only has as much UI as is needed to richly support its base functionality. I often use an analogy of Windows Explorer or Mac Finder; Apps that run on your computer depend on an underlying persistence layer (the file system) to work. The new generation of ICA (Identity Centric Architecture) based web apps will be dependant on the DataWeb for their underlying data persistence. DataTao will be the first DataWeb Explorer.

So why do I call it an ‘interoperable’ data hub? That’s because DataTao is designed to act as a bridge between many of the current identity protocols. While DataTao will provide storage for people that don’t have their data stored and available from elsewhere, its main purpose is to consume and forward data from its authoritative source(s). DataTao publishes your information, based on your permission settings, to all of the supported protocols. If you have a dataTao account you will be able to go to an XDI enabled site and have it establish a link contract for transparent data sharing. You will be able to go to a SXIP Network enabled Membersite and dataTao will act as your Homesite. You can visit a LID or OpenID enabled site and DataTao will provide the relevant interfaces for authentication.

If you have a LID, a SXIP Homesite, a public LDAP server or an XDI data service and you get a DataTao account you will be able to get the advantages of having all of them while still maintaining your data only at the one place that you already did. If you already have multiple places that your identity is published you can use DataTao to consolidate your identity into one virtual profile and manage who sees what from a single point.

It is my opinion that DataTao is a necessary and required next step in the evolution of the DataWeb. While DataTao by itself is NOT a compelling application it is a needed piece of infrastructure. It will hopefully encourage and enable people to build internet 2.0 applications and maximize the leverage of those already built. SXIP membersites will suddenly have a market not just of people with SXIP homesites but anyone with a LID or an i-name or an open LDAP service.

In order to drive adoption DataTao will provide some Apps that use the DataWeb for persistence in conjunction with the DataTao launch. These apps have not been finalized yet but will likely include Exchange and Mac Mail integration (Self updating address books) as well as a rich interface for person to person profile information sharing (i-share).

Despite the fact that the true value of DataTao is in the infrastructure piece that it puts in place, it is likely that all of the marketing that you see will be about the apps or the widgets that we deploy. But you, the tech savvy reader will know what it’s really about.

DataTao will be a free service that will have its public launch early in 2006.

For the true geeks amongst you...

2005-07-10T14:37:00.000-07:00

Here is some thoughts on how Error Handling can be improved using XRIs and XDI in distributed systems.

XDI Data Modeling Take II

2005-07-10T14:26:00.000-07:00

Here is a link to the same document (both .doc and .pdf forms). I have already largely changed my thinking on section 6 but I stand behind the rest though, still.

View from the top

2005-06-30T07:41:00.000-07:00

Click here for an image of XDI provided by Paul Trevithick that is just SUPER coool, THANKS Paul!!

XDI Data Modeling

2005-06-30T07:36:00.000-07:00

Here is a doc that represents months of thought about how dictionaries and applications might be built in XDI.

Graph-o-manic

2005-05-11T00:20:00.000-07:00

As Drummond Reed, Paul Trevithik and I continue to delve into the XDI Universal Schema and it's graph representation my understanding of it, and my belief in it, continue to grow.

I understand Kim’s assertion of his 7 laws. He’s not legislating; “You must do this”. He’s not playing god, he’s proposing that he has uncovered some basic truths about the state of things. I am starting to feel the same way about the power of the XDI Universal Schema. I believe that Drummond (it really is his brain child) has lead us into a VERY powerful, new way of representing data.

The Universal Schema juxtaposes, or superimposes, 4 hierarchical graphs on top of each other, one at right angles to the others. Every resource in the dataweb can be accessed through the constrained 3 level syntax (Auth, Type and Instance) axis or through it’s ‘natural’ schema (or meta-schema) representation on the second axis (once you have put it in the context of the authority that can permission that ‘document’).

Let’s Take a look…

In this image I see 4 distinct hierarchies; the first runs across the Authority level. This is a registry and the vertical graph would have been equally valid rooted in any of these Authorities.

The second hierarchy runs across the Type level. This graph describes a VERY simple schema; it shows the component parts of a US mailing address.
The third graph runs across the Instance level of the graph this MUST describe graphs that are valid instances of the schemas represented at the Type level.

Finally, the fourth graph is the one that runs from top to bottom. This is the graph that associates authorities with the schemas and the instances of those schemas. It provides XRI addressing directly to any point in that schema or schema instance. This enables very efficient traversal of the data as you can navigate the abstract schema until you NEED to drop down to the instance level to get the specific instances that you need.

Notably the first 3 graphs are totally un-constrained. At the Authority level this means that our registry is totally extensible. At the Type level this means that ANYTHING that can be represented in XML (which is a hierarchical metaphor) can be represented at the Type level (if you can describe it in RDF or XML Schema or RelaxNG you can put it here). At the Instance level it simply means that you can represent instances of the schemas from the type level.

Now, the final mind blower for the night…

I was talking to Jamie Lewis and I said “any object can be described as a list of name value pairs”… eyes, blue, hair, brown, street address, …, etc… in a simple world that might be true but even as I said it I knew that it was overly simplistic. But now looking at the XDI Universal Schema in the terms I just described I see what the vertical graph ‘also’ represents; it’s the association of, not ‘name,value’ pairs with an object, (an Authority) but ‘Schema, Instance’ pairs with an object. And That, in my mind, seems to be a mighty powerful way to describe an object.

Put a LID on it.

2005-05-11T00:12:00.000-07:00

NetMesh, ID Commons and ooTao jointly published a press release today anouncing the integration of i-names and LID through an XDI service.

To see, and play with, the demo that includes the LID integration go to the ooTao XDI Demo page.

Next... We will add a SXIP integration so we can demonstrate XDI i-name enabling and integrating LID and SXIP together. One i-name, one profile; use it as a LID or a SXIP homesite. (At least, that's the plan)

Face to Face

2005-05-05T13:53:00.000-07:00

Images of the XDI TC member that attended the Face to Face in New Orleans... with a twist.

If you want to view this silly bit of fun you will need to install the plugin (link at the bottom of the page). If you know the people on the XDI TC it's probably worth it. I have seen this working on IE and Firefox on PC and Mac. I have heard that some people have had trouble with Netscape 7.0 on the PC.

http://peru.ootao.com/docs/xditc/XDI_TC.htm

Another chance...

2005-04-15T15:15:00.000-07:00

My BlogMentor Kaliya has made me see the error of my ways. Here is the Intoduction to XDI in a format that is open and linkable... Now I want feedback on the content as well as the distribution format :-)

One long over due response

2005-04-15T10:06:00.000-07:00

Aldo asked:

Andy,Regarding:"'Typed Links' tell the XDI Engine to treat the link as special. the most common use of this is the $op* group ($get, $set, ...) that are used to link a contract to the data it permissions AND specifies, via the Link Synonym, what that permission is."I'm imaging a scenario where I've slapped a "$op*" to a piece of data that I own in order to allow another party to "$get" it. Now what happens when I would like to allow another person (from another "Authority domain") access to that same data? Does this require that I add another "$op*" link to that data (I'm thinking in terms of Contract Law (formation of a valid contract). Is there a potential problem if the data to which I allowed "X" access under a condition that "Y" doesn't get access to it? If I can just add another "$op*" how would "X" ever know that I've given "Y" access? Perhaps this is what you refer to in your presentation as a "collision"?Thanks as always for any info.

I think there's a couple of questions in here that I can answer;

The 3 questions I think I see are:

1) What is the mechanism for providing access to the same data for more than 1 person?

Once you have established a contract that provides access (a combination of set, get and delete) to a specific set of data you can connect as many instances of $link to that contract as you like. The signed copies of the contract hang off the $link instance not the $contract instance so each permissioned person has their own signed copy of the contract. You can permission all of the members of a community via a single $link instance, in this case when a member of that community actually accesses the data and signs a contract a new instance of $link is created specifically for that individual where the signed contract can be kept.

2) What is to stop the person I have given access from 'passing-on' access to others?

Rights paths always start with a segment that identifies who can use that rights path (=andy/($link)/(=aldo)) will only pass validation if the requester can provide an assertion that they are =aldo. However the same syntax the permissions community members also acts as a ‘forwarding’ permission. If @ootao* is the syntax for ‘any i-name delegated from @ooTao’ then by granting rights to @ooTao* I am giving the administrator of the @ooTao community implicit rights to provide access into my data by adding or removing members of the ooTao community. Similarly providing access to =aldo* would give =aldo access to my data and also people that aldo trusts.

3) What control does the consumer of the data have over the provider of the data?

At this point, none. As I have understood it so far there is no explicit provision at the XDI level to enforce the data provider to sign a contract. With that said, it wouldn’t be hard to model an application that required a signed signature at the application logic level. The application could even use the XDI contract negotiation mechanisms to implement the requirement.

One quick response

2005-04-15T09:49:00.000-07:00

Aldo asked:

I do have a question however about the following: "Even though some data providers adopt standards like iCal it is unusual and unlikely that any one protocol gains ubiquitous adoption. Low level standards seem to catch on but not high level ones - SMTP, POP3, SQL, HTTP, TCP-IP. XDI pushes Secure Data Sharing down the stack and makes it a lower level function. "Do you have an stats to prove that? I'm not questioning your assertion rather I think this might be an important point for me to address in my research and any "hard data" on this would be terrific.

No I don't have any facts.. I didn't think we needed those on blogs :-) I was just expressing my personal observation. I have subsequently be pointed at this quote by Drummond:

"protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity."

Although I can't find an attribution for it. We will have to look at XDI through this lens before going ‘main-stream with it.

You only make a first impression once...

2005-04-14T17:48:00.000-07:00

So, I have been working on a new 'Introduction to XDI' ppt. I put it up for review at the XDI TC yesterday and presented it to a bunch of engineers (about 15) today. I have incorporated their feedback and posted it here it is for further comment.

The Tao of XDI

SXSW

Accountability

Is anybody out there

What is SSO

IDM 101

What's in a claim?

The winner is:

The Claim Game

Resolution Revolution

Is this reputed to be a reputation?

I did my best...

The next stage

The times they are....

A Wag for the TAG

Let every eye negotiate for itself

The Claim Game

Did Info Card help?

iPages a go-go

Steve does it again...

More on Claims and XRDS

XRDS patterns

wow...what a week

Check it out...

Kind words, on the whole...

looking back...

Short and sweet

Open Source Ruby InfoCards RP Available...

why xri 2

why xri

Business Networking that _didn't_ suck...

All that glitters...

Open Source Brain

I-Name news

Relationships are real

Social Graph Portability

Option 5

What WIngaa Does....

Looking good...

XRI utils

If only it were that simple...

Andy in the news

XDI Update

Wingaa takes flight

OpenID and you

Adopting Evolution

now you're talking...

OpenID 2.0 discovery (with 1.0 compatability)

New RPs

More news...

Expediting XPP

Validating i-name claims.

Final word on XRDS… for now

Even More on XRDS.

More on XRDS

Making use of the XRDS

More to read...

CAPEC

Distributed Computing

People who like this blog will also like:

The quality of data is not strained

“The quality of data is not strained; It droppeth as the gentle rain from heaven Upon the place beneath. It is twice blessed- It blesseth him that gives, and him that takes.”– A bastardization of William Shakespeare.

Higgins IdAS and XDI

More on CardSpace and XRI

XDiggins

More Adoption

Another node in the XDI DataWeb

Week at the knees

Put a LID on it

I Want My Name Now

You should ph-off

More on OpenID

I-Names and OpenID

Link Contracts

XDI Workshop

YABP – Yet Another Blog Post.

GR Mapping

I fought the law...

Easy is Hard

let them go, and if they love you...