solid / solid/data-interoperability-panel

Define Rejection Records

Open
#278 0 comments 0 reactions 1 assignee View on GitHub

@elf-pavlik is already working on this.

Since Feb 27, 2023.

agent-registration data-authorization
Dominant language
Bikeshed
Stars
58
Forks
18
PR merge metrics
No merged PRs in 30d

Description

I see few places where various types of Rejection have to be recorded

Application Authorization

If a user on the Authorization screen decides not to authorize the app, it should be recorded so if the user sometime in the future launches that app and gets to the Authorization screen again they see their previous decision.

Access Receipt

In the sample implementation of the authorization agent, access receipt results in Push Notification sent to the user which takes them to a screen where they can add new Social Agent Registration. If they decide to reject it, it should also be recorded and available in the future.
BTW we may want to define that Authorization Inbox SHOULD only allow one receipt from a given Social Agent. Once connection gets established via Social Agent Registrations (reciprocal ones), Solid Notifications (webhook in our sample implementation) keep both agents up to date so no further Acces Receipts are needed between them.

Access Request

We still need to clarify access requests between Social Agents. I have a strawman proposal leveraging Social Agent Registrations and reusing Access Receipt if needed. Still specific Access-Request could be rejected and this should be recorded.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.