Topic
Digital Identity and Credentials
Within the Topic facet, Digital Identity and Credentials topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
History
The Server Did Not Need the Plaintext. It Still Controlled Availability: RFC 3157
In August 2001, RFC 3157 asked how one cryptographic identity could follow a user or router from one device to another. Its answer began with confidentiality but did not end there. A credential server might store an entity it could not use as plaintext and still decide whether…
Story
RIPE NCC is changing the RPKI key. The harder question is what it can touch
RIPE NCC is moving its RPKI dashboard and API credentials towards OpenID Connect. The more consequential disclosure sits lower on the same planning page: a proposed routing beacon was held back because its API could edit ROAs across all RIPE NCC space. Together, the two items set…
History
The Server Needed a Third Challenge: RFC 3163
The extra random value in RFC 3163 was not decorative. In its mutual-authentication mode, it addressed an asymmetry created by the order of the exchange: the client chose its own nonce only after it had already seen the server's first challenge. The fix was narrow, and so were…
IETF
The Envelope Was Signed. The Detached Ciphertext Was Outside the Signature.
The verifier returned green, the COSE entity was intact and the recipient decrypted a plausible message. None of those facts, alone, proves that the separately stored ciphertext was inside the outer signature. Detached content turns a neat security diagram into a custody problem…
IETF
The Calendar Called Them the Owner. It Had Not Granted Control.
A portable calendar record can call a entity an owner without making that person an authorized editor. The label describes a role; the exchange protocol still decides who may reschedule the event, change its entities, or send an update in its name.
IETF
The Redirect Succeeded. The Credential Had Already Crossed in Plaintext.
The final URL was HTTPS, the API returned useful data and every dashboard showed green. Yet the credential had already travelled in the first cleartext request. A redirect can repair where the client goes next; it cannot recall bytes the network has already seen.
IETF
The Chain Validated Against the Anchor It Carried. The Relying Party Had Not Trusted It.
The did:x509 resolver can finish every check it was asked to perform and still leave the decisive question untouched. A supplied certificate chain may be internally valid, its CA fingerprint exact and its leaf predicates true, while the relying party has not yet accepted the…
History
Long-Term Proof Had to Outlive the Key: RFC 3126
RFC 3126 treated an old signature as an evidence-preservation problem. A valid calculation made in 2001 would not explain itself decades later if certificates, revocation records, exact signed bytes or trustworthy algorithms had disappeared. Its answer was a ladder of timestamps…
IETF
It Opened the Handshake. It Still Needed the Group's Memory.
An MLS external receiver can open the same commit or proposal seen by group members and still lack the state needed to authenticate who sent it. The missing receipt is not more ciphertext. It is the current GroupContext that joins an epoch, a sender leaf, a credential and an…
History
A Valid Signature Still Needed a Policy: RFC 3125
RFC 3125 tried to make the rules around an electronic signature addressable as data. A correct cryptographic calculation remained only the first gate: validity under a transaction still depended on which policy bytes were referenced, which commitments and trust conditions…
IETF
The Active Key Signed Its Successor. That Was the Problem.
A signature can show that the key accepted by yesterday’s policy approved a change. It cannot answer the harder question: should that key, acting alone, have been allowed to decide every key that will control the identifier tomorrow?
IETF
The AS2 Names Matched. The Signer Was Still a Local Decision
A certificate rollover can leave every visible signal green—TLS connected, names reflected, signature valid, MIC matched—while one decisive fact remains outside the protocol transcript: who authorized this key to speak for this partner, in this direction, now?
Asia-Pacific Institutional
TrueMoney's Scale Claims, Audited Against Its Own Paperwork
The TrueMoney wallet is the consumer face of Ascend Money, the fintech owned by Thailand's CP Group, and the directory entity Truemoney Company PLC is the card that tracks it. Previous reporting, including BTW's own account of the virtual-bank approval path published 30 September…
IETF
The Voucher Promised Another Voucher. Renewal Had Not Happened.
ANIMA's current onboarding draft gives a MASA room to project how long it expects to renew a device Voucher. Revision 36 also makes the later gates clearer. The projected date is still not a replacement artifact, a service-availability receipt or proof that the device completed…
IETF
The Draft Removed Two HPKE Modes. Running Code Did Not Disappear.
The proposed HPKE replacement reserves the two mode values that RFC 9180 used for Auth and AuthPSK. That is a clear standards decision; it is not an inventory of libraries, profiles, stored entities or counterparties that may still depend on the older compatibility set.
IETF
The Proxy Authenticated the User. It Did Not Authenticate the Source MAC
A green tunnel indicator can be perfectly accurate and still conceal the most important unresolved question: which Layer 2 identities may the authenticated user introduce into the remote broadcast domain? CONNECT-ETHERNET draws that boundary sharply. HTTP can establish the…
IETF
The Server Returned the Old Object. It Did Not Return an Audit Trail.
JMAP Entity History proposes a practical way to recover previous and destroyed entity versions. Its own rules also explain why retained snapshots cannot prove every change, its actor, its authority or its outcome.
IETF
The Client Named a Trust Anchor. It Did Not Promise to Trust It
A server can follow a client's certificate-path hint exactly, send the path that the hint appears to request, and still watch the handshake fail. That is not a contradiction in the proposed TLS trust-anchor negotiation. It is the design's most important boundary: the client is…
IETF
The Exporter Produced 128 Bytes. It Did Not Bind the Token Holder to the Tunnel.
Revision 04 of EAP-PPT deletes an output that looked like inner-method keying material. The correction matters because a tunnel exporter can produce bytes without proving that the same party both terminated the tunnel and possessed the bearer token.
History
The Password Had No Directory Entry to Change: RFC 3062
In 2001, LDAP's ordinary edit operation could not reach every password. RFC 3062 introduced a separate password-change request that could target a session's user or a non-DN identity, even when the credential lived outside the directory. Its success rule was strict; its view of…