Ga naar inhoud

ADR-0034: An integrator connects under FSC delegation, and the consent binds the represented party

Context and problem statement

A consumer (afnemer) can let a software party, the integrator, call the source for it. The consent binds a consumer. The policy compared the dienstverlener_oin of the consent with the FSC peer that calls. An integrator breaks that assumption (F-73). The integrator calls, but the citizen gave consent to the consumer.

The integrator acts as processor for the consumer (Q-12, AV-06). The integrator must not get access of its own. It must act only for the consumers that registered it (REQ-106).

Decision

The decision has four parts:

  • Transport. The integrator connects over an FSC DelegatedServiceConnection grant (grant type 3). The consumer is the delegator and signs the contract.
  • Contract admission. The contract decision of the source admits a delegated grant only if the admission register has that integration. If not, the decision refuses with DELEGATION_NOT_REGISTERED (ADR-0015).
  • Mandate. The admission register records per integrator the consumers and the rules that it acts for (integrations, pulled into OpenFTV as acts_for). At request time, every delegated call needs a mandate for the represented party and the granting rule:
    • If the mandate is missing, the engine denies with INTEGRATOR_NOT_REGISTERED.
    • If the register data is missing, the engine denies with INTEGRATOR_REGISTER_UNAVAILABLE.
    • The engine applies this check to every rule. No rule can leave it out.
  • Consent binding. The consent binds the represented party. That is the FSC delegator, or the calling peer if there is no delegator. The consent gives the integrator no mandate.

Considered options

  1. FSC delegation plus a mandate in the admission register (chosen).
  2. The integrator calls with its own direct grant. The source then sees only the integrator. Either the consent binding fails, or the integrator gets access of its own.
  3. The integrator in the consent proof. With this option, the citizen also consents to the integrator. FR-DvTP v0.9 does not ask any more to tell the citizen about the integrator. It stays open whether the proof names the integrator (Q-46).
  4. No integrator role (the earlier TO). Real consumers use software parties, so the design must say how they connect (F-20).

Consequences

  • The integrator gets a separate admission and acts as processor (AV-06).
  • In demo v0.9.0, a mandate has no validity period. It ends only when the register entry changes.
  • The admission register is also a request-time input, in addition to a contract-time input. A suspended consumer with a valid contract can still query directly. REQ-110 covers that gap.
  • OpenFSC puts the delegator in act.sub and the connecting peer in sub. That is the reverse of RFC 8693. The demo reads the values as OpenFSC writes them. An upstream issue is due.
  • The autosign input has no grant data. For this reason, the contract decision admits the pair, but not the direction of the delegation. The mandate check at request time closes that gap.
  • In the demo, the path is opt-in (make demo-integrator, peer …1100).
  • One point is open: can policy read the FSC Peer ID as the OIN of the consumer (Q-68)?

Traceability