Stephen Curran
Stephen Curran
It may be better to match the SubjectAltName (SAN) rather than the CommonName in the TLS certificate
Interesting. Indeed, based on the description the SAN is the right way to check. I think what the requirement is really saying, although done so in a roundabout way, is...
It may be better to match the SubjectAltName (SAN) rather than the CommonName in the TLS certificate
Ideally we point the SSL spec and remove the precision of the reference. What we are trying to say is "Use SSL in the way modern browsers use SSL". @swcurran
Good catch. Will add that after the current 0.4 PR is merged.
Action: Add this as a clarification without changing the version. @swcurran
I’m not a cryptographer, but briefly looking at the differences between secp256k1 and ed25519 keys I gather there is not a lot of difference in the two approaches cryptographically. We...
A priority is use algorithms that are secure, so a NIST is used as guidance. We wouldn’t select something otherwise — and that is covered with both. After that, since...
This was discussed at the Nov. 7, 2024 meeting of the DIF Work Item, and we agreed to close this with the response: > I do want to underline that...
Had a good discussion with @jessecarter111, @trbouma and Jacques Latour about this. Here is the conclusion we came to: The High Assurance DIDs with DNS (HADwD) specification can be implemented...
While not needed to be done as part of the HADwD work, I thought of a different way we could implement added assurance through DNS for a `did:tdw` DID --...
Added to the information site [https://didwebvh.info](https://didwebvh.info) -- [here](https://didwebvh.info/latest/implementers-guide/high-assurance-dids-with-dns/) Pending close -- We plan to discuss this and other issues at the next did:webvh Work Item meeting -- Thursday, Feb, 13...