Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntactially differentiate data about the DID versus application data #85

selfissued opened this issue Oct 22, 2019 · 5 comments


Copy link

@selfissued selfissued commented Oct 22, 2019

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.


This comment has been minimized.

Copy link

@peacekeeper peacekeeper commented Oct 22, 2019

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.


This comment has been minimized.

Copy link

@selfissued selfissued commented Oct 22, 2019

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.


This comment has been minimized.

Copy link

@dlongley dlongley commented Oct 22, 2019


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


This comment has been minimized.

Copy link

@OR13 OR13 commented Oct 22, 2019

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.


This comment has been minimized.

Copy link

@iherman iherman commented Oct 23, 2019

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!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.