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