You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: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 identifier2.5.5.5
. A DID might look like this?example:
did:x509:0:sha256:WE4P...l38jk::san:2.5.5.5:123
Using this certificate.
What might be an elegant solution for this?
The text was updated successfully, but these errors were encountered: