You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recording this as its own issue after it was raised in #173
What is the cost / benefit of copying access needs into the consent registry, and referencing them in the Application Profile?
To date we have stored these in the (likely) event that an Application Profile changes its Access Needs, either by adding new ones or removing others. Having a local copy gives us the ability to compare what was originally authorized vs. the changed set.
We may be able to offload this to the Application's profile, and specify that the application must maintain a historical set of its changes, so that it's explicit when there is an updated set, and they can be diffed. A hash (e.g. URDNA2015) could also be maintained by the client to look for cases where the application changes an existing set. Generally the problem with this approach would be that if the application stops publishing their access needs at some point, the links would break, and that would impact the auditing trail.
We could leave it as a recommendation that implementations cache access needs in the consent registry when necessary to maintain that audit trail.
The text was updated successfully, but these errors were encountered:
Recording this as its own issue after it was raised in #173
What is the cost / benefit of copying access needs into the consent registry, and referencing them in the Application Profile?
To date we have stored these in the (likely) event that an Application Profile changes its Access Needs, either by adding new ones or removing others. Having a local copy gives us the ability to compare what was originally authorized vs. the changed set.
We may be able to offload this to the Application's profile, and specify that the application must maintain a historical set of its changes, so that it's explicit when there is an updated set, and they can be diffed. A hash (e.g. URDNA2015) could also be maintained by the client to look for cases where the application changes an existing set. Generally the problem with this approach would be that if the application stops publishing their access needs at some point, the links would break, and that would impact the auditing trail.
We could leave it as a recommendation that implementations cache access needs in the consent registry when necessary to maintain that audit trail.
The text was updated successfully, but these errors were encountered: