We are exploring the usage of did:x509 for binding existing certificates to the VC world. The did:x509 would become the issuer of a credential which contains the claims from the certificate. The relevant values are encoded in custom SAN fields. For this to work we need a way for the SAN policy can contain more types than the current email, dns and uri. Perhaps it can also contain an oid?
The value 123 is encoded in the asn1 object identifier 2.5.5.5. A DID might look like this?
We are exploring the usage of
did:x509for binding existing certificates to the VC world. The did:x509 would become the issuer of a credential which contains the claims from the certificate. The relevant values are encoded in custom SAN fields. For this to work we need a way for the SAN policy can contain more types than the current email, dns and uri. Perhaps it can also contain an oid?The value
123is encoded in the asn1 object identifier2.5.5.5. A DID might look like this?example:
did:x509:0:sha256:WE4P...l38jk::san:2.5.5.5:123Using this certificate.
What might be an elegant solution for this?