Pay As You Go – Associating Costs with Jini Leases By: Peer Hasselmeyer and Markus Schumacher

1. Pay As You Go – Associating Costs with Jini LeasesBy: Peer Hasselmeyer and Markus Schumacher Presented By: Nathan Balon

2. Introduction • The paper is proposing an extension to the Jini Architecture to provide for the ability to charge for the usage of a Jini lease. • Jini already has the ability to provide a lease for a resources, so the authors are proposing an extension to the leasing framework. • The authors then go on to provide a number of solution to the problems that come from using billable leases. • The main focus of the paper is the problems of starting and stopping a leased service.

3. Background Information on Jini • The goal of Jini is to create a distributed computing environment that allows for rapid configuration of software and devices using a “plug and play” model. • When a Jini device is attached to a network it announces its presence. After its presence has been announced, other components can then use the services it has to offer.

4. How Jini Works • There are three central components of Jini. • The service is a piece of independent functionality made available to other users. • The client is a device or software component that would like to use a service. • The lookup service is a special service that keeps track of the other services in a community.

5. Lookup Service

6. Jini Leases • A Jini lease is a contract between two parties. • The lease grantor has a resource they are willing to grant to another party. • Lease holder then uses the resource of the lease grantor. • Before granting access to a resource, a length of time is negotiated between the two parties. The lease grantor always has the final say in the negotiation of time length. • Jini leases are primarily used for garbage collection. It provides a convenient way for unused resources to be freed when the lease expires.

7. Lease Interface •  Any object that wishes to grant a lease must implement the lease interface. public interface Lease { // duration is in milliseconds void cancel() throws UnknownLeaseException, RemoteException; long getExpiration(); void renew(long duration) throws LeaseDeniedException, UnknownLeaseException, RemoteException; … }

8. Extension to Jini Leases • The authors envision using Jini leases in a commercial environment. • Service providers could then charge a fee for the use of their services. • In a Jini system software entities communicate with each other. This poses a problem, the typical model used on world-wide web is to generate revenue for the services provided through advertising, this model is unacceptable in this case. • Two pricing models could be used in the charging for a service. They are: unit-based pricing and time-based pricing. • A few examples of services that could be leased for a fee are: a storage service which could be used to perform temporary calculations, also software components that rarely used could be leased.

9. Problems with Jini Leases • Using Jini leases in a commercial environment poses a number of problems. • The majority of the problems deal with the security threats to the Jini lease model when used in a commercial environment. • Problems that arise: • Violation of Integrity • Theft of Information • Denial of Service • Repudiation: it cannot be verified that a user has performed a certain action. • For integrity and confidentiality authors propose the use of encryption to combat these threats. • The intent of the paper was to focus on the threat of repudiation.

10. Problems with Charging for Services • The service provider must be sure that a client has really ordered a service. • Clients want to be sure that a service provider has received an order. • It should be impossible for a client to use a service and not pay for it. • A service provider should not be able to get money for a service they have failed to provide.

11. Non-repudiation • The parties involved must have some way of guaranteeing that each one completes their part of a contract. • If a dispute arises between the parties there must be a way to determine who is right or wrong. • The authors state “the goal of non-repudiation is to transfer the concept of proofable contracts to the users action in IT systems.”

12. Requirements for Non-repudiation • All participants must trust the concept of and functionality of a service. • All participants must be willing to accept the result of the validation of proofs. • The judgment must be enforceable. • A legal binding must be established for the basic cryptographic mechanisms.

13. External Dependencies • A number of additional external services are need along with the non-repudiation service the authors are proposing. • Public Key Infrastructure: key management is need to provide digital signatures. • Secure Time Service: a trusted time service is required. • Secure Storage: electronic evidence must be stored in a secure location. • All communication channels must be secure.

14. Proposed Architecture • First, there is set of rules that the service must obey. • Java interfaces are used to define a number of methods that must be implemented. • The authors propose extending the Lease interface with a BillableLease interface. • Every service must also implement the AccessCharge interface to associate a cost to a service. • The two proposed interfaces use some additional objects which are : a Contract object and a Evidence object. • Contracts must be remotely accessible object that link a service to a specific contract. The authors envision contracts as being signed xml documents. • The Evidence objects are objects created by the non-repudiation service which we will see shortly.

15. Proposed Interfaces public interface BillableLease extends Lease{ Contract getContract(); long getCost(); Evidence renew(long duration, Evidence ProofOfOrgin); Evidence cancel(Evidence ProofOfOrgin); } public interface AccessCharge{ AccessGrant start(Contract termsAndConditions, Evidence proofOfOrgin, long duration); }

16. Proposed Architecture • The second part of the architecture are the run-time services. • Non-repudiation service • Time service • Accounting service

17. Non-repudiation Service • It Creates pieces of evidence (proofs). • It persistently stores evidence (proofs). • Evidences contained in proofs: • The contract that has been applied • Type of action or event (method name called) • Parameters of the method • A signed time stamp • The identity of issuer of proof • The identity of both parties • Hash value for validation of the proof

18. Non-repudiation Service • Steps required for the non-repudiation service. • Evidence generation • The transmission, storage and retrieval of evidence • Validation of evidence • Settlements of conflicts • The authors note that settlements of conflicts will usually be done by human intervention.

19. Time Service • The time service is a trusted entity that supplies time stamps. • The time service is needed because of lack of synchronized time in a distributed systems. • The non-repudiation service will then use the timestamps generated from the time service.

20. Accounting Service • The accounting service is responsible for storing and retrieving billing records. • Contains information such as the time and length of service usage, type of service used, identification of the client and a reference to the contract used.

21. Component Interaction

22. Starting a Billable Lease • To initiate the use of a service the client sends a message to the non-repudiation service to generate a proof of origin. • The client then receives the proof of origin from the non-repudiation service. • The client then calls the start method from the AccessCharge interface and supplies the proof of origin along with the additional required parameters which is sent to the service provider. • When the service provider receives the start request, the service provider then asks the non-repudiation service to generate a proof of receipt. • The service provider upon receiving the proof of receipt from the non-repudiation service, then returns to the client a proof of receipt and a billable lease. • The client has now established a lease and can use the services. • At the completion of the service usage the service provider sends a billing record to the account service.

23. Starting a Lease

24. Future Work • There is no standardized and usable non-repudiation service. • Ways to negotiate contracts between parties needs to be established. • Ways to keep clients and service providers anonymous.