-
Notifications
You must be signed in to change notification settings - Fork 0
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
Hackathon 4 refractor auth app #49
Conversation
…rchive of authorizations
currently, the focus access request and any authorization are displayed upon redirect to the auth app. this simple approach does simply not load authorizations when the redirected to the app
We identified the following problems with the data model of the INTEROP spec:
<#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
Feel free to add more problems, if you have some on your mind. |
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:
I also tried to get the You may review the UI changes and merge afterwards or let me know if more changes are needed |
…cialAgent" in Access Request for offer/order in BankApp
Replaced WebIds with the actual names from the profile cards ( My solution works, as long as we dont have more than one recipient, sender and grantee. I also added When the branch is reviewed and merged, i will close the respective tasks in Github. Tomorrow ill work on changing |
…p UI + add success toasts for "request additional data" in SME & Bank App + minor textual beautification in AuthApp
Finally i tested the full usecase, everything (still) works as intended. Everything works just fine! |
@dschraudner , @se-schmid something missing from your side for this PR? |
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 toAccess Need Group
s, and can be authorized (triggering authorization of all linkedAccess Need Group
s) and create anAccess Receipt
.Access Need Group
is a component that displays its properties, links toAccess Need
s, and can be authorized (triggering authorization of all linkedAccess Need
s) and create anAccess Authorization
.Access Need
is a component that displays its properties, and can be authorized to ACLs accordingly and create aData Authorization
.Data Authorization
is a component that relates to anAccess Need
, and can be revoked.Access Authorization
is a component that relates to anAccess Need Group
, and can be revoked (revoking all linked data authorizations)Access Receipt
is a component that relates to anAccess Request
, linking allAccess 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 Receipt
s are an entity introduced in [2].It makes handling the status of
Access Request
s easier and allows for multipleAccess Need Group
s to be present in anAccess 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 correspondingData Authorization
, to set the ACLs accordingly, and to fire an event to notify the parent component, i.e. anAccess Need Group
, about its authorization.An
Access Need Group
is responsible to create a correspondingAccess Authorization
and linking theData Authorization
s of its children components (theAccess Need
s). Authorizing anAccess Need Group
triggers the authorization of all its linkedAccess Need
s, awaits their authorization event, and then creates theAccess Authorization
and emitting an event to notify the parent component, anAccess 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:
Access Request
added, see https://solid.ti.rw.fau.de/public/ns/gdpr-purposesAccess Request
(creates anAccess Receipt
that does not link anyAccess Authorization
)Access Request
: if anAccess Request
is already handled, there exists anAccess Receipt
which is displayed instead of theAccess Request
. Only openAccess Request
s are displayed.Access Request
can have multipleAccess Need Groups
which was previously not possible with our implementationAcsess Request
propertyforSocialAgent
Access Request
propertyforSocialAgent
if applicable Add propertyforSocialAgent
in access requests of business apps #51Future work:
Access Request
Purpose of Access Request #52Potentially 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/