Did-core: application/did+json should be marked at risk

[OR13]

Let's be honest, "The Abstract Data Model contains only properties about the DID Subject"... actually comes from believing the DID Document is about RDF Triples....

DID Subject <propertyName> <propertyId>

It's been many months since the disastrous face to face in Amsterdam, where we created 2 new representations and the did spec registries, and only CBOR has seen any significant contribution, and it's only currently supporting JSON(-LD) as CBOR.

There are 0 implementations of DID Methods that intend to ONLY support JSON.

There have been 0 pull requests to did spec registries for JSON only... the only thing we have agreed to is that JSON-LD is required to define JSON only extensions in the registry!

JSON-Only as a representation is defined exclusively by not being JSON-LD, and its only other defining feature is that it supports arbitrary properties, like __proto__, and that@context is forbidden.... yet the entire did core spec is built around JSON-LD / RDF...

The use of arrays instead of objects, the alias of @type and @id.... the use of these properties to construct RDF triples, arguing over whether OWL sameAs is valid or not, arguing about the privacy issues associated with an open world type system being applied to the did subject.... These are all only issues because the ADM is actually RDF disguised in INFRA makeup.

At minimum JSON-Only MUST be marked at risk.

We have seen 0 evidence that it exists as a standalone concept (there are 0 implementations).... It appears to only exist, because people don't like JSON-LD, they want to be able to add arbitrary none RDF conformant properties to JSON DID Documents, making them more confusing for developers by having 2 nearly identical JSON representations with different security properties.

See this thread regarding JSON as the only supported representation of DIDComm...

https://github.com/decentralized-identity/didcomm-messaging/issues/112#issuecomment-702349868

Yet now the INFRA ADM is specifically being used to promote many alternative representations, increasing our reliance on trusted resolver software which will translate for us.... Are we even chartered to solve arbitrary data model translation / build resolvers?... We are making 3rd party translation resolvers the root of trust... destroying the entire point of DIDs.

We are not being honest about the relationship of RDF to the DID Core spec... RDF is guiding all the formal decisions, including alsoKnownAs, did subject types, services and privacy and the relationships to the VC Data Model, and then we are saying:

If you can't figure out how to use RDF properly, just say your did document is application/did+json...

The DID Core Abstract Data Model is actually RDF... we chose INFRA for the ADM because many folks couldn't figure out how to craft valid RDF...

https://github.com/decentralized-identity/universal-resolver/issues/106
Look at all the work @peacekeeper has done trying to help get DID Methods to be valid JSON-LD.... https://github.com/decentralized-identity/did-common-java/commit/d6b76125a50f6a682873d90420a0b84a99e1f5e9

Wouldn't it be easier to just say these are all application/did+json so we don't need to tell them its broken RDF? Sure, but is that a good idea from a security perspective... of course it's not... we should have been throwing errors this whole time, not papering over the failure to comprehend RDF.

I am concerned that we are baking in a reliance on trusted 3rd party translation software, complicated ADM rules implemented in software libraries not under the control of the DID Method, like the java code I just linked, and that the DID Controller will no longer be determining what properties of a did subject are exposed to did document consumers.

On the call today, the only -1 to removing JSON-only was @talltree, I would like to hear why you think the ADM is not actually RDF in INFRA makeup, and how continuing down the path of creating an ever more complicated INFRA based abstract data model that only trusted 3rd party software can translate representations with is helping did controllers express properties about a did subject.

I think the DID core spec could be massively simpler if we were willing to be honest about how RDF based the ADM really is.

[OR13]

@talltree JSON-only is:

1. NOT Safer (encourages arbitrary properties, incompatibility with JSON-LD, worse type support than CBOR)
2. NOT Smaller (same size as CBOR and JSON-LD)
3. NOT Faster (parsing time longer than CBOR and same as JSON-LD)

We also discussed the need to support multiple representations that are created after the spec freezes, using the registries, yet we have seen only contribution to the registries regarding JSON-LD and CBOR.

JSON-only should be marked at risk. cc @burnburn @brentzundel @msporny

[msporny]

JSON-only should be marked at risk.

I'm fine with marking it at risk, but I expect there will be multiple implementations. I don't think removing JSON-only will result in consensus, which is the proposal in the issue title.

Let's see where we land on the ADM tomorrow, but I expect that the result isn't going to be removing JSON-only from the spec.

[talltree]

I too am fine with marking it at risk, but I will be very surprised if there are not multiple implementations. The two advantages of JSON-only is that it is simple and very widely used.

[OR13]

@talltree JSON-only is simple to use because its less secure (sees unknown properties as a feature) and not as small (same size as JSON-LD and CBOR).... from an engineering perspective it provides 0 value to strict implementers... It's like saying python is a "safer language" than rust...

The Abstract Data Model is also not capable of knowing what the intention of the "unregistered properties is"... making the features of JSON-only harmful to providing a consistent interpretation of the ADM.

[tralcanx]

Hey, there is a method in the registries that is JSON-only: www.tyronzil.com - and so far I don't see any strong reason to change that. So I am against removing JSON representation from DID Core, I believe it would harm innovation that use DID Core as a standard reference.

[OR13]

https://www.tyronzil.com/did-document/

The contentType property in the resolver's metadata MUST be application/did+json

@julio-cabdu care to way in on: https://github.com/w3c/did-core/issues/417

I assume tyronzil only supports JSON, what happens if someone requests another representation?

Since you are using Sidetree, I should mention that Sidetree supports both JSON and JSON-LD...

[tralcanx]

Someone requesting another representation is not yet in the scope of tyron improvement proposals, but it will get assessed if it becomes relevant. Also, tyronZIL is no longer Sidetree-based since it evolved into smart-contract architecture - for details see DID smart contract.

[OR13]

@julio-cabdu

You might want to use publicKeyJwk instead of publicKeyBase58

And replace "SchnorrSecp256k1VerificationKey2019" with "JsonWebKey2020", since "SchnorrSecp256k1VerificationKey2019" is actually a JSON-LD Verification Method defined here:

https://github.com/w3c/did-spec-registries/blob/master/contexts/did-v1.jsonld#L17

Here is a complete implementation of that verification method:

https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019

also note that it relies on an unregistered JWS alg "SS256K", which is not present in https://www.iana.org/assignments/jose/jose.xhtml

You may also be interested in https://github.com/w3c-ccg/lds-jws2020, which defines several other JWK / JWS Linked Data (JSON-LD) Verification Methods.... that are properly registered / standard.

I remain confused as to how DID Core can both simultaneously use these and advocate for compatibility with the VC Data Model, and yet, also indicate a desire to see an abundance of non RDF compliant DID Document representations....

I expect this issue will be closed at some point in the future, my main objection to JSON-only is that it provides essentially no benefit to security minded developers, and invites a relaxed security posture in an area where nobody should be relaxed.

I suppose the simple answer is that "rules/schemas" are allowed for people who want them, but not required for folks who decide they are not useful for security.... the did core spec is flexible on this subject, and does not have an opinion on security best practices with respect to data formats.... many developers who use DIDs, like myself, do have an opinion on this topic, and the opinion is essentially that DID Core spec is less safe than it could be, in order to be accommodating to folks who think differently about security / privacy / interoperability.

[OR13]

waiting on "at risk" issue tags to be added to the spec

[OR13]

btw, I'm ok closing this if JSON representation support can be sufficiently demonstrated to "not be at risk"... seems like we are not being fair about how we consider representations to be at risk or not.

I implemented support for JSON Representation in did:key and did:elem / did:photon... but these only became valid implementations of the JSON representation AFTER we made the recent changes to the ADM production consumption rules.

[OR13]

here are at least 2 implementations I did that use application/did+json as it is currently defined...

• https://github.com/transmute-industries/sidetree.js
• https://github.com/transmute-industries/did-key.js

If pointing to these repos is enough to avoid being marked at risk, I am happy to close this issue

and add support for CBOR as well :)

[iherman]

here are at least 2 implementations I did that use application/did+json as it is currently defined...

• https://github.com/transmute-industries/sidetree.js
• https://github.com/transmute-industries/did-key.js

If pointing to these repos is enough to avoid being marked at risk, I am happy to close this issue

In my view they are.

and add support for CBOR as well :)

[csuwildcat]

We also implement the ability to output DID Documents as either plain JSON or JSON-LD in ION: https://github.com/decentralized-identity/ion. (and you can for all Sidetree methods, if an implementation elects to use of that part of the reference code: https://github.com/decentralized-identity/sidetree)

[selfissued]

Given that there are multiple implementations supporting JSON-only, I suggest that we now close this issue. Thanks.

[OR13]

@brentzundel @msporny @talltree @burnburn @jonnycrunch Is this enough to remove the "feature at risk flag for JSON"

and if I add support for vanilla CBOR, would it be enough to remove the feature at risk flag from vanilla CBOR?

[ChristopherA]

@OR13 What is "vanilla CBOR" in this case?

I ask as I'm still uncomfortable with multihash in CBOR, as it is self-describing encoding format inside a self-describing encoding format.

[OR13]

@ChristopherA "vanilla CBOR" is what you get when you pass a application/did+json or application/did+ld+json to https://www.npmjs.com/package/cbor

essentially, any tooling that supports json -> cbor.

[OR13]

Feels like this issue should be closed, because the consumption production rules for JSON and JSON-LD are so close, that I would be surprised if did+json was marked at risk when did+ld+json is not.... given they can actually be identical.

[OR13]

I am closing this, as there is no action here