A Network Centric Design For Relationship Based Rights Management (Tin180 Com)

958 views

Published on

Online Documentation: Socical Media and Internet Trend (http://tin180.com)

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
958
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • In this talk, I describe work done as part of my PhD thesis at Stanford as part of the Digital Library Project. It is overall about the question about how to deal with security and access control--or “rights management”--in an environment such as the Internet.
  • Over the past couple of years, we have seen how a technical infrastructure--the Internet--has been pulled into the mainstream with usages for which it was never originally designed. This has created what can be called a mismatch in languages. On the one hand we have a lot of social policies about access control, security, privacy, etc. that now apply to this new environment. On the other hand, the current technical infrastructure provides only minimal support in dealing with the kinds of policies that people would like to express. For example, a Web server generally only know the requester’s IP address; but it is not clear whether the requester is a student who qualifies for a student discount or whether it is just the infamous dog on the Internet that is so happy that no-one knows about its status. In other cases, we do have a rights language in the technical infrastructure but its terms turn out not to be meaningful in a larger sense. For example, when I look at the files on my machine at Stanford, the Unix file system tells me that I am the owner of the source code of the complete Digital Library testbed. But of course, this is just because what Unix calls an owner is really just some form of a possessor. But these distinctions didn’t matter that much when Unix was originally designed, and therefore such short-cuts now appear as a mismatch in language.
  • Digital rights management comes then into play here basically as a way of bridging this gap by augmenting the technical infrastructure to allow for a more structured mapping between - terms provided by the infrastructure and - policies that one might want to expres, or - structures that the legal framework uses.
  • Architecturally, this next-generation infrastructure is basically a set of service protocols that are layered on top of the existing network protocols. Specifically, my work is here about FIRM--a service layer for rights management. FIRM makes use of other protocols such as the DLIOP and UPAI protocols developed as part of the Stanford project to provide services for dealing with collections and payment, respectively. In this talk, I will also often refer to RManage--which is my sample implementation of the FIRM protocol. RManage augments services such as Web servers by a component that allows these services to make use of the FIRM service layer. RManage also provides implementations for the kinds of person and contract objects that FIRM assumes --and on the user interface side, FIRM services can either be used with a plain Web browser or integrated into DLITE, the interface viewer developed by Steve Cousins as part of the digital library project.
  • At first an example that could be a talk in itself: network security. Network security has been traditionally cast in a protection framework rather than a relationship management framework. An instance of this is the castle model that underlies current firewall technology. Security firewalls basically take the organizational boundaries of a traditional company and cast a wall around it--to protect the inside from the outside. The wall has then certain controlled entry points where it is controlled what can get in and what can get out. Of course, relationships in modern companies don’t line up quite as neatly with organizational boundaries as it used to be the case; see here. Today, especially in virtual companies, it is becoming less obvious where to draw the firewall boundary and what it is supposed to protect--since the assets are not as much inside the castle, but in the relationships and the partners. The current approach is basically to continue in the old paradigm and just build smaller and smaller castles, and then connect them by tunnels (so-called Extranets) (see the grey boxes here). Of course, the relationships themselves still cut across these security boundaries, and each them this is the case, we generally get usability hassle, reduced security, or any other kinds of transaction costs. Based on its network-centric design for contracting, RManage on the other hand allows us to shift the perspective entirely into a relationship view. We uniformly use the contracting infrastructure to manage relationships, as the ancillary of which we then obtain genuine relationship-based security. I have depicted this here like this, with the red boxes representing commpacts that provide the security for a certain relationship. Note that such a radical shift wouldn’t be possible without same relationship infrastructure.
  • In summary of this first-level infrastructure: We have a computational representation of contracts that lines up that directly uses contract law ideas to guide their structure. These contracts are smart contracts that include enforcement behavior. Furthermore, we have an extensible system of contract “forms” that can enable end-users to easily draft new contract offers. And then we have a flexible underlying architecture to manage this control information in a networked environement. In other words, we have the toolbox that we were looking for; and we have enabled computational interactions.
  • Following the FIRM specification, we can now implement and instantiate computational contract objects. I usually call them commpacts with a double m, or also “smart contracts”. Pardon me the word "smart" here--it is not intended to suggest any kind of artificial intelligence, but it is used here in the same way as in the phrase “smart card”--basically to emphasize that the contracts that we are talking about here are: structured interface, code that implements behavior, state, and then also a set of textual descriptions. The piece of text by which we usually know contracts is only the result of one specific method call to the commpact (GetDescription). But the structured interface also provides for a whole set of other methods--negotiation messages such as Terminate, and authorization functions such as ExerciseRight, etc.
  • At this point, just one more observation: [ADD RED] 1. How does a basic authorization fit in here? Since Tim has a site license here that allows him to access this book here, an access would be authorized in the following way: Tim would send a request to the online book that includes which contract to use; the book at the Web server would then simply use the designated commpact as an authorization monitor, obtain authorization, and return the content of the book.
  • A lot of effort in my thesis has gone into working out the following enabling architecture which I describe here in one slide: … an architecture in which control objects (the commpacts) are managed independently of the objects they control. Commpacts can in principle reside anywhere on the network, at any of a number of commpact managers. In other words, rather than attaching control information as meta-information to information objects, we have control information encapsulated into first-class objects that stand in a flexible n:m relation with the objects they control. For example, we can have one subscription commpact that applies to a whole range of content objects; and vice verse, we can have one and the same content object, that is governed by more more than one controls. That means, we do not need to replicate the control information with every controlled objects; we just have a pointer to the control information, and vice versa. This gives us a lot of flexibility--we can independently deliver control and content objects; we can independently modify them, etc. Cryptographic means are then used to ensure that this flexibility does not end up being an “anything goes”.
  • E-persons are electronic representations of persons. The idea is that users articulate basic preferences; and then the e-person executes the corresponding FIRM protocol actions automatically on behalf of them. A specific human person can have more than one e-person. E-persons exist also for organizational roles, etc. By this type of agency relationship, we can hide the FIRM transaction complexity almost entirely to users; most of the messages will just be between the e-person and servers--only in some cases will the e-person get back to the user directly.
  • As a second example, consider a contract-based approach to privacy. Privacy is a balancing act that is intrinsically relationship-based. For example, when going into a shoe store to buy a pair of shoes, few people would resist telling their shoe size when asked by the merchant--simply because volunteering your shoe size makes the shoe shopping experience obviously much more pleasant. The question now is how the same would work in an online environment. How do I tell my Web browser that it is ok to send along the shoe size when I look at a virtual shoe store, the ZIP code when I look at a weather site, the e-mail address at certain other sites, etc.--all preferably without that I have to approve it explicitly every time or without any other kind of usability overhead. To enable such usages, we’ll add e-persons to the infrastructure.
  • RManage provides a simple interface that allows users to programtheir e-person--meaning they can indicate which types of offers should be automatically accepted and which types of obligations should be automatically fulfilled. For example, in this screenshot here I agree to all user profiling contracts if they only involve a basic set of personal attributes and if they are adminstered by a certain service. I accept site registrations if my e-mail is not used, etc. And I set it up such that payment obligations are automatically fulfilled if it is a pay-per-view use for less than $5 or if it is from a subscription that I previously agreed to.
  • How does this look like then. Well, consider the user is going to a weather site the first time. We have one such site running experimentally based on the site of the weather underground. Then a.) the local weather would show up right away, and b.) we have an augmented log that indicate the contract that this user used to access the pages. There is also any number of anonymous users--since the same Web server can also be used in the old-fashioned way. In other words, having available some basic user attributes changes the way of organizing information: Rather than organizing the interaction design of a weather site around different ways of finding one’s geographic notion (such as the typical click country--click state--click city), we will now orgnize the site that local weather first, and then pointers to the other areas.
  • Finally, let me just run through quickly a couple of transaction examples. First let’s consider the simple case that there a relationship already exists. ooo
  • First note that if… commpact with server will be typical case.
  • for usage control; low interactivity better on client machine also in mobile case, this is necessary
  • How do we do this ? Well, basically we just go through a couple of contract law course outlines and decide for each item how it makes sense to reflect it computationally. Here’s a very simple example, just to give a sense of the structures. A subscription is basically a set of two promises, say, an access right and a payment obligation. The contract becomes effective once both parties agreed to it and the precedent condition is satisfied (here: the subscriber’s student status). Even if the contract is already effective, specific promises in it might not be so yet--in case its promissory condition is not satisfied, and so on. And then we basically map such structure into a formal specification ->
  • How do we do this ? Well, basically we just go through a couple of contract law course outlines and decide for each item how it makes sense to reflect it computationally. Here’s a very simple example, just to give a sense of the structures. A subscription is basically a set of two promises, say, an access right and a payment obligation. The contract becomes effective once both parties agreed to it and the precedent condition is satisfied (here: the subscriber’s student status). Even if the contract is already effective, specific promises in it might not be so yet--in case its promissory condition is not satisfied, and so on. And then we basically map such structure into a formal specification ->
  • For example, FIRM would specify then that a contract is a rights object that has an accept message, that has a set of promise objects, etc. A promise object can be exercised; it has a promissory condition, etc. And one of the subtypes of a promise object is an obligation object, with additional methods, to be able to set the time of fulfillment, etc. Note that not everything is reified of course. For example, there is a concept called “silent acceptance” by which basically the failure to reject an offer already counts as an acceptance; or there are also so-called “unilateral contracts” that can be accepted by merely fulfilling a promise (rather than by first separately accepting the offer). My sense has been that such issues were primarily incorporated by the legal framework in order to deal more smoothly with certain practical short-cuts. But in an online environment, the cost benefit of such short-cuts is a fairly minor one of course--especially relative to the cost of dealing with the additional ambiguity that they would create. And therefore those were the kinds of issues that I have usually chosen not to reify, meaning, in the examples, we would just send that extra accept message in the protocol just to be clear about it.
  • [want: hassle to subscribe; application-centered, not user-centered----no way to terminate; just list of my contracts--ideally directly in Quicken; way to terminate them directly] At this first level, let us see how we can support contracts in the technical infrastructure. Consider that currently on the Web, there are probably hundreds of different ways in which one can subscribe to a site. Everyone is doing it in a little bit a different way. In some cases they tell you the terms and conditions; in others they don’t. In some cases, they provide a way to terminate the agreement; in others, they don’t, etc. The point about such user interface heterogeneity is that it is basically unnecessary and confusing. Providing yet another way to subscribe to a site is not the kind of feature that any site cares to differentiate itself about. Moreover, the lack of structure is particularly reflected at the computational level, meaning for instance that there is no structured way for a program to inspect the terms and conditions of different offers; for example, how could a program like Quicken integrate contract management [rather than getting e-mail message--directly tell Quicken], etc. Approach used here: Move commonalities into shared infrastructure and provide a toolbox that makes it easy to follow structure. For rights management, what we take here as the common denominator is effectively contract law: since contract law is really nothing else than a body of generic principles that exactly identifies the shared structure between different rights relationships. We will therefore map its principles quite carefully into the online domain (“reify them”).
  • An important structure in RManage is the so-called “notifier”. The notifier is a single point of reference for all kinds of things that need to be brought to a user’s attention. For example, the notifier will tell me which obligations are due, etc. Here I have two payment obligations in my notifier, one notification obligation and one approval request. The first payment obligation and the notification obligation are schedule for automatic fulfillment--an issue that we will look later in more detail. In the notifier, I can follow the links to inspect more detail about an item, and I can also directly execute certain actions here--linked to the specific type of the item.
  • Secondly, how do we incorporate domain-specific actions such as payment ? Well, basically since it is domain-specific, it will also be dealt with by domain-specific implementations. In other words, it is up to the specific implementation of the payment obligation. RManage for example simply leverages the UPAI payment application program interface. Whenever an RManage payment obligation receives a fulfill request, it initiates a payment request to the payment module, which itself then talks the native payment protocols. And, once the payment transfer is completed, the payment obligation receives a message that declares it to be fulfilled.
  • First, how do we enforce predicates such as one’s student status based on the proper affiliation rather than based on guesses made indirectly based on one’s browser’s IP address ? Basically, the story is that we leverage the same kind of infrastructure that is also used for evaluating search queries. In other words, there is an interface such as the one shown in the screenshot to the left here, where offerors can fill in a constraint--here a promissory condition that says that the affiliation of the promisee must be Stanford. In FIRM, this constraint will be a separate object with methods such as ‘CheckCondition’. Then the constraint object uses proxies to local resources to infer the predicate. In terms of the search infrastructure, the RManage prototype simply uses the one of the Stanford Digital Library Project--but FIRM itself is really independent of this and any other attribute infrastructure can be used.
  • Let us now look at all of this from the user’s perspective. How would a user be able to set up a new contract, offer it to others, etc. RManage makes it easy to draft new contracts by reducing the authoring process to that of finding and selecting a so-called contract “form” and then simply filling in fields, etc. This slide here shows to the left a screenshot of the RManage viewer implemented using the DLITE toolkit. This interface basically provides direct-manipulation access to contracts, contract forms, obligations, etc. A user can create a query and search for contract forms that are related to some type of relationship. In this case here, by dropping the query on the Stanford forms provider I have obtained a result collection with four different forms that are applicable. By clicking on any of the forms I can read more details about it in the Netscape window. This will give me a general description about what contracts based on this form are like, etc. Once I found a form that I like, I can just select it and what I get is a draft where I can fill in specific fields ..
  • In the draft, a number of fields are already automatically filled in--for example the fact that I am one of the contract parties [I can also switch the contract role by clicking on the switch button] I can fill in a constraint that describes what this contract is about--here the Dialog service, etc. I can manually declare it an offer by clicking here; I can read a summary description of the promsies, here a search right that allows me 5 searches until it requires me to have done the first payment, and a flat fee payment obligation. And I can follow the various links to inspect more details… For example, I can look at the payment obligation...
  • In the payment obligation, I can fill in a range of options--including last not least the amount of it--here 300 dollars.
  • A Network Centric Design For Relationship Based Rights Management (Tin180 Com)

    1. 1. A Network-Centric Design for Relationship-based Rights Management Martin R ö sch eisen, Terry Winograd Stanford Digital Library Project Computer Science Department Stanford University PowerPoint Template Design: Andreas Paepcke
    2. 2. A Mismatch in Languages Technical Infrastructure “ Web browser’s IP address” “ Owner of Unix file” “ owner” “ possessor” “ ...for US citizens” “ ...for students” “ Employees…” “ contract” “ obligation” ? ? Social/Legal Framework ?
    3. 3. Bridging the Gap with Rights Management Infrastructure Technical Infrastructure “ owner” “ possessor” “ ...for US citizens” “ ...for students” “ Employees…” “ contract” “ obligation” “ Owner of Unix file” “ Web browser’s IP address” Social/Legal Framework Rights Management
    4. 4. Current Solutions Control Example Systems Server-based Client-based Third-party PageMaker license server expiring demo copies; trusted clients [Stefik] file systems, HTTP ACLs; security firewalls <ul><li>Disparate set of protocols (special-purpose, proprietary, …) </li></ul><ul><li>More uniformity? Interoperability? </li></ul>
    5. 5. Enforcement Choices <ul><li>Not only “technical locks” </li></ul><ul><li>But also: </li></ul><ul><ul><li>Police/courts </li></ul></ul><ul><ul><li>Prevention </li></ul></ul><ul><ul><li>Fail-safe </li></ul></ul><ul><ul><li>Monitoring </li></ul></ul><ul><ul><li>Reputation-based </li></ul></ul><ul><ul><li>“ Panoptic” </li></ul></ul><ul><li>Programmable framework that allows use of most appropriate enforcement? </li></ul>
    6. 6. Overall Objective <ul><li>“ Open standards” rights management service layer that </li></ul><ul><ul><li>unifies rights management protocols </li></ul></ul><ul><ul><li>accommodates </li></ul></ul><ul><ul><ul><li>legacy systems </li></ul></ul></ul><ul><ul><ul><li>current heterogeneity of trust </li></ul></ul></ul><ul><ul><ul><li>spectrum of enforcement options </li></ul></ul></ul><ul><ul><ul><li>institutional distribution </li></ul></ul></ul>
    7. 7. Towards a Rights Management Service Layer RManage components FIRM: Framework for Interoperable Rights Management RManage: prototype implementation of FIRM FIRM rights management service layer DLIOP -- items, collections UPAI -- payment API IIOP/CORBA HTTP COM TCP/IP “ Infobus” FIRM-enabled Services DLITE viewer Web browser E-persons Contracts ... FIRM-ready Clients
    8. 8. Overall Approach: Relationship-Centric <ul><li>Support relationship management </li></ul><ul><li>Realize security, privacy, … as ancillary of it </li></ul>… rather than content/property-centric
    9. 9. Example: Relationship-based Network Security Manufacturing Partner Traditional Company Relationships in the 90’s Castle Model of Security Clients Janitor Distributor Contractors Perspective Shift to Relationship-based Security Castles + Tunnels Inside Outside Firewall Clients Organizational Boundary Employees
    10. 10. Goals <ul><li>Relationship management framework </li></ul><ul><li>Architecture for managing relationships </li></ul><ul><li>Domain extensibility, interoperability </li></ul><ul><li>Usability </li></ul><ul><ul><li>Hide transactional complexity </li></ul></ul><ul><ul><li>Ease of authoring </li></ul></ul>
    11. 11. Design Space Simple Structured Complexity Static Dynamic Lotus Notes most “e-commerce” technologies firewalls Dynamics Relationship
    12. 12. Conceptual Framework <ul><li>Communication model </li></ul><ul><li>Communication participants </li></ul><ul><ul><li>negotiate boundary conditions </li></ul></ul><ul><ul><li>externalize them in “communication pacts” </li></ul></ul><ul><li>Actions performed and evaluated with respect to actor-designated commpact </li></ul><ul><li>Details: drawn from contract law </li></ul>
    13. 13. Commpacts <ul><li>Computational relationship objects,“smart contracts” </li></ul><ul><li>FIRM interface + Code + State + Text </li></ul><ul><li>Authorization function </li></ul>Commpact GetDescription Site License The following parties agree to the conditions GetPromises [Promise1] Terminate status: valid count: 4 ExerciseRight GetSearchCount
    14. 14. Tim: Retrieve book using my site license ! Authorized? OK. Tim’s Site License Book Lexicon Web server Commpacts as Authorization Monitors Tim’s PayPerUse Commpact Commpact Tim
    15. 15. Managing Commpacts: Network-Centric Architecture <ul><ul><li>Commpacts are </li></ul></ul><ul><ul><li>interpreted at “commpact managers” anywhere on the network </li></ul></ul><ul><ul><li>managed independently of controlled objects </li></ul></ul>Martin’s Subscription Commpact Manager Steve’s PayPerUse Commpact Manager Tim’s Site License Book Newsletter Journal Lexicon Web server Article Article Article Article Server
    16. 16. E-persons <ul><li>Current person representations: disparate </li></ul><ul><ul><li>e.g. Unix account, browser profiles, LDAP, etc. </li></ul></ul><ul><li>Have object that uniformly represents (roles of) persons: “e-person agent” </li></ul><ul><ul><li>Users articulate basic preferences e.g. Auto-Accept, Auto-Fulfill </li></ul></ul><ul><ul><li>E-person executes FIRM protocol actions </li></ul></ul>Server Client Get Result FIRM rights protocol delegate Tom’s e-person Tom
    17. 17. Example: Contract-based Approach to Privacy <ul><li>What shall Web browser tell a server about you ? </li></ul><ul><ul><li>Today: all-or-nothing </li></ul></ul><ul><ul><li>Want: case-by-case, depending on relationship </li></ul></ul><ul><li>For every new server: How can users determine relationship and negotiate contract ? </li></ul><ul><ul><li>...without usability overhead ? </li></ul></ul>weather site shoe store Browser ZIP: 94305 Shoe size: 9
    18. 18. RManage View: Setting Up E-Person Preferences
    19. 19. Example: Personalized Content <ul><li>FIRM-enabled Web server: </li></ul><ul><ul><li>Directly gets local page </li></ul></ul><ul><li>Conventional Web server: </li></ul><ul><ul><li>Gets “Pick country” page </li></ul></ul>User accesses weather site… Information organized around geographic navigation country state city
    20. 20. Under the Hood: Transactions E1: Exception; Get offerors E2: List of offerors N1: Get offers N2: List of offers N3: Accept subscription N4: Accepted E1,2 N3,4 N1,2 Server Client 2 5 4 3 Tom’s E-person UserProfiling Offer Tom 1: Request: e.g. HTTP 2: Which commpact to use ? 3: Use profiling commpact 4: Request to authorize 5: Authorization Decision 1: GET index.html 6: Result Mike’s E-person Case: Establishing a new relationship [Auto-Accept]
    21. 21. <ul><li>Case: Pre-existing relationship [no network caching] </li></ul>Server Tom’s E-person 1: GET index.html 2 1: Request: e.g. HTTP 2: Which commpact to use ? 3: Use profiling commpact 4: Request to authorize 5: Authorization Decision Tom’s UserProfiling Commpact 5 4 3 Tom 6: Result Client Under the Hood: Transactions
    22. 22. <ul><li>Case: Pre-existing relationship [no network caching] </li></ul><ul><li>Specialization: HTTP Access Control scheme </li></ul>Under the Hood: Transactions like HTTP auth exchange like HTTP server authorization Server Client 2 5 4 3 Tom’s E-person Tom’s UserProfiling Commpact Tom Web browser Web server 1: GET index.html 6: Result 1: Request: e.g. HTTP 2: Which commpact to use ? 3: Response: Use subscription 4: Request to authorize 5: Authorization Decision
    23. 23. Under the Hood: Transactions Doc Server Client 2 5 4 3 Tom’s E-person Tom’s UserProfiling Commpact Tom 1: GET index.html 6: Result Case: Pre-existing relationship [no network caching] Specialization: Case for usage control, mobile case 1: Request: e.g. HTTP 2: Which commpact to use ? 3: Use profiling commpact 4: Request to authorize 5: Authorization Decision
    24. 24. <ul><li>Case: Pre-existing relationship [no network caching] </li></ul><ul><li>Specialization: Rights clearing house case </li></ul>Under the Hood: Transactions Server Client 2 5 4 3 Tom’s E-person Tom’s Commpact Tom 1: GET index.html 6: Result Third Party e.g. CCC 1: Request: e.g. HTTP 2: Which commpact to use ? 3: Use Tom’s commpact 4: Request to authorize 5: Authorization Decision
    25. 25. Transactional Efficiency <ul><li>Simple cases are simple in FIRM. </li></ul><ul><ul><li>often faster than HTTP authorization </li></ul></ul><ul><li>Complex ones are uniformly possible. </li></ul><ul><ul><li># of messages scales with intricacy of negotiation </li></ul></ul>Server Client E-person fast Home/ modem ISP/ backbone ISP/ backbone
    26. 26. Trust Management <ul><li>Architecture accommodates people’s varied trust preferences </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Trust every site: </li></ul></ul><ul><ul><ul><li>Commpact can be anywhere on network </li></ul></ul></ul><ul><ul><li>Trust only one’s own server </li></ul></ul><ul><ul><ul><li>Keep commpact local [traditional access control] </li></ul></ul></ul><ul><ul><li>Trust specific third party </li></ul></ul><ul><ul><ul><li>Have commpact managed by third party ... </li></ul></ul></ul>
    27. 27. Domain Extensibility and Interoperability <ul><li>FIRM: Framework for Interoperable Rights Management </li></ul><ul><li>Carefully separate generic from specific info: e.g. </li></ul><ul><ul><li>fact that contracts have rights and obligations vs. </li></ul></ul><ul><ul><li>right to print at 300dpi resolution </li></ul></ul><ul><li>Two-level specification [“like MIME”]: </li></ul><ul><ul><li>Generic interoperability specification </li></ul></ul><ul><ul><li>Format for contributing domain-specific “rights vocabularies” </li></ul></ul>
    28. 28. FIRM Interoperability Spec <ul><li>Reification of generic contract law concepts </li></ul><ul><li>Object interfaces for </li></ul><ul><ul><li>commpacts </li></ul></ul><ul><ul><li>promises (rights and obligations) </li></ul></ul><ul><ul><li>e-persons </li></ul></ul><ul><ul><li>conditions (precedent, subsequent) </li></ul></ul><ul><ul><li>constraints </li></ul></ul><ul><li>Interactions: </li></ul><ul><ul><li>negotiation </li></ul></ul><ul><ul><li>performance (authorization, etc.) </li></ul></ul><ul><li>CORBA IDL interface spec; protocol spec </li></ul>
    29. 29. Domain Extensibility : FIRM Object Attribute Models Incorporate domain-specific information Based on Stanford meta-data framework SimpleSearchRightModel = { Attr1 = { Name: ‘ searchBudget ’ ValueType: ‘ CARDINAL’ Documentation: ‘Number of searches allowed’ } Attr2 = { Name: ‘ searchCount ’ ValueType: ‘ CARDINAL’ Documentation: ‘Number of searches performed’ } } ItemizedSearchRightModel:: SimpleSearchRightModel = { Attr3 = { Name: ‘ searchHistory ’ ValueType: ‘ SEQUENCE OF RECORD time: TTime, resultSetSize: CARDINAL END’ Documentation: ‘ History of searches that have been successfully completed so far’ } }
    30. 30. RManage: A Prototype “Relationship Manager” App <ul><li>Python/Java implementation of FIRM </li></ul><ul><ul><li>completed 1/97 </li></ul></ul><ul><li>Developed as part of Stanford DL Project </li></ul><ul><li>Experimental digital contracts for </li></ul><ul><ul><li>Knight Ridder’s Dialog Service </li></ul></ul><ul><ul><li>Xerox’ text summarizer </li></ul></ul><ul><li>Prototype authorization plug-in for Web server </li></ul><ul><ul><li>privacy negotiation [weather, advertising] </li></ul></ul>
    31. 31. Example: Managing Subscriptions <ul><li>Currently: Application-centered, disparate </li></ul><ul><li>RManage: User-centered & integrated </li></ul>Browser Web Server Quicken e.g. WSJ Subscriber Database Payment Processing passwords “ cookies” checks, ... Subscription Contract Mail: Invoice FAX: Student ID
    32. 32. Terminate Keep me out of the loop here -> E-person Control Panel RManage: Sample Affordances Details What’s new ? -> Notifier view Show my current relationships
    33. 33. RManage View: Contract
    34. 34. RManage View: Notifier
    35. 35. Linking in Fulfillment Actions <ul><li>Example: Initiate actual payment transfer </li></ul>Payment Obligation FIRM: Fulfill Payment Module e.g. UPAI Pay $300 to [email_address] native payment protocols FIRM: DeclareFulfilled bank, etc.
    36. 36. Constraint Checking <ul><li>Example: “Student status required” </li></ul><ul><ul><li>enforced directly based on attributes </li></ul></ul><ul><ul><li>evaluated using same infrastructure as for search queries (Infobus proxies to local services) </li></ul></ul>Right Exercise Constraint Check Condition Stanford Whois Proxy DLIOP
    37. 37. Authoring Support: Forms <ul><li>How do you draft a new contract </li></ul><ul><ul><li>… if commpacts contain so much behavior? </li></ul></ul><ul><li>Allow sharing and reuse </li></ul><ul><ul><li>Commpacts based on “forms” </li></ul></ul><ul><ul><li>Extensible, distributed system of forms </li></ul></ul><ul><ul><ul><li>Forms provider provide forms </li></ul></ul></ul><ul><ul><ul><li>Users customize and use forms. </li></ul></ul></ul>
    38. 38. <ul><li>… as user’s starting point </li></ul><ul><li>Just find and select a form (“smart stationery”) </li></ul><ul><li>Then fill in fields, etc. </li></ul>Creating New Contract: “Forms”
    39. 41. Goals Revisited <ul><li>Framework for relationship management </li></ul><ul><ul><li>communication model, commpacts </li></ul></ul><ul><li>Architecture </li></ul><ul><ul><li>“ network-centric” commpact management </li></ul></ul><ul><li>Domain extensibility, interoperability </li></ul><ul><ul><li>two-level FIRM specification </li></ul></ul><ul><li>Usability </li></ul><ul><ul><li>Hide transactional complexity  “e-persons” </li></ul></ul><ul><ul><li>Ease of authoring  “forms” </li></ul></ul>
    40. 42. Conclusion <ul><li>Developed prototype infrastructure for managing one-to-one relationships </li></ul><ul><ul><li>with radically lower transaction costs </li></ul></ul><ul><li>Protocols to uniformly cover previously disparate rights management cases </li></ul><ul><li>Enabled perspective shift to relationships </li></ul><ul><ul><li>relationship-based network security </li></ul></ul><ul><ul><li>contract-based approach to online privacy </li></ul></ul><ul><ul><li>... </li></ul></ul>

    ×