Friday, April 15, 2005
Another chance...
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
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
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.
Thursday, April 14, 2005
You only make a first impression once...
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.
Thursday, April 07, 2005
The P'u of XDI
What is P'u?
... I'm not even going to go there...
To me P'u is 'The Uncarved Block', 'something in its natural state'
Owen and I were talking about the what he called the 'Liquidity of Data'. This is something that we had both experienced; I call it the ultimate ACID trip, of course I mean ACID Transactions . It's when you are interacting with well structured data and suddenly you see the beauty and power that is unlocked in the interactions between the pieces of data (I said it was an acid trip). There is a whole industry that has grown around data mining that tries to unlock that power, that energy, it is generally accepted that it is a very valuable commodity. In the olden days, when I was young, data lived in dbase files. As a young database report writer I learned to respect a well crafted data model, I learned that if you modeled the data well; reports, knowledge, flowed out. I learned that trying to get meaningful reports out of poorly structured data was less than fun. Then, people understood that they needed to share data and move data from one repository to another. Those were hard times, moving 1meg over that 14.4 modem that would keep on dropping it's connection could take hours. And, how to structure the data so that the other people could use it? It was like running up the hill to the village with your water in a hand woven basket. Then XML came to save the day, all of a sudden we had real vessels to move the precious liquid, it was a plastic cup. Then the final touches SOAP, a plastic bottle with a screw on lid. Now you could move your data from one place to another without loss, knowing that anyone could receive it and understand it. This was cool.
But something happened, that ocean of data that spawned life, that ebbed and flowed, a medium we could swim in, was diminished. People thought well if XML / SOAP is so damn useful lets start using it everywhere. We can keep our data AS SOAP. So the image I have is this; imagine the ocean and it's richness, it's untapped potential. Imagine the same quantity of liquid in bottles sealed and stacked, static and dead.
The P'u of XDI is that data in it's raw form is a powerful thing. A call to XDI is a call to liberate data everywhere, throw off your chains and be free....
That was fun :-)
... I'm not even going to go there...
To me P'u is 'The Uncarved Block', 'something in its natural state'
One of the basic principles of Taoism is P'U, the Uncarved Block. The essence of
the Uncarved Block is that things in their original simplicity contain their own
natural power, power that is easily spoiled and lost when that simplicity is
changed - "The Tao of Pooh"
Owen and I were talking about the what he called the 'Liquidity of Data'. This is something that we had both experienced; I call it the ultimate ACID trip, of course I mean ACID Transactions . It's when you are interacting with well structured data and suddenly you see the beauty and power that is unlocked in the interactions between the pieces of data (I said it was an acid trip). There is a whole industry that has grown around data mining that tries to unlock that power, that energy, it is generally accepted that it is a very valuable commodity. In the olden days, when I was young, data lived in dbase files. As a young database report writer I learned to respect a well crafted data model, I learned that if you modeled the data well; reports, knowledge, flowed out. I learned that trying to get meaningful reports out of poorly structured data was less than fun. Then, people understood that they needed to share data and move data from one repository to another. Those were hard times, moving 1meg over that 14.4 modem that would keep on dropping it's connection could take hours. And, how to structure the data so that the other people could use it? It was like running up the hill to the village with your water in a hand woven basket. Then XML came to save the day, all of a sudden we had real vessels to move the precious liquid, it was a plastic cup. Then the final touches SOAP, a plastic bottle with a screw on lid. Now you could move your data from one place to another without loss, knowing that anyone could receive it and understand it. This was cool.
But something happened, that ocean of data that spawned life, that ebbed and flowed, a medium we could swim in, was diminished. People thought well if XML / SOAP is so damn useful lets start using it everywhere. We can keep our data AS SOAP. So the image I have is this; imagine the ocean and it's richness, it's untapped potential. Imagine the same quantity of liquid in bottles sealed and stacked, static and dead.
The P'u of XDI is that data in it's raw form is a powerful thing. A call to XDI is a call to liberate data everywhere, throw off your chains and be free....
That was fun :-)
Metrics For Success
Last night I was fortunate to see my friend and associate Gil Friend speak at the Commonwealth Club, it was inspiring. The topic of his speech was ‘THE STATE OF SUSTAINABILITY’, he spoke eloquently and passionately about how Big Biz can not only make a huge difference in the state of sustainability but MAKE MORE MONEY while they do it. Gil sited a couple of instances where, by changing the definition of success, companies have made more money while driving toward a greener goal:
DuPont used to manufacture and sell paint to the auto industry. The metric for success was ‘how much paint did we sell’, the more paint they could ‘push’ the better. As part of a drive to sustainability DuPont started to sell painting services to the auto industry instead of paint. Now every drop of paint wasted is money from the bottom line, the LESS paint used the better.
I think it was a Swedish shipping company that used to measure success by kg moved across km. That seems reasonable for a shipping company, the more stuff they move, the better they are performing their business, but then, they changed their metric. They made a decision to be more sustainable and changed their metric for success to $ (krona) of profit per liter of gas. More money good, less gas good. They now act as a logistics firm helping companies make sure that they have what they need, where they need it, when they need it, in the most efficient way. After all, that is what companies need, they don’t want to buy ‘shipping’ they just need their stuff in the right places.
So my point… How can I change my basic definitions of success to change my behavior? That isn’t a rhetorical question, please send answers to…
DuPont used to manufacture and sell paint to the auto industry. The metric for success was ‘how much paint did we sell’, the more paint they could ‘push’ the better. As part of a drive to sustainability DuPont started to sell painting services to the auto industry instead of paint. Now every drop of paint wasted is money from the bottom line, the LESS paint used the better.
I think it was a Swedish shipping company that used to measure success by kg moved across km. That seems reasonable for a shipping company, the more stuff they move, the better they are performing their business, but then, they changed their metric. They made a decision to be more sustainable and changed their metric for success to $ (krona) of profit per liter of gas. More money good, less gas good. They now act as a logistics firm helping companies make sure that they have what they need, where they need it, when they need it, in the most efficient way. After all, that is what companies need, they don’t want to buy ‘shipping’ they just need their stuff in the right places.
So my point… How can I change my basic definitions of success to change my behavior? That isn’t a rhetorical question, please send answers to…
Tuesday, April 05, 2005
Personal Server
The current XDI Server is what I consider the start of a "Community XDI Server" it's based on the J2EE servlet framework with 'axis' providing a SOAP Web Services interface. It is designed and built to handle a large volume of data and traffic, it needs robust server grade hardware to support it. I hope that we will see a PHP (LAMP) version of XDI Server soon that may offer an easier entry point for not-for-profit and NGOs. We may even look into a C/C++ version for really high end commercial use.
This post is about the other extreme; the XDI Server that will run on your desktop, your phone, your PDA, your watch?. This server needs to be very light weight and run as a stand alone app. It will be your messaging client, your calendar, your blog reader, file storage interface, your Personal Productivity Dashboard. You will generate content of any type; document, image, movie, song and in a single action do any of these that you wish:
This post is about the other extreme; the XDI Server that will run on your desktop, your phone, your PDA, your watch?. This server needs to be very light weight and run as a stand alone app. It will be your messaging client, your calendar, your blog reader, file storage interface, your Personal Productivity Dashboard. You will generate content of any type; document, image, movie, song and in a single action do any of these that you wish:
- Save it.
- Publish it.
- Put into a Knowledge Management System (tag it).
- Notify others that it is published.
- Back it up.
- Secure it.
- Assert ownership over it (I'm working on evaluating some newly patented watermarking technology that may have some teeth)
Because XDI is inherently distributed and interoperable this doesn't mean that we/you are building some monolithic repository that must hold all data, it simply enables a single point of reference for all that data. Your calendar data will still be kept in whatever you already use, your rich media will go to your ourMedia.org account.
You will use your person server to share your data with only the people you want to share it with and otherwise secure it. You will use your personal server to control access to you; when someone types your i-name into their cell phone, do they get your home phone, your cell phone or voice mail? You configure who, when, where and how. That works for email too and rss consumption. Maybe one day FedEx will be i-name enabled so you can have your package delivered to where you are when you are there.
XDI'm OK, You're OK
According to Amazon "I'm OK, You're OK", written by Thomas A Harris (1967);-
I haven't got a clue what transactional analysis used to mean but now it means that someone is watching all my transactions, analyzing them then selling them for their own gain. XDI is about "gaining control of yourself, your relationships and your future, no matter what has happened in the past."
Another reason I like the I'm OK, You're OK analogy is that XDI is about interoperability; if you are using LID, LDAP, FOAF, SXIP, XRI/XDI it doesn't matter, they should all work together, they are all OK. They all have different strengths and weaknesses but should be able to work together to give us all the control we desire in our futures. This isn’t some hippy dippy idealistic dream, this is the reality of our success or failure, collaboration and competition are the driving forces that will keep us focused and innovating.
Synopsis: A guide to transactional analysis. In non-technical language, it
offers advice on gaining control of yourself, your relationships and your
future, no matter what has happened in the past.
I haven't got a clue what transactional analysis used to mean but now it means that someone is watching all my transactions, analyzing them then selling them for their own gain. XDI is about "gaining control of yourself, your relationships and your future, no matter what has happened in the past."
Another reason I like the I'm OK, You're OK analogy is that XDI is about interoperability; if you are using LID, LDAP, FOAF, SXIP, XRI/XDI it doesn't matter, they should all work together, they are all OK. They all have different strengths and weaknesses but should be able to work together to give us all the control we desire in our futures. This isn’t some hippy dippy idealistic dream, this is the reality of our success or failure, collaboration and competition are the driving forces that will keep us focused and innovating.
I link therfore I am.
I was asked this question via email but thought I would answer here so that you can correct me.
Aldo Castaneda the watcher and documentor of the developing identity standards wrote:
At the Authority Level a Link mostly represents 'Membership' @ootao*aldo would indicate that Aldo is a member of the ootao community. @ootao*aldo*andy has Andy as part of Aldo's community in the context of ooTao.
At the Type Level Links represent Complex Types (I am going to write up a doc about XDI Dictionaries that will cover this ground) (+address*(+street)), (+address*(+city)), (+address*(+state)) and so on is a way of indicating that street, city and state are connected to make a larger type; address ( the dictionary definitions should indicate that while there may be 1 or 2 (+address*(+street)), there should only be 1 (+address*(+city)) for a given instance of +address).
At the Instance Level Links seem to be used for unstructured aggregation (aggregation not defined in the Dictionary) for example Link from the (@ootao) instance of (+biz.card) to an instance of (+email), (+phone) and (+title). From the (@natural.logic) instance of (+biz.card) I would link to a different combination of data. By not associating this at the Type level I have no constraints of the data structure.
Across all levels Links may be given synonyms that are $words (system words) these '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.
Aldo Castaneda the watcher and documentor of the developing identity standards wrote:
By the way I read "XDI-Universal-Graph Primer" with interest. One basic question for you:So the easy bit first, yes, the * always denotes a Link Node (which is represented either by the Red Dot or by a Green Line). It is also true to say that a Link is always a delegation of authority for a given section of the graph. But, I am finding that that description falls short of describing the richness of interactions that Links enable. At the different levels of the graph the Link represents a different thing;
In the notation that reads -> xri://@ooTao/(+Contact)/email*(=Andy/(+Email)/work)
Does the "*" stand for the Red Dot (Link Node)? And is a Link Node necessarily a delegated authority?
At the Authority Level a Link mostly represents 'Membership' @ootao*aldo would indicate that Aldo is a member of the ootao community. @ootao*aldo*andy has Andy as part of Aldo's community in the context of ooTao.
At the Type Level Links represent Complex Types (I am going to write up a doc about XDI Dictionaries that will cover this ground) (+address*(+street)), (+address*(+city)), (+address*(+state)) and so on is a way of indicating that street, city and state are connected to make a larger type; address ( the dictionary definitions should indicate that while there may be 1 or 2 (+address*(+street)), there should only be 1 (+address*(+city)) for a given instance of +address).
At the Instance Level Links seem to be used for unstructured aggregation (aggregation not defined in the Dictionary) for example Link from the (@ootao) instance of (+biz.card) to an instance of (+email), (+phone) and (+title). From the (@natural.logic) instance of (+biz.card) I would link to a different combination of data. By not associating this at the Type level I have no constraints of the data structure.
Across all levels Links may be given synonyms that are $words (system words) these '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.
Saturday, April 02, 2005
Control Freak
Drummond always loves it when I randomly decide to add another system word... well here I go again... (the title of this post is about the system words not about Drummond!!)
We have been going back and forth for a while about the behavior of the link contracts when the underlying permissions are changed. If I give you additional access to a new piece of data, should that invalidate the contract that you have already signed? What if I remove your access to piece of data?
If each change does invalidate the contract we are going to end up with a
So we decided to support both options; If the instance of a $policy has a synonym “$RequireSignedRightsPaths” then the rights paths will be signed as part of the contract. Any changes to your permission set will therefore invalidate the contract. In the absence of this synonym you will only sign the policy itself and the permissions can change at the authorities will. This has been added to the primer.
Given that most policies should be standard and don’t actually care what the specific data that is being shared is this should work fine.
How much is too much?
James Kobielus' Blog: fyi Databases Can't Handle RFID
Can a massively distributed data architecture like the ‘Dataweb’ as we conceive of it support masses of data? I guess we’ll find out. I do know that 5 years ago the idea that I would have a 300gig drive in my $800 PC would have seemed not only unlikely but also unneeded. If that 7 million terabytes of data that Wal-Mart Stores Inc was generating each day was spread across the data repositories of the people who executed the transactions what would the spread be? I’m not being glib… these are my real first thoughts on what is clearly a huge question.
But then... It is probably true that XDI 1.0 will not solve all of the problems in the data sharing world including this 'massive' data question. But massive distribution will certainly help and it will solve a lot of other problems.
Friday, April 01, 2005
The Authorititive Voice
I want to make sure that you know that all this stuff I spout is just MY OPINION. There is no XDI Spec yet, I'm sure that others on the TC would not agree with all my opinions (that's why we have the TC process). The stuff that I put out may be TOTALLY WRONG!! I hope not, I don't think it is but it might be.
Anatomy of a Rights Path
Geek Out:
What is a "Rights Path" ? It's a booklet on Aboriginal Human Rights .
but to me it's;
The address that a single entity (individual, organization, service, bot) can use to access data that has been made available to them that is under another entities authority. A Rights Path is a cross between an 'ability' and a data query. It's a query that only one specific entity can execute.
See Rights Paths 101 doc for more.
What is a "Rights Path" ? It's a booklet on Aboriginal Human Rights .
but to me it's;
The address that a single entity (individual, organization, service, bot) can use to access data that has been made available to them that is under another entities authority. A Rights Path is a cross between an 'ability' and a data query. It's a query that only one specific entity can execute.
See Rights Paths 101 doc for more.
$Public speaking
Geek Moment:
For months now I have been saying that the $public instance of the $contract provides a mechanism to permit anonymous access to your data. I was wrong...
A $public instance of $link should be the access point.. It'll be in v4 of the primer.ppt
For months now I have been saying that the $public instance of the $contract provides a mechanism to permit anonymous access to your data. I was wrong...
A $public instance of $link should be the access point.. It'll be in v4 of the primer.ppt
Subscribe to:
Posts (Atom)
