Re: Question regarding DID method-specific-id

We are also using did:jwk to add support for x509 when it is needed or to
add any of the other optional JWK members that are repeated outside of the
verification method in the case of did documents.

For example, saying a JWK is used to encrypt, is like saying a
verificationMethod is used for keyAgreement.

I really don't like that DID URLs use fragments to identify subresources
that contain properties that it would be nice to be able to negotiate for.

It would have been better if did resolution looks like this:

did:example:123/path/resource?query=param#kid --accept
application/jwk-set+json => JWKS

and verificationMethods looked like this:

did:example:123/use/sig#kid => JWKS
did:example:123/use/enc#kid => JWKS

Then you could use a media type other than application/jwk-set+json to get
a controller document, for example: application/did+json.

It's probably also worth calling JWKS controller documents, and defining a
signed version of them using JWT and CWT either at IETF or at a standards
organization that leverages JOSE and COSE frequently and has experts who
can review security of resolving identity documents.

Regards,

OS


On Wed, Aug 30, 2023 at 7:17 AM Oliver Terbu <oliver.terbu@spruceid.com>
wrote:

> We are also using did:jwk with x5c to combine X.509 and DIDs.
>
> On Wed, Aug 30, 2023 at 11:51 AM Paul Bastian <paul.bastian@posteo.de>
> wrote:
>
>> If your use case involves Verifiable Credentials, you could use x5c in
>> the VC header like in SD-JWT-VC directly and not use DIDs at all. The
>> identifier of the issuer is than an DNS/URL instead of a DID.
>>
>> Best regards,
>> Paul
>>
>> 30.08.2023 11:38:24 Niels Klomp <nklomp@sphereon.com>:
>>
>> Using a JWK with an x5u or x5c is also how we are using X509 in DIDs.
>>
>> By having the certificate chain including the public certificate in the
>> x5u or x5c and then having the public key as the Verification Method, means
>> you have everything you need to verify the certificate
>>
>>
>> Kind regards,
>>
>> Met vriendelijke groet,
>>
>>
>> Niels Klomp
>> ------------------------------
>> *Van:* Markus Sabadello <markus@danubetech.com>
>> *Verzonden:* woensdag 30 augustus 2023 10:59
>> *Aan:* ステファニー タン（SBIホールディングス） <tstefan@sbigroup.co.jp>; Alen Horvat <
>> horvat.alen@yahoo.com>
>> *CC:* public-credentials@w3.org <public-credentials@w3.org>
>> *Onderwerp:* Re: Question regarding DID method-specific-id
>>
>>
>> To add to this, we have done some work on attaching X509 certificates to
>> verification methods in DID documents, see here:
>>
>>
>> https://docs.google.com/document/d/1zMYUt8icua5kCyQtaDhjLnpETwfhBDE-cFQKauysk-k/
>>
>>
>> E.g. try to resolve this DID:
>> https://dev.uniresolver.io/#did:web:danubetech.com:did:test4
>>
>>
>> Verifying the certificate chain attached to a DID document's verification
>> method can be done by a DID resolver, which could raise errors/warnings if
>> a verification method can't be traced back to a "trusted CA".
>>
>>
>> And here are a few more links to existing work related to this topic:
>> -
>> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/hybrid_wallet_solutions_x509_DIDs_VCs.md
>> - https://wiki.trustoverip.org/display/HOME/X.509+PKD+Interop
>> - https://github.com/transmute-industries/openssl-did-web-tutorial
>>
>>
>> Markus
>>
>>
>> On 8/30/23 10:47, ステファニー タン（SBIホールディングス） wrote:
>>
>> Hi Alen,
>>
>> Thank you for your response!
>>
>> To answer your questions (our answers are in *blue*):
>>
>>    1. Binding x509 certs to DIDs can be also done via public keys. *We
>>    think this might raise some technical hurdles and might be more
>>    troublesome.*
>>    2. do you have the freedom to add additional information to the x509
>>    cert?  *No, we would want everyone to be able to use it.*
>>    3. is binding a public key to a DID sufficient? Related question is:
>>    does a Legal Entity have multiple x509 certs?* we are still reviewing
>>    this. For now, we are starting by connecting one DID to one Legal Entity,
>>    but we still don't know what the needs are for more than one DID against
>>    multiple Legal entities (so we cannot give a clear answer here, sorry.)*
>>    4. do you need a link from the DID to the certificate, vice versa or
>>    both?* the link from the certificate to the DID is critical, but even
>>    vice versa would be okay.*
>>
>> Best regards,
>> Stefannie
>>
>> ------------------------------
>> *From:* Alen Horvat <horvat.alen@yahoo.com> <horvat.alen@yahoo.com>
>> *Sent:* Wednesday, August 30, 2023 3:02 PM
>> *To:* ステファニー タン（SBIホールディングス） <tstefan@sbigroup.co.jp>
>> <tstefan@sbigroup.co.jp>
>> *Cc:* Markus Sabadello <markus@danubetech.com> <markus@danubetech.com>;
>> public-credentials@w3.org <public-credentials@w3.org>
>> <public-credentials@w3.org>
>> *Subject:* Re: Question regarding DID method-specific-id
>>
>> Hi,
>>
>> Very timely question. What about putting DID information in x509, if
>> that’s possible? Issuer Alternative Name and Subject Alternative Name
>> support URI value, which DID is.
>>
>> Binding x509 certs to DIDs can be also done via public keys. Questions
>> are:
>>
>> - do you have the freedom to add additional information to the x509 cert?
>> - is binding a public key to a DID sufficient? Related question is: does
>> a Legal Entity have multiple x509 certs?
>> - do you need a link from the DID to the certificate, vice versa or both?
>>
>> BR, Alen
>>
>> On 30 Aug 2023, at 05:20, ステファニー タン（SBIホールディングス） <tstefan@sbigroup.co.jp>
>> <tstefan@sbigroup.co.jp> wrote:
>>
>> Hi Markus,
>>
>> Thank you for the prompt response!
>> Please let me clarify, we are considering using both DID/VC and X509
>> authentication (RFC 5280). We assume a world wherein X509 trust roots
>> mutually authenticate each other using DID/VC.
>>
>> In order to achieve the above, we are thinking of embedding the Issuer
>> (Distinguished Name) in X509 into the DID method-specific-id or the issuer
>> id of the VC.
>>
>> However, the ABNF pattern allowed by the VC standard is more restrictive
>> than X509  Issuer (DN), so we cannot transcribe it as is.
>>
>> One suggestion is to use base-percent-encoding, but the processing is
>> complicated and heavy and lacks readability, so we are currently seeking a
>> better solution.
>>
>> Thank you for any further advice you or any member can provide!
>>
>> Best,
>> Stefannie
>> ------------------------------
>> *From:* Markus Sabadello <markus@danubetech.com> <markus@danubetech.com>
>> *Sent:* Tuesday, August 29, 2023 4:53 PM
>> *To:* public-credentials@w3.org <public-credentials@w3.org>
>> <public-credentials@w3.org>
>> *Subject:* Re: Question regarding DID method-specific-id
>>
>> Hello Stefannie,
>>
>> From that documentation page I can't really tell what a "CordaX500Name"
>> looks like when expressed as a single string, do you have an example?
>>
>> But basically a method-specific-id can be anything that matches this ABNF
>> pattern:
>>
>> method-specific-id = *( *idchar ":" ) 1*idchar
>> idchar             = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
>>
>> So it can consist of letters, digits, and the . - _ characters as well as
>> percent-encoding such as %20
>>
>> You say the name is base encoded and then percent-encoded, but from a DID
>> syntax perspective, this feels unnecessary.
>>
>> If the "CordaX500Name" can be expressed using only characters from the
>> list above, then there may be no need to base- or percent-encode anything,
>> and readability can be preserved.
>>
>> Markus
>>
>> On 8/29/23 09:33, ステファニー タン（SBIホールディングス） wrote:
>>
>> Hi everyone,
>>
>> I am seeking community support/advice regarding DID method-specific-id in
>> the syntax. If the DID Name is a CordaX500Name (
>> https://docs.r3.com/en/api-ref/corda/4.8/open-source/javadoc/net/corda/core/identity/CordaX500Name.html)
>> that has been base encoded, and then percent-encoded:
>>
>>
>>    1. will there be any potential issues if we use the above method?
>>    (technically speaking, is it possible?)
>>    2. is there a way to preserve readability?
>>
>>
>> Thank you!
>>
>> Stefannie
>>
>>
>>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>