solid / solid/data-interoperability-panel
Document pattern of using local group as grantee of consent
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 58
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
Looking at the familiar diagram
Luis, acting as a trusted grantee of ACME, wants to grant access to members of a local group. Local groups mean that ACME manages the group listing and ACME's authorization agent has access to it. In that case, Luis grants specific access to the ACME RnD group. ACME's authorization agent would record the Access Consent where the group would be the grantee. Then authorization agent would generate an access grant for each member of the group.
TODO
- Clarify that a local group would only be the grantee on Access/Data Consent.
- Clarify that generating of Access/Data Grants would need to be re-triggered when group membership changes.
- Vocab to express group membership
- Should group listing go as agent registration?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the familiar diagram and trace the specification sections covering Access/Data Consent, Access/Data Grants, local groups, and agent registration. Review the four TODO items and existing terminology, then document the agreed group-grantee flow, membership-change behavior, group-membership vocabulary, and whether group listing belongs in agent registration.
Written by the indexing model from the issue text.
Assessment
- Domain
- authorization, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100