06 · Access
A grant proves someone was allowed. It doesn't prove they should be.
A security database records decades of permissions, many made for reasons nobody remembers. Treat it as evidence of what's permitted, then state who needs what, and why, in the Standard's terms.
At Tidewater
Same question, two security models.
Anchor Core's RACF protects datasets by profile and group. KeelTrack's IBM i protects each object. Neither one knows what a partner bank is.
PERMIT 'TW.PROD.PMTDUE.**' CLASS(DATASET) +
ID(LATEOPS) ACCESS(UPDATE)
PERMIT 'TW.PROD.PMTDUE.**' CLASS(DATASET) +
ID(TWAUDIT) ACCESS(READ)
GRTOBJAUT OBJ(KTLIB/COLLATPF) OBJTYPE(*FILE) +
USER(*PUBLIC) AUT(*CHANGE)
Check adopted authority too. A program compiled with USRPRF(*OWNER) runs with its owner's rights, whatever the caller has.
| Finding | What it means | Decision |
|---|---|---|
LATEOPS reaches every bank | The source had no bank boundary at all | Marcus Bell works across banks by design. Sam Whitfield gets only Granite Valley, enforced by Verified Permissions and row level security. |
16 IDs in LATEOPS, 4 active | Usage evidence covering a full year shows who really needs it | Twelve grants aren't carried forward |
BankLink uses one ID, TWWEB | RACF sees one user. Real access rules are inside the Java. | Extract those rules as evidence, as you would business logic |
*PUBLIC *CHANGE on COLLATPF | Anyone signed on can change insurance records. Nobody chose that. | Not carried forward, and the replacement product must not repeat it |
| A UACC of READ on old datasets | Anyone can read data that's now classified confidential | Classification decides protection, not the old setting |
What it becomes
Actors, skills and reasons.
Authorization is generated in the Standard, so nobody hand-writes policies here. A spec says who may act and why. The table below is the input a person reviews, and the source grant is only a citation.
| Actor | Example | May | Scope | Reason | Replaces |
|---|---|---|---|---|---|
| Tidewater analyst | Marcus Bell | Work late follow-up tasks (skill: late follow-up) | Across banks | Tidewater does this for its banks | LATEOPS |
| Bank operations | Sam Whitfield | See their bank's late payments; review its remittance exceptions | Own bank | A bank answers for its own customers | TWWEB, logic in Java |
| Loan officer | Elena Marsh | Request a payoff quote | Own bank | Borrowers ask their bank | TWWEB, logic in Java |
| Auditor | — | Read history | Across banks, read only | Audit obligation | TWAUDIT |
A skill isn't permission
The mainframe habit is that being in the group grants the access. In the Standard, a skill makes a worker a candidate for a task and never authorizes anything. The server checks authorization on every action.
Outside systems · at Tidewater
Partners get identities, not shared credentials.
Every permission rests on an identity, human or not. An outside system proves itself through a named identity provider, then assumes a role in one bank. Verified Permissions decides what that role may do, and OIDC is the minimum.
| Caller | Today | Provider | How it gets in |
|---|---|---|---|
| Clearing service, funding notices | An MQ channel into Anchor Core | clearing-svc | Assumes a role per bank, with each bank's grant |
| Harborside's file exchange | Connect:Direct | harborside-entra | Presigned upload to quarantine, for Harborside only |
| Pinecrest's staff | BankLink, as TWWEB | Not a system | People sign in |
| Tidewater calling a partner | Case by case | The partner's choice | Stated in the application's spec, with a design decision |
Delegation or impersonation
BankLink's TWWEB ID hides which person did what. In the new system the relationship is always explicit, including in history. A person can delegate part of their authority to a system. A system impersonating a person is denied by default, and never crosses organizations.
Rules
MIG-022 to MIG-024, MIG-041
- MIG-022
Source security grants are evidence of what was permitted, never a specification of what should be.
- MIG-023
Every access rule names an actor and a business reason.
- MIG-024
A source grant with no evidence of use across the business cycle is not carried forward without a person's approval.
- MIG-041
A shared technical ID or file-transfer credential is not carried forward; each outside system proves itself through a registered identity provider.