authorization-base in de WorkflowTask

[willemsendennis]

Hi Allen,

Ik zie in de versie van deze Notified Pull ineens de authorization-base ook in de WorkflowTask staan. Dat was eerder nooit; alleen in de NotificationTask. Met welke reden is deze nu ook in de WorkflowTask gezet? Hierdoor is de flow (en WorkflowTask) niet meer interoperabel met de andere TA's.

[jorritspee]

Hi Dennis,

Hij is sowieso optioneel dus het moet ook werken als hij niet is opgenomen.

Ik moet er even heel hard over nadenken.

In een Nuts-implementatie is het opnemen van de authorization-base in een notification- of workflow-task sowieso nooit echt nodig. Het is alleen maar convenience.

Ik zie dat de authorization-base ook niet in deze voorbeeld workflow-task staat: https://docs.google.com/document/d/1haRC3WKeBpP4YU7C9rqnl-9HMRAejYxziHo6SfJ_0g4/edit

Bij Twiin is geen profiel van de workflow-Task opgenomen, anders had ik die mooi als basis kunnen hanteren.

Is er ergens (bijv. in de TA NP) wel een profiel van de workflow-Task opgenomen waarop we kunnen doorbouwen?

Volgens mij was de onderbouwing om hem optioneel op te nemen als volgt:

1. De notification-task bevat een authorization-base voor het ophalen van de workflow-task
2. De workflow-task bevat een authorization-base voor het ophalen van de onder Task.input genoemde resources

[willemsendennis]

Hi Jorrit, Thanks voor je comment. Ik had over het hoofd gezien dat het een optioneel veld is en inderdaad convenience...

Ander ding is inderdaad dat de auth-base in de NotificationTask nu verwijst naar de WorkflowTask credential, wat ik wel kan begrijpen qua flow, maar wat het wel een nare breaking change maakt voor iedereen die nog op de oude manier werkt en verwacht dat het een DID is naar de BGZ credential. Maar goed, dat is dan onderling afstemmen en zorgen dat iedereen het snel op dezelfde manier doet. Of je moet er inderdaad niet vanuit gaan en altijd zelf een search samenstellen.

Bij TWIIN zie ik nu deze pagina, niet echt een profiel en daar lijken ook fouten in te zitten (ook maar gemeld gelijk).

[jorritspee]

Hi Dennis, Ja we hebben het destijds bij het finaliseren van de spec in GitHub dat het dus stapsgewijs is. Je kunt natuurlijk altijd de inhoud van het CredentialSubject van de AuthzCredential inspecteren en daar zien voor welke resources die geldig is. Volgens mij hadden we bedacht dat het wel fijn is om de autorisatie van de workflow-task en de autorisatie van de bgz-resources onafhankelijk van elkaar te maken, dus 2 verschillende autorisatie-credentials. Dit is in lijn met hoe eOverdracht is geïmplementeerd.

[willemsendennis]

Bij nader inzien loop ik toch nog tegen het volgende aan:

Als de BGZ autorisatie credential in de WorkflowTask optioneel is (alleen convenience) dan zou ik de juiste ook moeten kunnen vinden. Maar als ik zoek met bijvoorbeeld:

{
  "query": {
    ...,
    "credentialSubject": {
      "id": "{didReceiver}",
      "resources": {
        "path": "/{resourceName}"
      }
    }
  },
  ...
}

dan krijg ik alle VCRs voor bijvoorbeeld /Consent (als voorbeeld resourceName) voor die issuer. Ik weet dan niet of ik de juiste heb voor de bevraging die ik wil doen, omdat ik ook de subject (BSN) nog niet altijd weet. Voor het vinden van de WorkflowTask is dat anders, dan kan ik zoeken op specifiek een workflow met identifier /Task/{workflowTaskId}, maar voor een BGZ credential heb ik niet iets om specifiek mee te zijn. De BSN weet ik op dat moment ook nog niet.

