Hackathon 4 refractor auth app

[uvdsl]

In this PR, we refractor the Access Request component as discussed at Hackathon 4 [1].

We split the current Access Request component into the single components as specified in INTEROP [2].

• Access Request is a component that displays its properties, links to Access Need Groups, and can be authorized (triggering authorization of all linked Access Need Groups) and create an Access Receipt.
• Access Need Group is a component that displays its properties, links to Access Needs, and can be authorized (triggering authorization of all linked Access Needs) and create an Access Authorization.
• Access Need is a component that displays its properties, and can be authorized to ACLs accordingly and create a Data Authorization.
• Data Authorization is a component that relates to an Access Need, and can be revoked.
• Access Authorization is a component that relates to an Access Need Group, and can be revoked (revoking all linked data authorizations)
• Access Receipt is a component that relates to an Access Request, linking all Access Authorizations that are currently granted.

We introduce the Access Receipt to our demo to adhere to the duality of the specified data model [2].
Access Receipts are an entity introduced in [2].
It makes handling the status of Access Requests easier and allows for multiple Access Need Groups to be present in an Access Request, which is possible according to the spec [2].

Authorizing an Access Request is implemented bottom up:
An Access Need is responsible to create a corresponding Data Authorization, to set the ACLs accordingly, and to fire an event to notify the parent component, i.e. an Access Need Group, about its authorization.
An Access Need Group is responsible to create a corresponding Access Authorization and linking the Data Authorizations of its children components (the Access Needs). Authorizing an Access Need Group triggers the authorization of all its linked Access Needs, awaits their authorization event, and then creates the Access Authorization and emitting an event to notify the parent component, an Access Receipt about the authorization.

Revocation is implemented in the same manner, bottom up via triggers from the parent components and events from the children components.
Pattern: Upon revocation, we notice a pattern of (archive/)copy/update/paste where the idea is to keep the old data around for audit/logging reasons and to "replace" it with some new data (see also #48).
Room to improve: We currently "archive" an old authorization for easier management of data, assigning a new URI to the old authorization. From a data integrity perspective, this seems to be malpractice. We do this nonetheless because as stated in [1], the semantics of the "replaced" data are violating the usual understanding of asserted statements, and we need to somehow make sure to only consider the "really asserted ones". This may pose as an interesting argument for the application of RDF-star [3] or Named Graphs for archiving (former) knowledge.

Current state of the auth app:

• link to purpose of Access Request added, see https://solid.ti.rw.fau.de/public/ns/gdpr-purposes
• added decline of Access Request (creates an Access Receipt that does not link any Access Authorization)
• added revocation of access rights
• display status of an Access Request: if an Access Request is already handled, there exists an Access Receipt which is displayed instead of the Access Request. Only open Access Requests are displayed.
• An Access Request can have multiple Access Need Groups which was previously not possible with our implementation
• added handling for the new Acsess Request property forSocialAgent
• have business apps use the Access Request property forSocialAgent if applicable Add property forSocialAgent in access requests of business apps #51
• fixed minor bugs

Future work:

• UI beautifications, e.g. put labels instead of links, UX - Beautify UIs #26
• investigate DPV for expressing purpose of Access Request Purpose of Access Request #52
• Freeze feature (Feature) Freeze Authorizations #48

Potentially re-visit "archiving strategy" (currently just creating and using a hard-coded container)
When I "tested" (#25) this PR, the E2E flow of the use-case worked as before.

Did I miss anything? Any comments?

Cheers
Christoph

[1] https://docs.google.com/document/d/1Q_VCChtPjwXGNRU9Yn9pJJM1-RCnFrYQuh_sZb_t2MQ/edit
[2] https://solid.github.io/data-interoperability-panel/specification/
[3] https://www.w3.org/2022/08/rdf-star-wg-charter/

[uvdsl]

We identified the following problems with the data model of the INTEROP spec:

1. Description of Access Need
   An Access Need does not link to the Access Description Set or similar.
   The access need group only links to the access description set, but from that set, there is no link to any further description. That is, based on an access request, we can not discover its description.
   So, we cannot retrieve labels and definitions for acceess needs via graph traversal.
   One could easily solve such problems by directly describing the access need.
   The way the spec handles description is incorrect in my opinion:

<#accessNeedGroupDescription>
      a interop:AccessNeedGroupDescription ;
      interop:inAccessDescriptionSet <#accessDescriptionSet> ;
      interop:hasAccessNeedGroup <#accessNeedGroup> ;
      skos:prefLabel "Zugriff Offer und Order container"@de ;

means that there is something of type AccessNeedGroupDescription, and the preferred label of that description is "Zugriff ..." but what the spec wants to see here, is the label of the access need group or acecss need for the corresponding description resource.

2. rdfs:domain of interop::hasAccessNeedGroup
   The specification allows for example interop:AccessRequest or interop:AccessNeedGroupDescription as rdfs:domain of interop:hasAccessNeedGroup.
   This indicates a very loose semantics of interop:hasAccessNeedGroup because if a an Access Request has a Need Group the "having" means something else than a Description "having" a Need Group.

3. interop:replaces of Access Authorizations
   As mentioned in the initial comment on this PR, the "replaced" Access Authorizations are still asserted, and not quoted or placed into a different graph.

Feel free to add more problems, if you have some on your mind.

[banxtv]

Tested the whole usecase with this newer version of the auth app and everything works as intended :)

I also made some minor cosmetical changes to the UI:

• Display "From Demand" in AccessRequest only if there is an actual value set (compatibility with potential 3rd party apps not sending this triple)
• Purpose now links to vocab + shortened displayed text
• Changed displayed caption of a single AccessAuthorization to link to actual AccessAuthorization and shortened displayed text
• Shortened displayed "From Demand" text in AccessRequest
• Shortened displayed "Required Data" text in AccessNeed
• Shortened displayed "Required Instances" text in AccessNeed
• Shortened displayed "For Access Request" text in AccessReceipt
• Shortened displayed "Access Need Groups" text in AccessAuthorization
• Shortened displayed "Access Needs" text in DataAuthorization
• Shortened displayed "Authorized Data" text in DataAuthorization
• Shortened displayed "Data Registration" text in DataAuthorization

I also tried to get the foaf:name from the profile cards, but i failed miserably at javascript, async functions and displaying results in the UI :D I will have to take another look tomorrow

You may review the UI changes and merge afterwards or let me know if more changes are needed

[banxtv]

Replaced WebIds with the actual names from the profile cards (foaf:names) in the UI of all AuthApp components.

My solution works, as long as we dont have more than one recipient, sender and grantee.
If a more flexible solution is needed, we would need to refactor that. Let me know.

I also added interop:forSocialAgent to the access request for offer & order data registrations in the BankApp.

When the branch is reviewed and merged, i will close the respective tasks in Github.

Tomorrow ill work on changing credit:fromDemand to rdfs:seeAlso.
This should conclude all changes needed for the ICWE paper.

[banxtv]

• Changed from:demand to rdfs:seeAlso in all AccessRequests and in AuthApp UI
• Shortened "Authorized Instances" text in DataAuthrization UI (this should conclude all textual beautifications in AuthApp)
• Added success toast for "Request creation of data" in Bank-App
• Added success toast for "Request creation of data" in SME-App
• Fixed issues in AccessAuthorization i introduced with my previous changes

Finally i tested the full usecase, everything (still) works as intended.
I also re-tested the revokation of access rights for SME and Bank and reviewed the stored data in the respective Pods.

Everything works just fine!
Great work! :)

[uvdsl]

@dschraudner , @se-schmid something missing from your side for this PR?
Any changes requested from your side?