Remove `interop:AccessAuthorization`, `interop:AccessGrant` and `interop:AccessNeedGroup`

[srosset81]

From Friday meeting with @elf-pavlik:

• SR: Are Access Authorizations and Access Grants really needed ? It seems they are used only to group together grants/authorizations, but it's a lot of work to manage them. Similarly it seems we could do without Access Need Groups.
• SR: IMO if we can simplify some parts of SAI, it will increase adoption amongst developers.
• SR: For me data authorizations/grants are the basis of SAI permission system. We can do a lot with them. Access authorizations/grants just seem an annoyance. We could link data grants directly from application registration or social agent registrations.
• eP: Original purpose was to group together grants. This reduces the number of time a agent registration is updated.
• SR: In ActivityPods, we update the registration only when all data grants have been updated.
• eP: Was also used to group together access needs, so that they could be accepted together.
• SR: Maybe an optional predicate could identify AccessNeeds which should be "grouped" ?
• eP: I will contact Justin and Eric to see if there are use cases I don't remember about.

[ericprud]

to eP's point, i recall the goal being to associate a single functionality with a set of permissions, e.g. app says it will backup your recipies if only you're so generous as to grant read permissions to your recipie archive and write access to your backups; granting either one alone does not enable backups.

[TallTed]

app says it will backup your recipies if only you're so generous as to grant read permissions to your recipie archive and write access to your backups; granting either one alone does not enable backups

I think there's more to the permissions required by such an app.

• Define the granularity. Recipe? Ingredient? Implement (oven, slow cooker, deep fryer, saucepan, etc.)?
• CREATE new grains
• MODIFY and/or DELETE the grains of previous backup operations
• Handle retention cycle options (e.g., retain one per year, one per month for the most recent year, one per week for the most recent month, one per day for the most recent week, one per hour for the most recent hour....)

There are likely more considerations.

[ericprud]

app says it will backup your recipies if only you're so generous as to grant read permissions to your recipie archive and write access to your backups; granting either one alone does not enable backups

I think there's more to the permissions required by such an app.

Nope, that was the point of the whole SAI infrustructure. A trusted party provided the ShapeTrees, the ShapeTrees provided the label recipie, the ACL provided the verb write, and the app provided the intention "backup your recipies".

• Define the granularity. Recipe? Ingredient? Implement (oven, slow cooker, deep fryer, saucepan, etc.)
• CREATE new grains
• MODIFY and/or DELETE the grains of previous backup operations
• Handle retention cycle options (e.g., retain one per year, one per month for the most recent year, one per week for the most recent month, one per day for the most recent week, one per hour for the most recent hour....)

There are likely more considerations.

[srosset81]

to eP's point, i recall the goal being to associate a single functionality with a set of permissions, e.g. app says it will backup your recipies if only you're so generous as to grant read permissions to your recipie archive and write access to your backups; granting either one alone does not enable backups.

Thanks for the example @ericprud . What I find very complicated to handle are mostly the access authorizations and access grants. The access needs groups are only generated when app's access needs change, so that doesn't happen every day.

We could probably find a way to simplify access need groups, or make them optional, but that would be a different topic IMO, and one that is less urgent. Maybe we can split this issue and go ahead with the removal of access authorizations and access grants @elf-pavlik ?

[ericprud]

to eP's point, i recall the goal being to associate a single functionality with a set of permissions, e.g. app says it will backup your recipies if only you're so generous as to grant read permissions to your recipie archive and write access to your backups; granting either one alone does not enable backups.

Thanks for the example @ericprud . What I find very complicated to handle are mostly the access authorizations and access grants. The access needs groups are only generated when app's access needs change, so that doesn't happen every day.

We could probably find a way to simplify access need groups, or make them optional, but that would be a different topic IMO, and one that is less urgent. Maybe we can split this issue and go ahead with the removal of access authorizations and access grants @elf-pavlik ?

The proposal to remove interop:AccessNeedGroup seems different in kind from the propopsal to remove interop:AccessAuthorization and interop:AccessGrant. I believe the latter two relate to tracking grants and the former relates to grouping an applications's needs for some functionality.

I've not fully swapped in but I think we run the risk that optionality makes it more complicate rather than less because then you have two models. We should at least record them. I'll make an attempt here (abusing mermaid a bit by pretending that e.g. hasAccessDescriptionSet has no upper cardinality):

with access groups

erDiagram
    direction TB
    Application ||--o{ AccessNeedGroup : needs
    Application {
        string applicationName
        IRI applicationAuthor
    }
    AccessNeedGroup ||--|{ AccessNeed : hasAccessNeed
    AccessNeedGroup {
        IRI hasAccessDescriptionSet
        IRI accessScenario
        IRI authenticatesAs
    }
    AccessNeed {
        IRI registeredShapeTree
        IRI accessNecessity
        CRUD accessMode
        CRUD creatorAccessMode
    }

Loading

without access groups

I guess without AccessNeedGroup, we'd copy hasAccessDescriptionSet, accessScenario, authenticatesAs into each of the formerly-grouped AccessNeeds:

erDiagram
    direction TB
    Application ||--o{ AccessNeed : needs
    Application {
        string applicationName
        IRI applicationAuthor
    }
    AccessNeed {
        IRI hasAccessDescriptionSet
        IRI accessScenario
        IRI authenticatesAs
        IRI registeredShapeTree
        IRI accessNecessity
        CRUD accessMode
        CRUD creatorAccessMode
    }

Loading