Re: When Technical Standards Meet Geopolitical Reality

> 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).

Yes, we're definitely on the same page here and this is a very succinct summary of what I was hoping to articulate. Thank you for taking the time to mull it over and find a way to put it into fewer words!

> 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.

That's definitely not what I'd like to see. I think the primitives grant us the flexibility we need to appropriately represent the proper power dynamics as they best suit. While I'm sure everyone of us enjoys the red herring debates around particular formats, method specific tradeoffs, and other technical debates the overall primitives are sound in my opinion.

This is the main takeaway I hope people can take away from this discussion is that the tools we build are ambivalent to how we use them, but we inherently will always express our values as we do. I just hope we all have the ability to reflect early enough to recognize when we're doing this and make sure to change as needed. If our tools are built correctly, this should be easier to do too. 

> 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.

Yup, exactly this. I think it's important to point out too, the only way I was able to reach that conclusion was by acknowledging the power dynamics of the use case. I had to first determine why it felt incorrect and then working backwards from what felt like a more accurate representation of how we model the problem from a first principles perspective. I hope others are able to achieve the same with their particular use cases.

> 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. :)

That's pretty awesome! I wasn't aware of the latest capabilities, but had assumed it was possible based on what I see can be done in Chrome OS. I suspect guardians having overriding capabilities will be a natural progression if guardians start finding these rules are overly restrictive. We'll see, the juries still out on this topic it seems.

> 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.

Yes, agreed I'd also add highlighting when they should be used too. For example, we probably don't really want a decentralized- reputation based model to decide who can drive a car even though I'd like to give a 1 star rating to some people when I'm driving down the road. :)

This will also likely help because we're not making morally assertions of "good" and "bad", but rather it comes off as "right for the use case". For example, centralization has it's benefits, but the tradeoffs are often too large when dealing with aspects that effect human rights. If we're talking about enterprise authorization systems, like what SSO solves centralization can still be fairly useful.

> 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.

++ I think it's always much easier to critique when we offer alternatives to be critiqued at the same time. It makes it more about deciding the best path forward, rather than coming off as "your work is bad, don't do that" which is rarely what we want to say. However, it's often how it comes off when we operate in these collaborative-competitive environments. I suspect this is why we got some of the responses we did with the phone-home PSA. I still catch myself getting this wrong, but I try to get better with each time I make the mistake again.

> 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)

Agreed, this is why I often come back to the question of "what are our shared values?". From there we can work upwards to decide the best technicals because the values proceed the technicals. I suspect this is also why we've ended up on the proposed age verification architecture today. It probably accurately reflects what those making the decisions actually want even if I don't agree with it.

> 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.

++ - I think as long as we make it possible (which I think we're doing a good job at it), then we've built the technology properly. The rest is to be decided by those who use it, and that's the paradox of building tech but not being able to fully prevent the unintended consequences of how it's used.

- Kyle

On Sunday, August 10th, 2025 at 6:38 AM, 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/

Received on Saturday, 9 August 2025 21:48:10 UTC