Re: When Technical Standards Meet Geopolitical Reality

All sensible thoughts. One architecture to consider puts a holder-chosen
mediator or notary between the verifier and the issuer.

- Adrian

On Sat, Aug 9, 2025 at 2:40 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Sun, Jul 20, 2025 at 8:29 PM Pryvit NZ <kyle@pryvit.tech> wrote:
> > Thanks Manu for the long post in response. I’m responding in line to try
> and break it down a bit more, but as usual I tend to over author things a
> bit so apologies to everyone for another long post.
>
> Hey Kyle, I did read your entire post when you sent it, then spent a
> week thinking about it, then read it again, thought about it some more
> over the following weeks, and re-read it just now before responding.
> Thank you for taking the time to write up your thought process and a
> suggested alternative architecture. I think I more clearly understand
> some of the points you are making now.
>
> If I had to summarize the core of your message, you're suggesting that
> we have over-optimized for large government issuers and have therefore
> further entrenched traditional power dynamics (that some in this
> community don't like). You are saying that when we identify use cases
> that we want to address, we need to focus on the power dynamics
> created by the solutions. Does it shift too much power and authority
> to the issuer, a guardian, the holder, or the verifier? You're
> suggesting that we need to explore architectures that don't
> over-optimize for the issuer, and then you used an example with age
> verification where we put the decision making power in the hands of a
> guardian (the parent) instead of the verifier (the website).
>
> Is that somewhere in the ballpark of understanding what you are saying?
>
> If so, I can agree that approaching use cases and solutions in that
> way is a useful thing to do.
>
> What I was thinking that you and Christopher were saying was something
> along the lines of: Decentralized Identifiers are broken and we should
> abandon them. Verifiable Credentials are broken and we should abandon
> those too... and so on. When I think what you're saying is that we
> need to reevaluate how these primitives are put together into a
> functioning architecture; specifically, what credentials are issued by
> whom and who depends on those -- decentralize the issuers, if
> possible.
>
> To get back to the age verification use case, you're saying -- don't
> put the onus on the site operator to make the final decision, put it
> on the parent/guardian so they can make the choice that is best for
> their child and not defer that authority to the verifier (because
> they're never going to be able to make choices that are that
> personal). Again, that's a fair point and architecture.
>
> You might be interested to know that I just went to my kid's
> back-to-school night and the IT department has a new offering for
> parents -- you can hand-edit the filtering rules for your specific kid
> now, which is the model you suggested. However, you also cannot turn
> off the base filters that the school has -- too much liability for the
> school in doing that. These filters follow your kid home on their
> school-issued laptops. :)
>
> Coming back to the work this community is doing -- it is true that
> we've created many of these primitives without taking a strong
> position in the specification about how these technologies are
> composed together. I do think we've taken strong positions about "no
> phone home" (when other communities have not), and have written
> normative text around that when there is consensus. So, there are some
> architectures (such as the two-party model) that this community has
> identified as "clearly bad" in certain situations... but every time
> some of us try to write something about that, we're blamed for
> "attacking the motives" of other communities in the digital credential
> ecosystem. Some of the responses and blog posts to the latest "no
> phone home" initiative are a good example of this.
>
> So, what can we do?
>
> We can focus on labeling good architectures; that shouldn't be
> controversial (but might be ignored).
>
> We can focus on calling out bad architectures, but should be ready for
> negative press every time we do that -- the removal of Server
> Retrieval from mDLs, if it sticks, will be a demonstration that we can
> do that if we're willing to endure the initial negativity around the
> effort.
>
> Most of all, we have to focus on putting better alternatives on the
> table, with clear deployment paths to large scale production and
> adoption and then follow through on it. Anything else is just wishing
> for a future that will never come because we didn't figure out the
> proper incentives that would cause the societal change we want to see.
>
> While I don't see how we shift issuing power away from governments to
> individuals at scale any time soon (without the citizenry changing how
> those institutions operate within their society), nor do I think
> that's a good idea in all cases (e.g., any teenager can drive a ton of
> metal around as long as their parents say so), I do think ensuring
> that the technological primitives and architectures we create and
> standardize enable more issuer decentralization (if society wants to
> go in that direction) is a worthy goal, among many.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>