PSP2 - Substrate Uniform Resource Identifier

[xlc]

Please allow me to create this to discuss PSP2 - Substrate Uniform Resource Identifier

https://github.com/w3f/PSPs/blob/master/PSPs/drafts/psp-2.md

[xlc]

https://github.com/paritytech/xcm-format uses relative path to address assets so we may want to adjust PSP2 to remove the absolute path part.

[olanod]

I don't have a lot of context to give in depth opinions but when I see something related to resource identifiers in a decentralized world It immediately raises the flag to mention Decentralized Identifiers(DID). I would say is quite mature as a standard now and it should be the way to identify anything in the future.
A DID could look something like did:polka:chain1 where the method polka refers to the verifiable-data-registry(the relay chain?) that resolves the DID into a DID document that has the relevant information of that resource(parachains in this case?). DID urls can have paths, query, fragments so is quite flexible the possibilities of how a service of a resource can look like. Not expert in the DID subject but is my understanding that something like this is possible? did:polka:chain1/acount123/assets?id=FOO#balance

[burdges]

As a rule, the W3C is quite incompetent and represents interests opposed to what we exist to do. It's worth understanding their documents of course, because some parties contribute technical understanding, but one should focus on understand why they do what they do, and one should not ask how do we fit our work into their usually foolish pattern.

I suspect identity discussions belong with paritytech/substrate-open-working-groups#2 and should evolve dramatically over the next two+ years (SNARKs everywhere!), while this conversation is focused more upon identifying projects/tokens to users, which is much simpler.

---

I'll briefly outline the complexities in identity discussions:

Their DID spec has numerous problems: It violates fundamental privacy principles and largely exists so that users give advertisers, etc. access to excessive personal details. I'd wager implementations violate GDPR. It'd encourages discrimination too. If I recall, the W3C's DID spec actually out sources verifying credentials too, which likely creates vulnerabilities in our context.

We do want a general purpose identity system that deSibels user, but unlike DIDs its identities should then be unlinkable across domains/functions, which means a ring VRF implemented with a zkSNARK. This is the sort of thing for which one wants a standard, while a standard like DID for advertisers to trick users into giving away too much data is obviously bad. See also paritytech/substrate-open-working-groups#2 (comment)

We also want a special purpose identity system for governance, staking, etc. on polkadot and its parachains, but it should be focused upon the needs of governance, and the less suitable for outside use cases the better. There is nothing wrong with a URI for referencing staked/stashed DOTs for governance purposes of course. It'd likely work off-chain so the obvious fields would be:

• staked account id,
• proof of dot value staked until some date in the future,
• some recent polkadot state root,
• merkle proof from account to state root, presumably a few kilobytes, and
• BEEFY roll up proof showing finality of this state root, along with whatever roll up we devise for the polynomial commitments to the history of validators BEEFY keys.

I suppose shortener services could produce the merkle proofs from the current state, or even roll up from verification into a 200ish byte SNARK, but such a shortener services require a full node. It's straightforward to run full nodes now, but in the (distant) future I'd expect shorteners would demand small fees be paid over some future micropayment channel, so actually users should cashe and reuse this record locally.

[olanod]

I'm just a curious passerby but I'd be interested to know more how the DID spec violates fundamental privacy principles, what you describe sounds more like the WebID? 🤔 Also seems very polarizing and not super useful to antagonize the W3C and assume everything under its umbrella is evil, is a requirement of the W3F to oppose they propose? 😅 Specifically about DIDs, It seems to me the people working on those specs have similar motivations and values and would be quite open for people to point flaws in the design to make them as privacy preserving as possible?
Identity part aside which is a bit off-topic for this particular issue, for a resource identifier I still think a DID URL is worth looking at, it fits well as an identifier and it would probably be up to this ecosystem to later implement it correctly so when an identifier resolves it doesn't bring evilness along in the returned document, it will help with interoperability, there will be tooling and things like how to represent it in a binary format. I'd be nice to hear from someone with more knowledge the spec to know if it makes sense to use those identifiers that I understand are not limited to identity.

[burdges]

Ask Servo devs about all the HTML spec cruft they needed to ignore to make rendering parallelize. Ask EFF, FSF, Harry Halpin, etc. about the EME DRM. Do not expect quality or ethics from the W3C.

The privacy problem is simply that websites A and B should not be able to figure out which users they have in common. There exist other problems that entities two whom you prove personal detail like having a collage degree should then owe you a fiduciary-like duty, but if proving you have a collage degree is a simple click away then people will abuse it for all manor of things. If proving your real name becomes only a click away then again this would be abused and become common place.

I repeated told the VC working group behind the DID spec about problems, mostly that certificates acted as unique identifiers. They got Jan Camenisch to tell them CL-signatures exist, which solve an unrelated and much less useful problem than ring/group VRFs.

A proper solution should look more like proof-of-personhood parties: You prove to domain X that you only have one account at domain X, but this reveals nothing else about you and is unlinkable to any accounts you may have at other domains.

[burdges]

I suppose token wrapping is a large concern here, meaning we represent token FOO held in some SPREE.

We should be cognizant of how this impacts zk parachains, so one might glance at ZCash's thoughts in https://github.com/zcash/zips/pull/269/files and zcash/zcash#830 via https://github.com/zcash/zips/blob/master/zip-0218.rst and maybe the zexe paper https://eprint.iacr.org/2018/962.pdf and whtaever they're doing in halo2.

I suspect that's mostly a concern for anyone writing zk circuits though, not soo limiting here. If substrate cannot really hide asset types anyways then this could be a simple as hash-to-the-curve the asset type to obtain the base points used for representing value in pederson commitment, although maybe more efficient options exist.