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

Issues to explore resolve #16

Open
trbouma opened this issue Feb 13, 2024 · 4 comments
Open

Issues to explore resolve #16

trbouma opened this issue Feb 13, 2024 · 4 comments

Comments

@trbouma
Copy link
Collaborator

trbouma commented Feb 13, 2024

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
Copy link
Collaborator Author

trbouma commented Feb 13, 2024

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
Copy link
Contributor

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
Copy link
Collaborator Author

trbouma commented Feb 15, 2024

yeah - that header format looks good.

@trbouma
Copy link
Collaborator Author

trbouma commented Feb 16, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants