Syntactially differentiate data about the DID versus application data

[selfissued]

DID applications should be able represent data in whatever manner they choose, whereas the representations of data in a DID document about the DID itself should be specified by the DID standard. To meet these dual requirements, these two classes of data must be syntactically differentiated.

We need to evolve the DID document syntax to syntactically differentiate between data about the DID versus data for DID applications that happens to be co-resident in the DID document. The former is the domain of the DID standard. The latter is not.

Note that this differentiation was initially discussed by @dlongley and @selfissued in #67.

[peacekeeper]

All data in the DID document is about the DID. Or to be more precise, about the DID subject. (Or in some cases, perhaps also metadata about the DID document - that's a different discussion, see #65).

Therefore I don't think "data about the DID" vs. "data for applications" is a very meaningful distinction that should have different syntax. I think what @dlongley said in #67 (comment) and what we discussed in the 2019-10-15 DID WG Meeting was that data in the DID document may be used for different purposes - by applications, or by the DID registry, or by both.

But the DID specification can not and should not try to anticipate in advance what data in a DID document will be used by certain applications or by certain DID methods.

[selfissued]

Are you saying @peacekeeper , that, for instance, all keys in the DID document can be used to validate control of the DID? If indeed, there is no application-use-only data in the DID document, that argues for using standard key representations, so common code can do the signature/proof validation.

Is suspect there are more nuances here than are apparent in the discussion to date. Let's plan to discuss this on a call soon.

[dlongley]

@selfissued,

...all keys in the DID document can be used to validate control of the DID? If indeed, there is no application-use-only data in the DID document, that argues for using standard key representations, so common code can do the signature/proof validation.

The DID Document is a place for the DID controller to express verification methods (e.g., public keys, M of N bundles, capabilities) that are authorized for the proofs it creates, according to the purpose of those proofs (e.g, authentication, capability invocations, as a method of assertion, etc.).

I think what is being said by @peacekeeper is that any application that is able to consume the verification methods and proofs will be able to verify them, whether those applications are integral to the DID method itself or not. So creating a distinction there is not likely to meaningful -- rather I would expect it to create artificial barriers to use and maintenance.

I agree with you that we should have standard key representations so we can have common code for doing signature/proof validation. However, I think the emphasis here will unfortunately have to be on the plural form ("representations"). Different applications consume different key formats and we don't have control over what they choose. We shouldn't create impedance mismatch via additional layers of conversion to formats the applications don't accept; it will just annoy users and cause them to have to incorporate more tooling that they wouldn't otherwise need. Saying we'll only support one standard representation isn't a big stick that can make applications adopt that format, it is merely an obstacle to DID adoption. DID method providers will just move to add support for other formats.

Therefore, I think we want to enable keys to travel in a DID document (ensure they conform to the data model) as minimally as we can (e.g., "publicKeyPem", "publicKeyJwk", etc.).

[OR13]

ethereumAddress in did:ethr is a good example of this... You are probably not going to have good app level interop if you only support ethereumAddress formats. Other systems will need actual public keys... the ethereum ledger does not.

IMO this highlights the need to support flexibility around the key format discussion.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Key representation
Daniel Burnett: #67
Manu Sporny: #85
Manu Sporny: #85 gets into whether data is application data or DID data , or …
Michael Jones: logged #85 based on discussion with dlongley, that application data may be formatted however the app likes, while DID data should be formatted according to the standard(s) we set
Manu Sporny: #85 is a bit of a meta-discussion, which is hard to resolve in a concall, and will make it harder to resolve #67 which is fairly focused
… #85 is still important, just less tangible and harder to grasp
Markus Sabadello: there’s a separate issue for “data about the DID subject” vs “data about the DID document”: #65 this is different from issue 85
Michael Jones: focusing on #67 for now is fine. hope is that folks will keep #85 in mind while doing so.
Manu Sporny: #67 (comment)
Manu Sporny: [ summarizes #67 ] …
Kyle Den Hartog: one concern is that data size will continue to grow, and that may pose a problem
Michael Jones: base* encoding does expand the size of things; that’s a valid concern.
… most important thing is raised as Requirement 11, about future proofing
… secondarily, JWK proponent (and author, so somewhat biased)
Dave Longley: regretful counter is that we have no control over formats used in the wild
… point of expressing your key is to let apps in the wild use your key, and many apps don’t consume JWK, so requiring that all keys are expressed in JWK imposes burden on apps now using openssl or nodejs or others
… would be fantastic if a single representation worked for all, but there are many tools already using multiple representations, so this is hard to force after-that-fact
… forcing JWK would slow adoption of DIDs and DID Methods
Drummond Reed: Mike, what’s your thoughts on Dave’s point?
Kyle Den Hartog: to clarify about size – it’s not about encoding; it’s about the characters required to express the base mathematics
Kyle Den Hartog: yeah, I can add them
Michael Jones: [ citation/example requested ]
… dlongley is right that any chosen format would require translation be implemented (once). idea is that once that translation is written, it’s done
Tobias Looker: DID resolver is going to be required in any case, let this handle the heavy lifting (the representation translation) for the app
Markus Sabadello: remember that we’re separating abstract content from concrete syntax
Manu Sporny: we’ll certainly talk about this again next time. the question is not “JWK or something-else”, it’s “something and JWK” – what is the something, that is capable of handling PEM or PEM in CBOR or ….?
Kyle Den Hartog: @manu thank you for that clarification. In that point, I’m less opinionated about this.
Daniel Burnett: Thanks all. Will continue this discussion next week
Dave Longley: options: 1. support ONLY JWK, 2. support JWK and other popular formats
Manu Sporny: question is whether to support only JWK, or JWK-plus-others
Manu Sporny: +1
Manu Sporny: That’s what the group has to decide.
Ted Thibodeau Jr: fifth time’s the charm!

[dlongley]

I think we came to a resolution on this issue regarding key representations and so forth -- and anything that might remain just duplicates the metadata issue #65. I recommend we close this issue as a result.

[selfissued]

This should remain open until we close all the metadata issues, including #65, as it provides important context for the discussion, all-up.

[jricher]

The information in this issue is still available even when it's closed. If the :actions: are being tracked in another issue, then this one should be closed and it should be referenced and linked from the issue where the actions are taking place.

[selfissued]

Until the information has been acted uponand the issue addressed, the issue should remain open.

[jricher]

This is addressed in part in #253 which creates space for metadata in addition to the document itself.

[selfissued]

I suggest that we have a special topic call on this. There's lots of expertise in the group that we should bring to bear on this topic. We should address this issue before the feature freeze.

[jricher]

See also #299 for metadata structure definitions. We need to have a place to talk about metadat abefore we define what the metadata is.

[peacekeeper]

We added a section on metadata properties in #347, and we added some concrete metadata properties (created, updated) in #365.

What still remains to be done to address this issue?

[brentzundel]

I recommend closing.
@selfissued Is there more to be done to address this issue?

[brentzundel]

No comments since marked pending close, closing.