View
216
Download
3
Category
Preview:
Citation preview
A Network-Centric Design for Relationship-based Rights Management
Martin Röscheisen, Terry WinogradStanford Digital Library ProjectComputer Science Department
Stanford University
PowerPoint Template Design: Andreas Paepcke
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
?
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
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
Disparate set of protocols (special-purpose, proprietary, …)More uniformity? Interoperability?
Enforcement 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?
Overall Objective
“Open standards” rights management service layer thatunifies rights management protocolsaccommodates
legacy systemscurrent heterogeneity of trustspectrum of enforcement optionsinstitutional distribution
Towards a Rights Management Service Layer
RManagecomponents
FIRM rights management service layerDLIOP -- items, collections UPAI -- payment API
IIOP/CORBA HTTP COM
TCP/IP
“Infobus”
FIRM-enabledServices
DLITEviewer
Web browser
E-persons
Contracts ...
FIRM-readyClients
FIRM: Framework for Interoperable Rights ManagementRManage: prototype implementation of FIRM
Overall Approach: Relationship-Centric
Support relationship management Realize security, privacy, … as ancillary of it
… rather than content/property-centric
Example: Relationship-based Network Security
Manufacturing Partner
Inside OutsideFirewall
Traditional Company Relationships in the 90’s
ClientsOrganizational Boundary
Employees
Castle Modelof Security
Clients
Janitor Distributor
Contractors
Perspective Shift toRelationship-based Security
Cast
les
+Tu
nnel
s
Goals
Relationship management framework Architecture for managing relationships Domain extensibility, interoperability Usability
– Hide transactional complexity– Ease of authoring
Design Space
Simple Structured
Complexity
Static
Dynamic
Lotus Notes
most “e-commerce” technologies
firewalls
Dyn
amic
s
Relationship
Conceptual 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
Commpacts
Computational relationship objects,“smart contracts” FIRM interface + Code + State + Text Authorization function
CommpactGetDescription
Site LicenseThe following partiesagree to the conditions
GetPro
mise
s[Pro
mise
1] T
erm
inate
status: validcount: 4
ExerciseRight
GetSearchCount
Tim: Retrieve book using my site license!
Authorized? OK.
Tim’s Site
License
BookLexicon
Web server
Commpacts as Authorization Monitors
Tim’sPayPerUse
CommpactCommpact
Tim
Managing Commpacts: Network-Centric Architecture
Commpacts are interpreted at “commpact managers” anywhere
on the networkmanaged independently of controlled objects
Martin’sSubscription
Commpact Manager
Steve’sPayPerUse
Commpact Manager
Tim’s Site
License
Book
NewsletterJournal
Lexicon
Web server
ArticleArticle
ArticleArticle
Server
E-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
ServerClient Get
Result
FIRM rights protocol
delegate
Tom’se-person
Tom
Example: Contract-based Approach to Privacy
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 ?
weather site
shoe storeBrowser
ZIP: 94305
Shoe size: 9
RM
anag
e V
iew
: S
etti
ng
Up
E
-Per
son
Pre
fere
nce
s
Example: Personalized Content
FIRM-enabled Web server:Directly gets local page
Conventional Web server:Gets “Pick country” page
country
state
city
User accesses weather site…
Information organized around geographic navigation
E1: Exception; Get offerorsE2: List of offerors N1: Get offersN2: List of offersN3: Accept subscriptionN4: Accepted
E1,2
N3,4
N1,2
ServerClient
25
43Tom’sE-person UserProfiling
Offer
Tom
1: Request: e.g. HTTP2: Which commpact to use ?3: Use profiling commpact4: Request to authorize5: Authorization Decision
1: GET index.html
6: Result
Mike’sE-person
Under the Hood: Transactions
Case: Establishing a new relationship [Auto-Accept]
Case: Pre-existing relationship [no network caching]
Server
Tom’sE-person
1: GET index.html
2
1: Request: e.g. HTTP2: Which commpact to use ?3: Use profiling commpact4: Request to authorize5: Authorization Decision
Tom’s UserProfiling
Commpact
543Tom
6: Result
Client
Under the Hood: Transactions
like HTTP auth exchange
like HTTP server authorization
ServerClient
25
43Tom’sE-person Tom’s
UserProfilingCommpact
Tom
Web browser
Web server1: GET index.html
6: Result
Case: Pre-existing relationship [no network caching] Specialization: HTTP Access Control scheme
1: Request: e.g. HTTP2: Which commpact to use ?3: Response: Use subscription4: Request to authorize5: Authorization Decision
Under the Hood: Transactions
DocServer
Client
25
43Tom’sE-person Tom’s
UserProfilingCommpact
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. HTTP2: Which commpact to use ?3: Use profiling commpact4: Request to authorize5: Authorization Decision
Under the Hood: Transactions
Case: Pre-existing relationship [no network caching] Specialization: Rights clearing house case
ServerClient
25
43Tom’sE-person Tom’s
Commpact
Tom
1: GET index.html
6: Result
Third Partye.g. CCC
1: Request: e.g. HTTP2: Which commpact to use ?3: Use Tom’s commpact4: Request to authorize5: Authorization Decision
Under the Hood: Transactions
Server
Transactional 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
E-person
fast
Home/modem
ISP/backbone
ISP/backbone
Trust Management
Architecture accommodates people’s varied trust preferences
Examples:– Trust every site:
Commpact can be anywhere on network– Trust only one’s own server
Keep commpact local [traditional access control]– Trust specific third party
Have commpact managed by third party...
Domain Extensibility and Interoperability
FIRM: Framework for Interoperable Rights ManagementCarefully 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 specificationFormat for contributing domain-specific “rights vocabularies”
FIRM Interoperability Spec
Reification of generic contract law conceptsObject interfaces for
commpactspromises (rights and obligations)e-personsconditions (precedent, subsequent)constraints
Interactions:negotiationperformance (authorization, etc.)
CORBA IDL interface spec; protocol spec
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’ }}
RManage: 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 Ridder’s Dialog Service– Xerox’ text summarizer
Prototype authorization plug-in for Web server– privacy negotiation [weather, advertising]
Example: Managing Subscriptions
Currently: Application-centered, disparate RManage: User-centered & integrated
Browser
WebServer
Quicken
e.g. WSJ
SubscriberDatabase
PaymentProcessing
passwords“cookies”
checks, ...
SubscriptionContract
Mail: InvoiceFAX: Student ID
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
RM
anag
e V
iew
: C
ontr
act
RM
anag
e V
iew
: N
otif
ier
Linking in Fulfillment Actions
Example: Initiate actual payment transfer
PaymentObligation
FIRM: Fulfill
PaymentModule
e.g. UPAI
Pay $300 tosergey@Stanford
native paymentprotocols
FIRM: DeclareFulfilled
bank, etc.
Constraint Checking
Example: “Student status required” – enforced directly based on attributes– evaluated using same infrastructure as for
search queries (Infobus proxies to local services)
Right
Exercise
Constraint
Check Condition
StanfordWhoisProxy
DLIOP
Authoring Support: Forms
How do you draft a new contract
…if commpacts contain so much behavior?
Allow sharing and reuseCommpacts based on “forms”Extensible, distributed system of forms
» Forms provider provide forms
» Users customize and use forms.
…as user’s starting point Just find and select a form
(“smart stationery”) Then fill in fields, etc.
Creating New Contract: “Forms”
Goals Revisited
Framework for relationship managementcommunication model, commpacts
Architecture “network-centric” commpact management
Domain extensibility, interoperability two-level FIRM specification
Usability– Hide transactional complexity “e-persons” – Ease of authoring “forms”
Conclusion
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– ...
Recommended