Ga naar inhoud

ADR-0030: Flow and subject identifier semantics as FSC grant properties

Why superseded

The regime does not need a declaration. The regime follows from the evidence that the request carries (ADR-0031):

  • A consent proof puts the request in the consent regime.
  • A request without a consent proof is in the PID regime.

After that change, no component read the flow property. The subject_id_type property also lost its reader. The source gateway takes the subject from the consent proof, and not from the contract (ADR-0033). The demo removed both properties. The following sections hold the original decision as history.

Context and problem statement

The PDP judges a request under an authorization regime. The regime has two parts: the flow, and the way to read the subject identifier (subject_id_type). The regime must be bound to the connection and signed, and the caller must not control it. ADR-0014 describes the mechanism that this ADR replaced.

Decision (superseded)

The decision put flow and subject_id_type as properties in the GRANT_TYPE_SERVICE_CONNECTION grant of the FSC contract (fsc-core, section Properties). It worked as follows:

  • The properties are inside the grant, so they are part of the grant hash. Both peers countersign the regime when they sign the contract.
  • The Manager of the provider puts the properties in the access token, as the FSC-normative prp claim.
  • The PDP request mapper reads the flow from prp only. It uses no header and no default.
  • If a token has no prp, the flow is empty. An empty flow matches no rule, so the PDP denies with NO_APPLICABLE_RULE.
  • The source gateway reads subject_id_type from the same claim.

The demo seeded three property sets:

Contract Properties
EDI issuer → data services (bri, brp) {"flow": "eudi:attestation", "subject_id_type": "direct"}
Mortgage lender (Hypotheek-BV) → bri {"flow": "dvtp:query", "subject_id_type": "pseudonym"}
EDI issuer → metadata services {"flow": "gbo:source-metadata"} (not subject-bound)

Consequences (at the time)

The decision had these consequences:

  • The provider needed no mapping file and no extra service. The contract was the single source of truth for the regime.
  • Contracts are immutable, so a regime change meant a new contract. The seed scripts matched on properties and moved the grant link to the new contract.
  • Every peer on a contract needed OpenFSC 2.0 or later. If the contract of a peer carried no properties, the PDP denied the peer until a new seed.
  • If subject_id_type was missing, the fail-safe default of the source gateway was direct (pass-through). If the flow was missing, the default of the PDP was deny. This difference was safe, because the PDP decided first.

Traceability

  • Requirements: REQ-74
  • Findings: F-32 (resolved in demo), F-43 (superseded), F-62 (resolved in demo), F-70 (open)
  • Open questions: Q-15 (answered)
  • Demo increments: SL-24 (dropped), SL-48 (done)