Skip to content

Re-evaluate naming and meaning of scopes used in Data Consent and Data Grant #155

@elf-pavlik

Description

@elf-pavlik

For example renaming AllRemoteFromAgent -> AllFromAgent which would also address #113 We might also define All as everyone's data including case where Requesting Party === Data Owner. Which means we might consider adding convenience of AllFromOthers which would exclude that case. The last one to be honest I'm not sure of scenario where one would want to use. It sounds weird to give consent for everyone else data but not mine 🤔

Possibly also: AllInstances -> AllFromRegistration, or even better AllFromRegistry where we would define that:

  • Every Data Registry MUST have maximum one Data Registration for given Shape Tree
  • Every Storage SHOULD have maximum one Data Registry

I someone has reason to have separate Data Registrations they preferably would be using separate Storages, in most cases that's what they would want to do anyways.

Following it

  • InheritInstances -> InheritedFromRegistration, or even better InheritedFromRegistry
  • SelectedInstances -> SelectedFromRegistration, or even Better SelectedFromRegistry

This way we have 3 levels of consents for given shape tree

  • global
  • (social) agent
  • registration/registry (/storage if one registry per storage)

We have all/selected for bottom registration/registry level, so mid level only needs all (AllFromAgent), to be more granular one just uses bottom level.

Now we should consider inherited scopes for consents. Following the three levels

  • All -> InheritedAll
  • AllFromAgent -> InheritedFromAgent
  • AllFromRegistration and SelectedFromRegistration -> InheritedFromRegistration

Defining distinct Inherited scopes match having different shapes for each of them.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions