search

CIRALabs / high-assurance-dids-with-dns

Other
0 stars 1 forks source link

Issues to explore resolve #16

Open trbouma opened 6 months ago

trbouma commented 6 months ago

Issues to explore/resolve. Some of these might require an "ask" from IETF and/or W3C

  1. DNS record types to support high assurance DIDs

DID (_did) type for specifying did:methods to invoke other than the did:web method DID TLSA for looking up public key material. TXT record for looking up other pubkey type.

  1. Adding "header" to DID doc to indicate info needed for verification

type for public key type, etc. alg - for a given public key type, specifying the signing algorithm, etc.

  1. "signature" versus "proof"

Accommodate JWT conventions where additional info can be found in header

  1. additional attributes in did doc:

As per JWT conventions - "iat", "ext", "iss", etc.

trbouma commented 6 months ago

After discussion, this is the proposed approach. I also discovered that many DNS providers do not support URI and/or TLSA records, so relying on those types is a significant path blocker to adoption.

Use the scoping _did and TXT record to store any public key material (e.g. hex string)

In the did document, add a header section like this example:

header = { 
"typ" = "dns/did",
"alg" = "secp256k1ecdsa"
}

Since the issuer knows and has registered the public key for the did doc, it can provide this information within the did doc.

The verifier checks the header - type="dns/did"`` indicates to look up public key material at_did.domainandalg="secp256k1ecdsa"``` indicates to use the secp256k1 curve and ecdsa. Therefore the TXT record can be interpeted as a sec256k1 public key.

jessecarter111 commented 6 months ago

Proposed header object: 3 required fields verificationMethod: Must point to the corresponding verificationMethod used to generate the signature. alg: A value indicating the crypto-suite used to generate the signature dnsType: Used to indicate the DNS record type to query (TLSA, CERT, TXT, should be TLSA) Ex:

"header": {
"verificationMethod": "did:web:example.ca#key-1",
"alg": "ecdsap256",
"dnsType": "tlsa"
}

Proposed JWT field inclusions in DID doc: exp: An expiry date indicating how long a given resolver should cache the DID document/how long that did document is valid for. iat: A date indicating when the current DID document was issued/created. Ex:

{
"exp": 2024-03-15T07:09:48.000+0545
"iat": 2024-02-15T07:09:48.000+0545
}

There is no need to include the issuer field as that concept is not supported by the DIDs. The relevant parallel is the "controller" (https://www.w3.org/TR/did-core/#did-controller) and "id" fields (https://www.w3.org/TR/did-core/#did-subject).

trbouma commented 6 months ago

yeah - that header format looks good.

trbouma commented 6 months ago

I implemented "dnsType" and made the timestamps ISO format. I still don't believe verificationMethod should be in the header because it is a different concern: the header is just about how the did doc is signed and verified. Verficationmethod is about how it is used for signing and verifying other things (not the did doc) - that became clear when I was generating did docs for users, e.g., did:web:trustroot.ca:examplecorp