Browse Prior Art Database

Authority Transfer Mechanism for an Object Management Operating System

IP.com Disclosure Number: IPCOM000084213D
Original Publication Date: 1975-Oct-01
Included in the Prior Art Database: 2005-Mar-02
Document File: 4 page(s) / 64K

Publishing Venue

IBM

Related People

Bennett, RB: AUTHOR

Abstract

An authority transfer mechanism is described for a data processor operating system which enables transfer of authority to access objects from one user to another, without compromising unique user identifiers in a decentralized object access control environment.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 4

Authority Transfer Mechanism for an Object Management Operating System

An authority transfer mechanism is described for a data processor operating system which enables transfer of authority to access objects from one user to another, without compromising unique user identifiers in a decentralized object access control environment.

The authority transfer mechanism described herein is intended for use in an object management system of the kind described in an article entitled "Object Management System", by R.B. Bennett appearing in the IBM Technical Disclosure Bulletin, Vol. 18, No. 5, October 1975, pages 1356-1360.

The method of inter-user or interprogram communications provided by the herein described authority transfer mechanism has these features: (a) The originator may transfer objects to another user or program, delegating specific authority levels relative to the transferred object. (b) Although object access control is based upon Unique User Identifiers (UIDs), neither the originator nor the recipient of the transferred object need have access to the other's UID in order to accomplish the authority transfer. (c) It is not possible for the recipient of a transferred object to forward it to a third party, unless the originator has so authorized. (d) Responses to communications may be enforced for verification that the recipient has received (displayed) the communication.

The drawing shows the general flow of a "Letter" (LTR), a unit of communication, from the originator (X) to the addressee (Y), including the enforcement of a response. In the drawing, the Service Functions associated with the Mailbox and Post Office objects are collectively referred to as the Mail Service. Users are assumed to execute in separate environments, each with a dedicated Private Library for symbolically resolving to object IDs, and a Mailbox for holding incoming communications. The following objects are illustrated along with some of the required Service Functions associated with each: MAILBOX POSTOFFICE - DEPOSIT.LETTER * - DISPATCH * - DISPLAY.MAIL * PRIVATELIBRARY - FILE.LETTER * - CATALOG LETTER TRANSFERRED OBJECT - DISPLAY.CONTENTS - ACCESS - RESPOND * - SET AUTHORITY

The functions marked with an asterisk are described in detail at the end of this discussion. Other functions are not detailed because they are not critical to the description.

Communication is initiated by a Service Request, DISPATCH (1), whose arguments supply the following elements of a Letter object: (a) UID of originator
(b) SYMBOLIC ROUTING FOR ADDRESSEE (c) LETTER DESCRIPTION (d) * SERVICE FUNCTIONS AUTHORIZED (list) (e) * Identifier (ID) of transferred object (f) * RETURN ADDRESS -SYMBOLIC ID OF THIS LETTER - ORIGINATOR'S SYMBOLIC ROUTING -FLAG: OFF - RESPONSE REQUIRED ON - RESPONSE MADE

Letter elements marked with an asterisk are optional. If any are included, these combinations are permitted: d,e; d,e,f; and f.

1

Page 2 of 4

DISPATCH uses the CREATE.LETTER (2),

DETERMINE....