Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider giving grantee a read access to the Authorization #308

Open
elf-pavlik opened this issue Apr 4, 2023 · 3 comments
Open

Consider giving grantee a read access to the Authorization #308

elf-pavlik opened this issue Apr 4, 2023 · 3 comments

Comments

@elf-pavlik
Copy link
Member

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.

@ericprud
Copy link
Contributor

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).

@uvdsl
Copy link

uvdsl commented Apr 11, 2023

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.

@woutermont
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants