Chapter 13 — Identity and access
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Authentication and authorization"]
N2["13.2 Keys as identities"]
N3["13.3 Roles for the voucher system"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Authentication and authorization"]
N2["13.2 Keys as identities"]
N3["13.3 Roles for the voucher system"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Authentication and authorization]
|
v
[13.2 Keys as identities]
|
v
[13.3 Roles for the voucher system]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) distinguish authentication and authorization; (2) manage keys as identities; (3) design roles for the voucher system.
13.1 Authentication and authorization
Authentication proves who someone is; authorization decides what they may do. On the cooperative's ledger, a member authenticates by signing a transaction with their private key, and the voucher contract authorises the action by checking rules, such as whether the member has enough vouchers. Off-chain, coordinators log in to the shift database with passwords and a second factor. Sofia notes that a blockchain address is an identity only as strong as the protection of its key. If someone else holds the key, the contract cannot tell the difference, so key protection becomes identity protection in this system.
13.2 Keys as identities
Each member's wallet holds a private key. Most members use a simple mobile wallet, and the cooperative offers a custodial option where volunteers hold keys for members who prefer not to manage them. Sofia lists the trade-offs: self-custody gives control but risks loss; custody is convenient but concentrates risk with the cooperative. For the treasury and minting keys she recommends hardware devices held by three different keyholders. She also plans recovery: if a member loses their key, the board can approve reissuing their balance to a new address after checking their identity in person at the shop.
13.3 Roles for the voucher system
Sofia designs roles. The minter role can issue vouchers and is held by a 2-of-3 multi-signature wallet. The pauser role can stop transfers in an emergency and requires two keyholders. The administrator role can change roles and is protected by a timelock so changes are visible before they take effect. Members can only transfer and spend their own vouchers. Each role has the smallest set of powers needed. The OWASP Smart Contract Top 10 lists access control failures among the most common contract weaknesses, so she documents each role and reviews the list with Dr Asante.
Worked example
Sofia assigns minting to a 2-of-3 multisig, pausing to two keyholders and administration behind a timelock, with in-person recovery for lost member keys.
Synthetic case. The roles and wallets are synthetic; the OWASP Smart Contract Top 10 is a real source.
Errors and limits
Treating a blockchain address as a person ignores that whoever holds the key controls it.
Exercises
- EX037 — Authentication on-chain. How does a member authenticate on the ledger? Rubric: 3 = by signing a transaction with their private key;; 2 = signing;; 1 = password;; 0 = none.
- EX038 — Custody trade-off. What is the risk of custodial wallets? Rubric: 3 = risk concentrates with the cooperative;; 2 = concentration;; 1 = vague;; 0 = none.
- EX039 — Administrator safeguard. What protects the administrator role? Rubric: 3 = a timelock that makes changes visible first;; 2 = timelock;; 1 = vague;; 0 = none.
Synthesis
Clear authentication, careful custody and least-privilege roles protect the voucher system.
Continue studying — chapter 13 of 40
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →