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