In creating the signed did doc, I needed some more information about keys, algorithms, etc. In reviewing the W3C DID spec, I felt it was simpler to adopt JWT conventons of "header", "payload and "signature".
In the example below you can see how I implemented. I also used the registered claim types defined by JWT.
In the did doc, there is now a "header" section with "type" and "alg". In the example below, this is what I put it the header to indicate that I am using a pubkey using the ecdsa signing algorithm. I store this in a TXT record _pubkey.domain.com.
In following the JWT convention, I also decided to use the "signature" section instead of using "proof" section because the necessary information can now be indicated in the "header" section, so the "proof" information would be redundant.
In signing the did doc, I remove the "header" section, treat the balance as the "payload", generate the signature and add in the resulting "signature" section before transmitting the did_doc
When verifying the transmitted did doc. I inspect the header for what I need to do, extract the signature from the signature section, and then remove "header" and "signature " for verification.
I propose that we use the "header" section to indicate how to get the right key for verification. In addition to the pubkey approach I have been using, we need to have an indication for TLSA certificate types and their parameters. Something like:
"header": {
"typ": "tlsa",
"...": "..."
},
I am not sure what the other header parameters should be yet.
Also, I added in expiry which is similar to TTL (using 3600, or an hour).
Anyway this issue is intended to capture the discussion.
In creating the signed did doc, I needed some more information about keys, algorithms, etc. In reviewing the W3C DID spec, I felt it was simpler to adopt JWT conventons of "header", "payload and "signature".
In the example below you can see how I implemented. I also used the registered claim types defined by JWT.
In the did doc, there is now a "header" section with "type" and "alg". In the example below, this is what I put it the header to indicate that I am using a pubkey using the ecdsa signing algorithm. I store this in a TXT record _pubkey.domain.com.
In following the JWT convention, I also decided to use the "signature" section instead of using "proof" section because the necessary information can now be indicated in the "header" section, so the "proof" information would be redundant.
In signing the did doc, I remove the "header" section, treat the balance as the "payload", generate the signature and add in the resulting "signature" section before transmitting the did_doc
When verifying the transmitted did doc. I inspect the header for what I need to do, extract the signature from the signature section, and then remove "header" and "signature " for verification.
I propose that we use the "header" section to indicate how to get the right key for verification. In addition to the pubkey approach I have been using, we need to have an indication for TLSA certificate types and their parameters. Something like:
I am not sure what the other header parameters should be yet.
Also, I added in expiry which is similar to TTL (using 3600, or an hour).
Anyway this issue is intended to capture the discussion.