Re: some thought after using did:web

We have had the same issue... per the did core spec, there are really 2
main key types, in our crypto libraries for the key pair classes
themselves, we do our best to support both and handle translation for you:

https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/Ed25519KeyPair.ts#L78
https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2018.ts
https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2020.ts
https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/JsonWebKey2020.ts

> The suite is actually a concern at the VC level so enforcing
representations on DID methods doesn't really make sense imo.

^ yes, that is one way of looking at it... but I still think it's a shame
we couldn't get everyone to bend the knee to JWK...

It would have been worth it... but then again, decentralization is not the
same as federation.

Regarding the universal resolver, I would recommend using it as a last
attempt to resolve things.

Here is some older code (probably outdated by now) showing how to "short
circuit" the universal resolver:

https://gist.github.com/OR13/975d855ae0f0c968eab47d2e6b9d3de7

It's a good idea when you know which methods you want to support, and you
know the universal resolver proxies requests to another resolver service
for those methods anyway.

IMO there is never a reason to call a remote resolver for did:web, unless
you can't make network requests... See:

https://github.com/w3c-ccg/did-method-web/issues/52#issuecomment-996227323

> IMHO it will be great if each DID method enforces particular
representations. It makes development and integration much easier.

^ this is generally the case, some methods choose to only support JWK, or
only support multi codec... did web is probably the most flexible json
supporting did method you can find.

If you want to really feel the pain, you can implement post resolver
middleware that normalizes all public keys to JWK and pretend like the
other formats don't even exist...
I wouldn't trust a remote service to do that, but once you have resolved
and consumed the document, how you choose to represent it is up to you.

Regards,

OS


ᐧ

On Wed, Jan 5, 2022 at 6:09 PM Brian Richter <brian@aviary.tech> wrote:

> Yeah, there are quite a few different linked data suites that can
> represent keys in DID documents. Here is the one you are using now
> https://w3c-ccg.github.io/lds-jws2020/. The suite is actually a concern
> at the VC level so enforcing representations on DID methods doesn't really
> make sense imo.
>
> I'm also interested in the use of the universal resolver for did:web. It
> is one of very few did methods that doesn't take any setup or special
> infrastructure. you can simply take the domain from the did and send an
> http request to {domain}/.well-known/did.json. Using the universal resolver
> for this adds latency, another point of failure and adds the possibility of
> surveillance.
>
> Brian
>
> On Wed, Jan 5, 2022 at 3:36 PM Nikos Fotiou <fotiou@aueb.gr> wrote:
>
>> Hi,
>>
>> We are developing a project demo where a user generates JSON Web
>> Signatures and these signatures can be verified using information
>> associated with a “did:web” DID. In theory, the verification process is
>> straightforward: the “verifier” retrieves the corresponding DID document
>> (we are using universal resolver for that) and it extracts the appropriate
>> “verificationMethod”, indicated by the “authentication” claim.
>>
>>
>>
>> However, when it comes to the actual implementation, it turns out that
>> there are many ways to represent a key in a DID document, but our crypto
>> library (used for verifying signatures) accepts only a couple of them. So
>> initially, we started by creating a big “if” that converted  various
>> “verificationMethod” types to the appropriate representation. Soon we
>> abandoned this approach and we enforced project  members to use only
>> “publicKeyJwk” in DID documents, which is OK for a demo but not for a real
>> world product.
>>
>>
>>
>> IMHO it will be great if each DID method enforces particular
>> representations. It makes development and integration much more easier.
>>
>>
>>
>> Best,
>>
>> Nikos
>>
>>
>>
>> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
>>
>> Researcher - Mobile Multimedia Laboratory
>>
>> Athens University of Economics and Business
>>
>> https://mm.aueb.gr
>>
>>
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>