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.
IETF
A Token Status Bit Is Not a Revocation Timeline
A relying party reads one compact value and declines a credential. The decision may be correct. Yet the bit alone cannot say when the underlying state changed, who authorised that change, when the list exposed it, which cached copy was consulted or why this application treated…
History
The Target Added No Random Value. The Context ID Was Not a Bilateral Receipt: RFC 2025
A context identifier can look like proof that two peers jointly established something new. RFC 2025 makes the harder question unavoidable: whose fresh value actually went into that identifier?
IETF
The Channel Ended. The Claims Kept Moving: RFC 9781 and the UCCS Source Break
A verifier can receive an authenticated, integrity-protected claims set and still lose the basis for that assurance one function call later. RFC 9781 makes this boundary unusually concrete: tag 601 identifies an unprotected CWT Claims Set whose protection belongs to a channel…
IETF
The Header Found the Verifier. It Did Not Earn the Decision: RFC 9782
An API gateway can read `application/eat+cwt`, select a handler and produce a clean routing log before anyone has established what the bytes contain. RFC 9782 makes that first step interoperable. Its importance lies equally in what it refuses to collapse: a media type can name a…
IETF
The Message Had One Security Badge. Its Layers Did Not Share One Status: RFC 9787
The comforting part of an encrypted-mail interface is the badge. The difficult part is deciding exactly which bytes are entitled to it. RFC 9787 makes that boundary explicit: one received message gets one cryptographic summary, calculated only from the contiguous protection…
Global Cloud Services Trends
Orchid Security's agent kill switch needs an outcome test
New identity controls promise a way to intervene when AI agents stray beyond their remit. Buyers still need to distinguish a recorded response from evidence that the relevant authority has actually ended.
History
Before Email Could Be Signed, the Gateway Had to Stop Editing It: RFC 2015
A mail gateway could preserve every sentence a person cared about and still destroy a digital signature. RFC 2015 made that uncomfortable fact part of PGP/MIME's design: the evidence was not an abstract message but an exact MIME entity—content headers, transfer encoding…
IETF
The Hidden Service Answered. The Onion Key Had Not Yet Spoken: RFC 9799
The hidden service answered over Tor, the ACME account was valid, and the final CSR was ready. None of those facts yet proved that the applicant controlled the `.onion` identity. RFC 9799 makes that missing proof explicit—and shows why issuance authority, descriptor visibility…
History
The Message Opened. That Did Not Mean the Evidence Was Complete: RFC 1991
An early PGP message could pass through six visibly successful operations—ASCII decoding, packet parsing, session-key recovery, decryption, decompression and signature verification—without any one of them proving who controlled the key, when the act occurred, whether it was…
History
The Certificate Was Public. The Private Key Was Not: RFC 1984’s Trust Boundaries
In July 1996, two Internet standards bodies accepted that a government could operate a certification authority and still rejected the idea that a government, or any other third party, should hold a user’s private key. That is not a contradiction. It is the organising distinction…
IETF
A Workload Credential Is Not the Workload: Eight Proofs Between Bootstrap and Outcome
The WIMSE practices draft shows how platforms can replace embedded secrets with short-lived workload credentials. Its harder lesson is that every safer credential still sits inside a longer chain of facts that must not be compressed into one green authentication event.
IETF
Jim Schaad and the Key ID That Was Only a Hint
Two keys sit in the same verifier under the same short label. The message supplies that label, the first key is tried, and a dashboard turns the result into the name of a device. Jim Schaad’s COSE specification draws a harder boundary: the label is a search hint; identity and…
IETF
Patrik Fältström and the ENUM Answer That Did Not Complete the Call
The number resolved. A signed DNS answer yielded a URI. The phone still never rang. Patrik Fältström’s work on ENUM is most useful when those three facts remain separate.
IETF
David Harrington and the SNMP Context That Did Not Identify the Operator
The command named an engine, a context and an entity with precision. None of those fields said which human had chosen the change. David Harrington’s SNMP architecture makes that absence visible rather than filling it with an assumption.
IETF
Revision 36 Turns Voucher Renewal Into a Control Decision Without a Decision Receipt
A short-lived onboarding voucher looks like a credential with a new end date. Revision 36 of the IETF's Voucher Artifact draft now makes the deeper operation explicit: renewal confirms that an earlier relationship still holds, checks continuing access to a Domain key, consults…
IETF
Bernard Aboba and the EAP Method That Did Not Grant Network Access
The credential was valid and the authentication method finished cleanly. Yet the controlled port stayed closed. Bernard Aboba’s work on EAP explains why those two observations can coexist without contradiction.
IETF
Chris Newman and the Secure Mail Port That Did Not Authorize a User
Port 465 can require the conversation to begin with TLS, but it cannot decide who may send a message. Chris Newman’s work on secure mail access shows why transport, service identity, user authentication and authorization need separate receipts.
History
The Ticket Arrived. The Receipt Did Not: RFC 1964’s Authentication Boundaries
RFC 1964 gave Kerberos V5 a disciplined GSS-API wire vocabulary: a mechanism identifier, typed tokens, a digest for caller-supplied channel bindings, service flags and an optional delegated credential. The design is valuable precisely because each item stops at a boundary. A…
IETF
The Principal Signed the Delegation. The Issuer Still Bound the Agent Key
Two valid signatures can sit in one credential without answering the same question. A new AIC-JWT revision puts the principal’s authorization inside an issuer-signed token, yet draws a precise line between the Agent identity the principal authorized and the proof-of-possession…
Story
RIPE Database 1.124.1 Fixed Certificate Selection. Its “No Evidence” Finding Needs a Search Boundary
RIPE NCC was right to ship a reported authentication vulnerability without waiting for a routine test interval. The next duty is different: show members what time, traffic and registry history were actually examined before “no evidence of exploitation” became the public…