Missing section: no privileged positions?

[ChristopherA]

An important concept has been lost somewhere in the process from architecture to this implementation guide.

In many early documents, there was the concept that there were no privileged positions in our combined DID/VC architecture — in VC specs everyone explicitly could be an issuer, a subject, a holder, or a verifier, and there was at one point similar early language about no privileged positions in DIDs.

Yet I'm seeing in almost every POC lately that subjects and holders can't issue their own VCs, for instance, to self-certify or make claims about credentials that they hold, even if few will accept them. I know that there may be few business cases for this, but from an architecture perspective, toolmakers should at least make it possible that all parties can participate, even if ultimately you don't enable code for all variants.

Even as an implementor you don't enable certain subjects or holders to issue claims, making sure you think about it is important in your designs to future-proof yourself, and also to be able to look critically at potential single points of failure or single points of compromise.

-- Christopher Allen

[TallTed]

@ChristopherA — I think you're reading roles as identifying individuals, and possibly mis-aiming this Issue against DIDs rather than VCs, upon which your text seems to be focused.

So far as I know (and I haven't re-read everything today, so perhaps I've missed a change), a single Agent could act as each and every role in the VC architecture — acting as Issuer to Issue a VC about themselves as Subject to themselves as Holder, and then Verifying it as Verifier. In a sense, this (minus the Verifying) is what a Holder is doing when they construct a VP about themselves as Subject and Present it to a Verifier.

What am I (or you) missing? Maybe we just need some specific statement along these lines in the document(s), melding what I've written here with what you wrote when you opened this issue?

[ChristopherA]

@TallTed I do agree that I've not nailed the issue precisely enough for DIDs architecture implementation advice as opposed to VC architecture implementation advice, but I still find that as I look around at various recent POCs, that there there is a bias toward more powerful parties controlling the process, rather than allowing for more peer-oriented architecture.

This power bias can lead to re-centralization despite our goals to enable decentralization. (I'm not saying that power bias is bad, but more that without acknowledging this bias has its owns risks.)

I'm also not saying that developers need to enable things like more peer-to-peer DID functionality, more peer and self-signed VCs, etc. Instead, I'm saying that as they design their own systems that they should not rule them out. Not only does that offer some flexibility and future-proofing, in my opinion, it also opens one mind to some security and privacy issues that might not be obvious with more power-biased designs.

In any case, I not doing a great job expressing a recommendation for specific text for the implementation guide here. I'm more just bringing it up as something related felt absent with more power-biased Legally Enabled Self-Sovereign designs. I hope that someone can take up the banner and be inspired on some text to add some helpful advice.

[peacekeeper]

It's true that privileged positions exist not only on the VC layer, but also in many DID methods. E.g. to create a DID in Sovrin, you need a signature from a "Transaction Endorser". In the EU's EBSI project, you need to get a token from an "EBSI Onboarding Service". Etc. Even in permissionless blockchains like Bitcoin, you need to obtain coins, typically from an exchange or similar service (= also a privileged position) before you can create a DID.

The good thing is that different DID methods approach this differently, and I agree that implementers should not rule out support for systems that minimize those privileged positions.

[TallTed]

@ChristopherA — I think the best way to get the sort of text you want added, whether as a new section or as modification of an existing section, whether here in the DID Implementation Guide (which I think is a suboptimal target), or next door in the DID Rubric (which I think is likely the best target of the DID docs), or across the street in one or more of the VC docs, would be for you to submit a draft of that text as a pull request to each relevant doc. I think you're best suited to submit such initial draft/s, even if it's/they're extra-imperfect. What you've said here seems like it could be a good starting point....