A Network-Centric Design for Relationship-based Rights Management

About This Presentation
Title:

A Network-Centric Design for Relationship-based Rights Management

Description:

A Network-Centric Design for Relationship-based Rights Management Martin R scheisen, Terry Winograd Stanford Digital Library Project Computer Science Department – PowerPoint PPT presentation

Number of Views:3
Avg rating:3.0/5.0

less

Transcript and Presenter's Notes

Title: A Network-Centric Design for Relationship-based Rights Management


1
A 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
2
A 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
3
Bridging 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
4
Current 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?

5
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?

6
Overall 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
7
Towards a Rights Management Service Layer
RManage components
FIRM Framework for Interoperable Rights
Management RManage prototype implementation of
FIRM
8
Overall Approach Relationship-Centric
rather than content/property-centric
  • Support relationship management
  • Realize security, privacy, as ancillary of it

9
Example 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
10
Goals
  • Relationship management framework
  • Architecture for managing relationships
  • Domain extensibility, interoperability
  • Usability
  • Hide transactional complexity
  • Ease of authoring

11
Design Space
Complexity
Simple Structured
Relationship
Static Dynamic
Lotus Notes
firewalls
Dynamics
most e-commerce technologies
12
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

13
Commpacts
  • Computational relationship objects,smart
    contracts
  • FIRM interface Code State Text
  • Authorization function

14
Commpacts as Authorization Monitors
Tims SiteLicense
Commpact
Commpact
Lexicon
Authorized? OK.
Book
TimsPayPerUse
Web server
Tim Retrieve book using my site license!
Tim
15
Managing 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
16
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

Get
Client
Server
Result
delegate
Tom
Tomse-person
FIRM rights protocol
17
Example 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 ?

18
RManage View Setting Up E-Person Preferences
19
Example 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
20
Under 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
21
Under 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
22
Under 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
23
Under 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
24
Under 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
25
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
Server
Home/modem
ISP/backbone
E-person
fast
ISP/backbone
26
Trust 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...

27
Domain 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
28
FIRM 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
29
Domain 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
30
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 Ridders Dialog Service
  • Xerox text summarizer
  • Prototype authorization plug-in for Web server
  • privacy negotiation weather, advertising

31
Example 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

32
RManage 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
33
RManage View Contract
34
RManage View Notifier
35
Linking 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.
36
Constraint 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
37
Authoring 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.

38
Creating 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)
41
Goals 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

42
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
  • ...
Write a Comment
User Comments (0)