Consider giving grantee a read access to the Authorization
elf-pavlik opened this issue · 3 comments
Currently, we assume that the grantee can only access the grant but not the authorization, this leads to re-stating the same information in the authorization and the grant. We should re-consider what exactly are we trying to prevent from being disclosed and document reasoning whichever way it lands.
Scopes
While grantees will not explicitly know if they were granted All or AllFromAgent scope in the authorization, they still should be able to make informed guess based on observed changes to auto-generated grants.
Granted / Denied
In #278 and #293, we have some ongoing work on denying and revoking access. I don't think there is any information in the authorization that would not be available in the grant. Still, we should double-check.
There might be a temptation to use this redundant info as a local cache to 1. enable some "airplane mode" use cases, 2. make the UI snappier. I suspect both of these would be best addressed by a more general caching scheme (which would be interesting work).
I am just copying (ha... how ironic, did not find an option to link them) my comments from the gitter channel:
Take as an example, the data authorization example and data grant example from the spec, they are literally the same except for the grant referencing the data registration. If the authorization is the unique thing anyway, why would you mandate copying it, instead of linking it from a grant? If you expose the same data anyway to different audiences, then the audiences decide in any case what to do with it. Data providers do not really care for read-only immutable data. If it was maybe mutable data by the audiences, then yes, but in the case at hand, I don't see the benefit of that level of indirection... :/
_:authz a interop:DataAuthorization ;
interop:dataOwner alice:\#id ;
interop:grantee projectron:\#id ;
interop:registeredShapeTree pm-shapetrees:TaskTree ;
interop:accessMode acl:Read, acl:Create ;
interop:creatorAccessMode acl:Update, acl:Delete ;
interop:scopeOfAuthorization interop:Inherited ;
interop:inheritsFromAuthorization alice-authorization:54a1b6a0 ;
interop:satisfiesAccessNeed projectron:\#9462959c .
and grant
_:grant a interop:DataGrant ;
interop:dataOwner alice:\#id ;
interop:grantee projectron:\#id ;
interop:registeredShapeTree pm-shapetrees:TaskTree ;
interop:accessMode acl:Read, acl:Create ;
interop:creatorAccessMode acl:Update, acl:Delete ;
interop:scopeOfGrant interop:Inherited ;
interop:inheritsFromGrant alice-projectron:40d038ea ;
interop:satisfiesAccessNeed projectron:\#9462959c ;
interop:hasDataRegistration alice-work-data:df4ab227\/ .
I am not referring to "triple-level access control" but rather on just linking from grant to authorization:
_:grant a interop:DataGrant ;
interop:basedOnAuthz _:authz;
interop:hasDataRegistration alice-work-data:df4ab227\/ .
re caching:
Personally, I think that client-side caching is independent from the data model.
If a client wants to enable "airplane mode" or a snappier UI, they can very well do so, without the replication of data being mandated by the spec.
Interesting question, to be treated with caution. If possible, it would indeed make the model more elegant, but we should be careful not to optimize prematurely. That said, given the current indications, I think we could definitely try using only one resource, and see how far that brings us.
Re caching, I agree with @uvdsl: it should not inform our data model.