-
Notifications
You must be signed in to change notification settings - Fork 0
Modes
Modes are specified for the read and write operations, and sharing consents can be restricted and enhanced by modes.
Modes are defined in permissions.AccessMode. A set of modes is used to indicate requested or consented modes.
An object can be requested with certain modes, e.g. read,anonymous or write,pseudonymous. A get request always has implicit read mode, while put, post and delete requests have an implicit write mode.
The modes of each request is logged in the permission.Access object.
An object can be shared with consent with certain modes, e.g., anonymous.
Certain modes, such as anonymous must be requested if the accessing principal has been consented access with that mode. The mode must be requested explicitly, because the returned result may be different.
Modes can be requested that are not consented, as long as the schema supports the mode. If a mode is requested for an object that is not supported, an error is raised.
Modes are supported by Capabilities, which are attached to Schemas.
combined mode allows a DApp to bypass the restriction that only objects for which there are intersecting consents may be read in one transaction or session. If combined mode is invoked objects with no overlapping consent may be read (DDH paper 8.2.4).
| Requested Mode | Consented Mode | Effect |
|---|---|---|
| combined | - | error, requested mode must be consented |
| combined | combined | object is read, but ignored for check |
| - | - | object is checked for overlapping consents |
| - | combined | object is checked for overlapping consents |
The overlapping consents are determined as the intersection of object owners and all consentees, except for the transaction owner. This ensures that only objects that have a common access are combined.