FinWave Japan本人確認のデジタル化に向けた新たな一歩💡
金融庁が #VerifiableCredentials を用いた実証実験結果を公表しました。マイナンバーカードを用いた認証でなりすましリスクの低減を確認。犯収法への対応など実用化に向けた検証が進んでいます✅
Doug BelshawInstead of static badge images, what if we used SVG radar charts as living views over Open Badges v3 / VC data, showing how practice is recognised across contexts and over time?
Featuring Open Recognition ideas and Serge Ravet’s Recognition Practices Occupational Framework.
https://blog.dougbelshaw.com/polygonal-badges/
#OpenBadges #OpenRecognition #VerifiableCredentials #DigitalBadges #SkillsRecognition
larinyoThe JWT ecosystem already uses this principle: IANA maintains a centralised registry of claim definitions — a semantics-linking mechanism.
@context achieves the same binding, but decentralised and domain-controlled. Which is what the rulebook model requires.
"Semantics are essential but linking credentials to their semantics is unnecessary" is a contradiction.
A recurring objection to my EUDI Wallet analysis: "Semantics come from rulebooks, not JSON-LD. @context is unnecessary."
I agree with the premise. Not the conclusion.
If vocabularies are in rulebooks, how does a credential tell a verifier which rulebook governs it? @context is a machine-readable link from the credential to its vocabulary. Not embedding semantics — linking to them.
EdTech companies, European EdTech Alliance, national associations:
Have Your Say on EUDI Wallet regs is open until early March. A clear contribution explaining that your products use W3C-VC, the regulatory gap affects market access, and linked data is essential for semantic interoperability — this carries weight.
Collective industry input amplifies individual voices.
Full analysis for reference: see my pinned post.
If your company builds credential issuance or verification on W3C Verifiable Credentials — the draft EUDI Wallet Implementing Regulations affect your product roadmap.
Three formats referenced: mdoc, SD-JWT VC, W3C-VC. Only the first two receive scaffolding — encoding tables, presentation profiles, issuance protocols, revocation rules.
W3C-VC: formally included, practically excluded.
Have Your Say open until early March.
#EdTech #EUDIWallet #eIDAS2 #VerifiableCredentials #OpenStandards
A critical gap: Token Status List (mandated for mdoc/SD-JWT VC) supports only permanent revocation.
Several Member States legally require suspension — temporary withdrawal with possibility of reactivation.
Bitstring Status List (W3C Recommendation, validated in EBSI/DC4EU) natively supports both revocation AND suspension.
Regulation 2024/1183 contemplates suspension. The Implementing Acts eliminate it.
#eIDAS2 #VerifiableCredentials #TrustServices #EUDIWallet #DigitalIdentity
Data Integrity with BBS cryptosuites enables native unlinkability — the strongest privacy-by-design pathway for verifiable credentials.
European cryptographers criticised the EUDI Wallet in 2024 for insufficient unlinkability provisions.
Annex XIV lists format identifiers for SD-JWT VC and mdoc. Nothing for ldp_vc/ldp_vp. BBS-secured W3C-VCs cannot be presented through regulated protocols.
I've submitted a detailed analysis to the European Commission's Have Your Say consultation on the EUDI Wallet Implementing Regulations.
Core finding: W3C Verifiable Credentials are formally referenced in the regulatory framework — but without the operational scaffolding to function.
Four asymmetries. Eight types of regulatory action needed.
Thread 🧵
#EUDIWallet #eIDAS2 #VerifiableCredentials #DigitalSovereignty #HaveYourSay #OpenStandards
Michael N. KingsnorthServerless SaaSless Networking: Building the Future Today
In the realm of serverless SaaSless networking, an architect doesn’t have to work in concrete. Some of us design networks.
Right now, the work I care about most is serverless, SaaSless networking: systems that run without a central point of truth and without a compulsory platform sitting in the middle. In other words, this approach builds the future today by making infrastructure that survives churn, pricing shifts, policy drift, and the sudden disappearance of a dependency everyone assumed would last forever.
Privacy follows from that choice. When the architecture stops funneling everything through a choke point, surveillance becomes harder, leakage becomes less likely, and “quiet repurposing” becomes far less tempting.
Cloud still has a place. However, forced dependence creates fragility.
A product that requires permanent permission from a third party isn’t really a product. Instead, it becomes a subscription to someone else’s stability.
What “serverless” and “SaaSless” mean in this context
Marketing turned “serverless” into a synonym for “someone else runs servers.” That model works for plenty of teams, yet it misses the deeper principle.
In this context, serverless means the network does not rely on a central server as the point of truth. Peers should discover each other, authenticate, exchange data, and recover without routing everything through a single authority.
Likewise, SaaSless means the core capability does not depend on an always-on subscription platform. Basic function should not sit behind tiers. Data should not live inside a proprietary dashboard with no clean exit. When a vendor can throttle, cut off, or reshape capability through closed APIs, control disappears.
That’s where architecture matters. It draws the line between a tool you own and a leash you tolerate.
A better metaphor than “roads versus theme parks” is public roads versus toll roads.
Public roads act as infrastructure. Anyone can use them, routes stay flexible, and no single company gets to decide who is allowed to travel. Toll roads can help too, but the experience changes the moment a gate sits in the middle. Then prices rise, rules shift, and access tightens. As a result, the journey starts depending on the operator’s incentives instead of the traveler’s needs.
That’s what SaaS-by-default networking creates. Movement still happens, but the gatekeeper sets the terms.
Why privacy becomes inevitable once the choke point disappears
Centralization attracts data. Then data attracts risk. Over time, risk becomes a breach email full of regret.
A privacy-first system takes a quieter path. It collects less, retains less, processes closer to the user, and reduces the number of places sensitive material can leak or be copied. Because of that, teams earn trust through engineering, not performance.
People don’t experience their lives as “data.” They experience messages, drafts, searches, locations, relationships, and decisions. So systems should treat those things with the seriousness they deserve.
Web3 identity, without the hype cycle
Web3 marketing created a mess, and the noise turns people off. Still, user-owned identity remains practical.
Most online identity works like a rental. Access can vanish. History can lock up. A policy change can turn an account into a liability overnight.
User-owned identity flips that relationship. A cryptographic anchor under the user’s control changes authentication from permission to proof. Additionally, it supports delegation, roles, and verification in ways auditors can check.
If a network aims to outlive trends, it needs identity built on owned ground, not rented ground.
Localized AI completes the design
Localized AI makes the whole approach feel coherent.
Privacy-first design does not pair well with exporting sensitive prompts to third-party model APIs by default. Instead, running models on-device, on-prem, or inside controlled infrastructure keeps private inputs inside a boundary you can actually defend.
The practical benefits show up fast. You get lower latency, predictable costs, and fewer moving parts. You also reduce exposure to training pipelines you cannot properly audit. Most importantly, the boundary stays intact, and thought stays close to home.
For that reason, localized AI belongs in the architecture, not as a bolt-on feature.
The future worth normalizing
Here’s the normal worth building:
- Identity stays portable.
- Data stays minimal and encryptable.
- Networks keep functioning when vendors disappear.
- AI runs locally for sensitive workflows.
- Audit trails stay verifiable, not vibes.
None of this requires utopian thinking. Instead, it requires disciplined engineering.
Call to action
Pick one place in your stack where a platform sits in the middle by default.
Then run three questions against it:
A single “yes” signals progress. Two points to direction. Three makes the future arrive early.
Privacy First. Security Always. Not as branding. As architecture.
If this resonates, share it with someone who builds systems for real users. Also, drop a comment with the one dependency you’d love to remove in 2026, or the one privacy-first change you plan to ship first. I read the replies and I’ll respond.
Key Takeaways
- Serverless SaaSless networking eliminates reliance on central authorities, allowing autonomy and privacy in data management.
- This architecture minimizes risk by decentralizing data collection and reducing points of possible leakage.
- User-owned identity enhances security, transforming authentication from permission-based to proof-based.
- Localized AI integration ensures sensitive data remains secure and allows for efficient processing without third-party dependencies.
- The article encourages assessing existing platform dependencies to foster a more privacy-focused and resilient system architecture.
