Musings about the structure of a JWT for P-256

[bshambaugh]

This is not well formed, but I figured that I would start this thread.
During my explorations to understand did-jwt for P-256 I first thought:

I am a bit confused by what the "iss", "sub", and "aud" should be for the payload for a did:key. I suppose I will just say "iss" is did:ethr and "aud" is did:key.

I may have the reverse case, "iss" did:key and "aud" did:ethr

Then I started thinking about how existing curves secp256k1 and ed25519 looked for the JWT.test.ts file:

I put together a gist while reviewing did-jwt for the secp256k1 - ES256K signer:

From JWT.test.ts in decentralized-identity/did-jwt:

const audAddress = '0x20c769ec9c0996ba7737a4826c2aaff00b1b2040'
const aud = `did:ethr:${audAddress}`
const address = '0xf3beac30c498d9e26865f34fcaa57dbb935b0d74'
const did = `did:ethr:${address}`
const alg = 'ES256K'

const privateKey = '278a5de700e29faae8e40e366ec5012b5ec63d36ec77e8a2417154cc1d25383f'
const publicKey = '03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479'

Convert the public key to an Ethereum Address:

var didjwt = require('did-jwt')

const publicKey = '03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479'

const ethAddr = didjwt.toEthereumAddress(publicKey);

console.log(ethAddr);

output:

0x1fbfbce2b5618814eed6b2fd6022251d36c6305a

summarizing:

This suggests that the Ethereum addresses for the aud, did, and address for the public signing key are all different.

const aud = did:ethr:0x20c769ec9c0996ba7737a4826c2aaff00b1b2040

const did = did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74

const ethAddr = did;ethr:0x1fbfbce2b5618814eed6b2fd6022251d36c6305a

[mirceanis]

Yes, these 3 properties of a JWT, iss, sub, aud, all refer to (usually) different entities.
They can also be identical, depending on the use-case..
This has nothing to do with a particular DID method, nor with a particular key type. These 3 entities can be identified by whatever makes sense in a JWT interaction.

This did-jwt library deals with the situation where the iss (issuer) is identified by a DID, and can handle the verification of JWTs with this property by using a DID resolver to figure out what public keys or verification methods are associated with that DID.

From the point of view of this library, the formats for the sub (subject) and aud (audience) properties are irrelevant.

That being said, I don't know what to make of this post so I'm closing it as it does not seem to be an actual issue.
If you think something in the documentation could be made more clear, please specify.
I created a discussions page where this type of post fits better.
https://github.com/decentralized-identity/did-jwt/discussions