Als ik niet het juiste credential kan vinden door te zoeken, dan maakt dat de BGZ authorization-base dus eigenlijk verplicht in plaats van optioneel. Dat brengt mij tot de volgende 2 uitdagingen:

• Ons achterliggende systeem (EPD) weet op dit moment helemaal niets van Nuts en niets van autorisatie-bases. Dat maakt het ook interoperabel met bijvoorbeeld TWIIN en de TA NP.
• Er is een volgordelijkheidsprobleem; bij het aanmaken van de WorkflowTask heb ik nog geen autorisatie credential. Het BGZ credential wordt gemaakt op basis van de inhoud van de WorkflowTask. Deze issues zijn niet makkelijk op te lossen voor systemen die de notification en workflow loskoppelen van elkaar met een koppelvlak/GTK achtige opzet.

Ben nu toch alsnog benieuwd naar waarom deze wijziging in de spec nodig was. Wat was er mis met hoe het werkte? Hoe het werkte, zoeken naar de WorkflowTask credential op basis van /Task/{id} en vervolgens zoeken naar BGZ cred in de NotificationTask werkte prima in de uitwisselingen die we hebben gedaan met Tenzinger, Firely en Parsek...

[gasperr]

Hi,

disclaimer: I do not remember why we've changed this; but just to understand the issue:

Notification task now has a reference to VC of the Workflow task Workflow task now has a reference to VC of the BgZ items.

(receiver) When you get a notification, you read VC of the Workflow and use it to READ the workflow, then from the Workflow Task read the VC of the BgZ and then Query all BgZ items with that one.

(sender) Worfklow Task is created with attached ZiBs. You create a VC for those ZiBs and update the workflow task now referencing the BgZ VC.

Then you also create the notification task, after issuing VC for the Task/{workflow-id}

Can you point out what I've missed? Apologies if I lost it from your msg in translation.

[willemsendennis]

Hi,

Good idea to map the issue to the flow:

In general; the WorkflowTask was interoperable with other specifications (TWIIN TA and TA). Now it needs Nuts knowledge.

(receiver) interoperability issue When the receiving EHR wants to fetch a BGZ resource, it currently includes the authorization-base from the Notification to fetch resources; this is the case for TA NP and TTA NP. The EHR has no knowledge about NUTS NP, TA NP or TTA NP specifics. That is handled in an intermediate system. This change breaks interoperability. (and makes it hard for architectures to uncouple EHR and intermediate system) cardinality issue The spec defines the BGZ authorization-base as optional, which is not possible. As far as I know there is no way to query the credential with only the intended FHIR search and issuer. It will result in all BGZ credentials of the issuer.

(sender) coupling issue Our system (and I assume at least AORTA as well) have the EHR uncoupled from the service that handles Nuts specifics. The WorkflowTask is interoperable with TA NP, TTA NP and (the previous version of) NUTS NP. As you describe; the WorkflowTask now would need to be updated with Nuts specifics after the creating. Apart from the unwanted Nuts specifics, updating the WorkflowTask after creation with the authorization base creates several complexities in transactions and unhappy flows. implementation issue Currently in our implementation the WorkflowTask is only saved after the Notification has been succesfully send. This is naïve and not so robust (although the user will know immediatly that something is wrong) and will change in the future. Currently this makes it impossible to update the WorkflowTask in the same sending flow. Although this is something we want to change in the future, it would require quite some work because we would need to update the WorkflowTask based on the error scenario's and would force us to create the retry mechanisms when something goes wrong in the chain now (unplanned surprise). Technically not impossible, but label this as just a very inconvenient breaking change with major impact on our side (read expensive).

So to summarize: Apart from the cardinality issue, which I think is mistakenly labeled as optional in this newly introduced flow, This change creates interoperablity issues and a tight coupling issue, which was not necessary; it worked before. So in my opinion there must be a very good reason to introduce this, more than just 'convenience' in not having to query for the WorkflowTask credential.

I hope this elaborate description clarifies the issues I encounter :).