eduKateSG · Why Science?
Carry verifiable research attributes between trusted systems—without turning one token into unlimited scientific permission
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. GA4GH Passports are signed digital documents that carry researcher attributes and permissions as one or more Visas. GA4GH lists Passports as current with Active Engagement and v1.2, approved on 13 January 2023, as the last approved version. A Passport claim can contain multiple independently issued and independently expiring Visas. Standard Visa types cover affiliation and role, accepted terms and policies, controlled-access grants, researcher status and linked identities. A relying service evaluates those assertions under its own trust and access policy. A Passport is not a travel document, a central identity database, a guarantee of access, legal advice or proof that a proposed analysis is scientifically sound. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: GA4GH Beacon v2 and federated genomic data discovery; GA4GH Data Repository Service and portable data access; GA4GH Workflow Execution Service and portable workflows; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Passports product page, current v1.2; Official GA4GH Passport and Visa specification v1; Official GA4GH Data Use and Researcher Identities repository; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, service interfaces and recommendations can change, so preserve the dated documentation and versions used.
A deeper reading route
A GA4GH Passport is best pictured as a secure folder of signed research credentials, not as a master key. Each Visa says something bounded: this organisation asserts a role, this authority records a controlled-access grant, or this service confirms acceptance of a policy. The receiving service verifies the signature, issuer, time limits and meaning, then applies local rules. Portability comes from a shared claim format; authority still comes from trusted issuers and policy.
The separation between Passport and Visa keeps evidence granular. The Passport claim can bundle multiple Visas for transport, while every Visa has its own type, value, source, asserted time and cryptographic envelope. One can expire or become irrelevant without rewriting every other assertion. That design mirrors good science: preserve individual pieces of evidence and the organisation responsible for each claim instead of collapsing them into one unexplained approval flag.
Controlled access is a decision process, not a token-reading trick. A data service may check whether a Visa names the right dataset or access committee, whether terms are current, whether the researcher has an acceptable status and whether the planned use matches policy. A technically valid signature proves integrity and issuer control of a key; it does not prove that the issuer is trusted for every claim or that the requested action is allowed.
Privacy improves when the Passport carries only attributes needed for a decision. Full identity documents, CVs and unrelated personal details should not travel simply because a system could include them. The specification supports linked identities and affiliation claims, but implementers still need data minimisation, secure transport, short exposure, restricted logging and careful user interfaces. A portable credential should reduce repeated disclosure, not multiply it.
Expiry and revocation require separate thinking. A Visa contains time information and can expire independently, but urgent withdrawal may need a trust framework, clearinghouse or local deny decision beyond passive expiry. Services should fail safely when keys cannot be resolved or an issuer is unknown, while preserving enough audit detail to explain a denial without leaking the Passport to unauthorised observers.
For students, Passports create a friendly analogy to permission slips. A signed slip can state who issued it, what activity it covers and when it ends, but the laboratory teacher still checks whether today’s activity fits. The analogy helps separate identity, evidence, permission and scientific responsibility—four ideas that are often blurred in online systems.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Issue | Who asserts which bounded attribute? | Signed Visa, type, value, source and time | A verifiable claim |
| Carry | How are several claims presented? | Passport claim containing multiple Visas | A portable evidence bundle |
| Decide | Does local policy permit the request? | Trust, scope, expiry and purpose checks | An allow or deny decision |
| Audit | Can the decision be explained safely? | Issuer, policy, time and decision record | Accountable controlled access |
Inside this guide
1–12 · Foundations and design
- 1. Start with a bounded access question
- 2. Understand the current product
- 3. Separate Passport from Visa
- 4. Read the signed token boundary
- 5. Identify issuer and subject
- 6. Check expiry for every Visa
- 7. Read the Visa object fields
- 8. Use source as provenance
- 9. Treat the asserted time precisely
- 10. Understand standard Visa types
- 11. Read affiliation and role narrowly
- 12. Read researcher status narrowly
13–24 · Models and estimation
- 13. Record accepted terms and policies
- 14. Evaluate controlled-access grants
- 15. Use linked identities cautiously
- 16. Evaluate conditions as written
- 17. Ignore unknown custom types safely
- 18. Verify signatures and keys
- 19. Plan key rotation
- 20. Check audience and token use
- 21. Use a clearinghouse carefully
- 22. Apply least privilege
- 23. Plan revocation beyond expiry
- 24. Minimise identity disclosure
25–36 · Diagnostics and interpretation
- 25. Protect logs and interfaces
- 26. Separate access logs from Passports
- 27. Keep policy local and explicit
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready access report
- 35. Build a validation ladder
- 36. Finish with an auditable bundle
Section 1 of 36
1. Start with a bounded access question
A service should ask which person, dataset, action and research purpose are in scope. “Has a Passport” is too broad to be an access policy.
Working checkpoint — GA4GH Passport: Write the exact requested action and governing policy. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 2 of 36
2. Understand the current product
GA4GH lists Passports as current with Active Engagement and identifies v1.2, approved on 13 January 2023, as the last approved version.
Working checkpoint — Visa: Record the specification and trust-framework versions. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 3 of 36
3. Separate Passport from Visa
A Passport claim transports multiple Visas; each Visa is an independently issued assertion with its own meaning and lifetime.
Working checkpoint — signed assertion: Inventory the Visas rather than treating the bundle as one credential. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 4 of 36
4. Read the signed token boundary
The model uses JSON Web Tokens so issuers can sign claims and relying parties can verify integrity. Token validity is only one gate in authorisation.
Working checkpoint — controlled-access grant: Verify algorithm, signature, issuer and time claims before policy evaluation. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 5 of 36
5. Identify issuer and subject
The issuer identifies the authority signing the assertion, while the subject identifies the person or entity to whom it applies. Confusing them reverses responsibility.
Working checkpoint — trust framework: Store issuer and subject with the decision record. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 6 of 36
6. Check expiry for every Visa
Each Visa can expire separately. A fresh Passport wrapper cannot make an expired underlying assertion current.
Working checkpoint — least privilege: Evaluate time claims at the moment of each request. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 7 of 36
7. Read the Visa object fields
The Visa claim includes a type, asserted time, value and source, while the JWT envelope supplies standard token context. Every field contributes to interpretation.
Working checkpoint — GA4GH Passport: Validate both token structure and Visa-type rules. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 8 of 36
8. Use source as provenance
The source points toward the authority or process behind a Visa value. It helps a relying party understand where the assertion originated.
Working checkpoint — Visa: Resolve source through an approved trust framework. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 9 of 36
9. Treat the asserted time precisely
The asserted timestamp records when an issuer made the claim, which is not always the same as the start or end of permission.
Working checkpoint — signed assertion: Distinguish assertion, issuance and expiry times. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 10 of 36
10. Understand standard Visa types
The specification defines standard types for affiliation and role, controlled-access grants, accepted terms and policies, researcher status and linked identities.
Working checkpoint — controlled-access grant: Use the type whose semantics match the evidence. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 11 of 36
11. Read affiliation and role narrowly
An affiliation Visa can describe an institutional relationship and role. It does not automatically confer access to every dataset held by that institution.
Working checkpoint — trust framework: Map only approved roles to specific policy conditions. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 12 of 36
12. Read researcher status narrowly
A ResearcherStatus Visa can communicate a defined status assertion. It is not a universal judgement of competence, ethics or scientific merit.
Working checkpoint — least privilege: Document which issuer and status values local policy accepts. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 13 of 36
13. Record accepted terms and policies
An AcceptedTermsAndPolicies Visa can indicate that specified terms were accepted. Terms can change, and acceptance does not replace enforcement.
Working checkpoint — GA4GH Passport: Pin the policy identifier and version. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 14 of 36
14. Evaluate controlled-access grants
A ControlledAccessGrants Visa can carry a grant from a responsible authority. Scope, dataset, purpose and expiry still need exact interpretation.
Working checkpoint — Visa: Match the grant value to the requested resource and operation. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 15 of 36
15. Use linked identities cautiously
LinkedIdentities can help connect accounts recognised by different systems. Linking increases convenience but can also increase privacy and correlation risk.
Working checkpoint — signed assertion: Link only necessary identities with approved evidence. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 16 of 36
16. Evaluate conditions as written
Visa values can encode conditions whose logic must be interpreted consistently. A client should not silently weaken conjunctions or alternatives.
Working checkpoint — controlled-access grant: Test each condition branch with allow and deny fixtures. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 17 of 36
17. Ignore unknown custom types safely
The specification requires unrecognised custom Visa types to be ignored rather than misinterpreted as a familiar permission.
Working checkpoint — trust framework: Log unsupported types without granting access from them. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 18 of 36
18. Verify signatures and keys
A signature shows that token bytes were signed by a key. The service must still obtain the correct key and decide whether its owner is trusted for that claim.
Working checkpoint — least privilege: Use trusted key discovery and planned rotation. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 19 of 36
19. Plan key rotation
Issuers need to rotate signing keys without breaking legitimate access or accepting retired keys indefinitely. Cached keys and overlapping validity need clear rules.
Working checkpoint — GA4GH Passport: Test new, old, missing and compromised-key scenarios. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 20 of 36
20. Check audience and token use
Tokens should be used only by intended relying services and through the correct protocol. Replaying a token at another audience can leak attributes or gain unintended access.
Working checkpoint — Visa: Validate audience and bind tokens to the authorised flow. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 21 of 36
21. Use a clearinghouse carefully
A Passport clearinghouse can help collect or validate Visas, but it becomes a sensitive trust and availability boundary.
Working checkpoint — signed assertion: Document what it verifies and what the data service still decides. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 22 of 36
22. Apply least privilege
An access decision should grant only the data and operations needed for the approved purpose. Broad convenience permissions magnify mistakes and token theft.
Working checkpoint — controlled-access grant: Issue narrow scopes with short, reviewable lifetimes. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 23 of 36
23. Plan revocation beyond expiry
Expiry handles ordinary time limits, while urgent withdrawal may require deny lists, issuer updates or local policy changes.
Working checkpoint — trust framework: Test how quickly a withdrawn grant stops working. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 24 of 36
24. Minimise identity disclosure
The specification discourages carrying identity information unnecessary for access. More personal detail is not stronger authorisation.
Working checkpoint — least privilege: Transmit the smallest adequate set of Visas. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 25 of 36
25. Protect logs and interfaces
Passport tokens and claims can expose affiliations, grants and linked accounts. Debug logs, browser histories and screenshots can become data leaks.
Working checkpoint — GA4GH Passport: Redact tokens while retaining a safe decision trace. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 26 of 36
26. Separate access logs from Passports
An audit should record who requested what and which policy decided it without copying the entire reusable credential into every system.
Working checkpoint — Visa: Store references and bounded decision facts where possible. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 27 of 36
27. Keep policy local and explicit
Portable claims support federation, but each relying service remains responsible for local law, agreements, data-use policy and operational controls.
Working checkpoint — signed assertion: Version the policy engine and its rule set. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A permission slip identifies the activity, issuer and date, but it does not prove that an experiment was carried out safely or correctly.
Working checkpoint — controlled-access grant: Use fictional school activities and no real identity data. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 29 of 36
29. Connect to Secondary Science
Research ethics joins consent, data governance, fair access and reproducibility. Digital credentials support those responsibilities without replacing them.
Working checkpoint — trust framework: Separate a signed assertion from an ethical judgement. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 30 of 36
30. Connect to mathematics
Boolean conditions, sets, time intervals and trust graphs make authorisation rules inspectable. A single false condition can change the decision.
Working checkpoint — least privilege: Draw the rule and test boundary times. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 31 of 36
31. Connect to computing
JWTs, signatures, key discovery, federation, scopes and audit logs show how cryptography and policy meet real research systems.
Working checkpoint — GA4GH Passport: Test expired, altered, wrong-audience and unknown-issuer tokens. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Section 32 of 36
32. Connect to pathways
Research identity systems connect science, cybersecurity, law, ethics and data governance and can illuminate STEM pathways.
Working checkpoint — Visa: Check current official qualifications and role requirements separately. Read every signature beside key provenance, issuer authority, audience, scope and the requested operation.
For future study, connect research access to computing, ethics and cybersecurity while checking official pathways separately.
Section 33 of 36
33. Did you know?
A Passport can contain several Visas that expire independently, so one outdated assertion need not erase every other valid piece of evidence.
Working checkpoint — signed assertion: Evaluate every Visa rather than trusting the wrapper age alone. Preserve denials, unknown types and expired claims; a successful request is not the complete access history.
For scientific writing, describe the trust and policy decision without publishing reusable tokens.
Section 34 of 36
34. Write a reader-ready access report
Name Passport and implementation versions, relying service, Visa types and issuers, policy version, requested action, outcome and time.
Working checkpoint — controlled-access grant: Exclude reusable tokens and unnecessary personal details. Separate token validity and portable attributes from local policy, ethics review and scientific suitability.
For students, ask who issued the permission, what it covers and when it ends.
Section 35 of 36
35. Build a validation ladder
Validate structure, signatures, issuers and time; test policy scope and revocation; review privacy and logs; then authorise a minimal fixture.
Working checkpoint — trust framework: Fail closed at the earliest unresolved trust layer. Treat issuer, source, policy and dataset identifiers as security-critical inputs: a silent mismatch can overgrant access.
For parents, ask which personal details are truly necessary for the access decision.
Section 36 of 36
36. Finish with an auditable bundle
Deliver trust anchors, key and policy versions, redacted test tokens, allow-and-deny fixtures, decision logs, revocation tests and governance approvals.
Working checkpoint — least privilege: Make every decision explainable without exposing the credential. Keep issuer, subject, Visa type, value, source, assertion time, expiry and policy decision together.
For a classroom model, use fictional permission slips and never real credentials.
Contents · Previous section · Continue to the Science Learning Hub