-
Notifications
You must be signed in to change notification settings - Fork 212
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
Add permissions bundles #549
base: main
Are you sure you want to change the base?
Conversation
tomayac
commented
Feb 4, 2022
- Add permissions bundles to allow for tiered API access.
- Minor changes (implementor → implementer Ngrams).
- Add permissions bundles to allow for tiered API access. - Minor changes (implementor → implementer [Ngrams](https://books.google.com/ngrams/graph?content=implementor%2Cimplementer&year_start=1900&year_end=2008&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cimplementor%3B%2Cc0%3B.t1%3B%2Cimplementer%3B%2Cc0)).
(I'm just checking back with our open source folks regarding the CLA.) |
CLA signed. |
CC: @aarongustafson & @diekus. |
@tomayac I’m intrigued by this concept, but it made me wonder if a permissions bundle could benefit from being an object with some form of label in addition to the array of permissions, rather than just an array of arrays? For example: "permissions": [
{
"label": "Copy/paste",
"bundle": [
"clipboard-write",
"clipboard-read"
]
},
{
"label": "Communications",
"bundle": [
"camera",
"microphone",
"notifications",
"push"
]
}
] Perhaps implementers would disregard the labeling information, but it could also be profoundly helpful for providing basic context around why permissions are being grouped. Counterargument though: it will be abused when someone labels a bundle "Required." :-( |
Maybe UAs could come up with commonly agreed-on enums for valid labels (like In contrast, mini apps have the notion of a free-form permission description, which would be more in line with your |