Closed OR13 closed 2 years ago
Such middleware seems very necessary to allow for did:jwk to interop with did methods that support JSON-LD or that use DIDComm.
What you're describing is definitely interesting, but I would consider that a different method.
If I were to go this way I might consider it being a did:jwt
method so that it is also protected and can be updated by using canonicalId
to the contained JWK thumbprint. I could even imagine supporting rotation by embedding a JWS attesting to the next key (though it would balloon in size quickly).
The current spec text does not forbid stuffing JSON in the JWK, should it be:
Prime examples of things we expect to see in a JWK which would show up in a did document:
kid
, use
, alg
.
given adding JSON to the JWK is the main extension point, I think more guidance on this is required to prevent folks from putting database queries or results in the JWK.
Completely agree, I'll work on some language with specific guidance.
one hack around did methods like this has been "resolver middleware", or... modifying a did document to contain values other than what the method author intended (for example adding service endpoints or
@context
or other json values to an existing did document.It is possible to make
did:jwk
look like a did web by exploiting the ability to encode arbitrary JSON in the encoded JWK.For example:
This will then yield a did document that contains nested data which can be pulled up the correct level by "post resolution middleware"....
example: