-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
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... :/
and grant
I am not referring to "triple-level access control" but rather on just linking from grant to authorization:
re caching: |
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. |
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.
The text was updated successfully, but these errors were encountered: