- From: Niels Klomp <nklomp@sphereon.com>
- Date: Fri, 21 Jul 2023 11:07:28 +0000
- To: Vishwas Anand Bhushan <vishwas@hypermine.in>, Alen Horvat <horvat.alen@yahoo.com>
- CC: Orie Steele <orie@transmute.industries>, "public-credentials@w3.org" <public-credentials@w3.org>, Pratap Mridha <pratap@hypermine.in>
- Message-ID: <AM9PR08MB71185CD32EA133E7C88704B3B63FA@AM9PR08MB7118.eurprd08.prod.outlook.com>
Hi, Yes, it is a self-signed VC. The binding to the domain comes from the /.well-known location. That location typically will not be available to non-admin users and/or hosted/virtual customers/users. It is a bit the same as with did:web. You can have it in /.well-known or you can use any sub path hosted by the domain. But at that point you for sure don’t known anymore whether the owner/admin is in control because these folders could be managed by other users or customers of the owner. So /.well-known/did.config contains a VC mentioning the origin, pointing to the DID, signed by that same DID. The DID contains a service endpoint pointing to that well-known location, which is a top-level virtual or physical location on the hosted origin. Regards, Niels From: Vishwas Anand Bhushan <vishwas@hypermine.in> Sent: vrijdag 21 juli 2023 11:24 To: Alen Horvat <horvat.alen@yahoo.com> Cc: Orie Steele <orie@transmute.industries>; public-credentials@w3.org; Pratap Mridha <pratap@hypermine.in> Subject: Re: Confusion regarding Domain linkage Hi Alen, > It is you (verifier of the challenge) who should issue/sign the domain linkage credential. This is also was my understand, the reason I got confused with self signed credential is because of this part of the spec<https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource-verification> [cid:image001.png@01D9BBD3.053010F0] Which says, DID MUST be equal to both Subject and Issuer - which seems to be self signed credential ? Thanks, Vishwas, CTO @ hypersign.id<http://hypersign.id> On 21-Jul-2023, at 1:34 PM, Alen Horvat <horvat.alen@yahoo.com<mailto:horvat.alen@yahoo.com>> wrote: Hi. To follow the HTTP-01 approach, you’d need a challenge response (you send a challenge to their https endpoint and receive a response signed using the DID key) and of course you check the validity of the TLS certificate. It is you (verifier of the challenge) who should issue/sign the domain linkage credential. Alternative approach (I guess) would be to use the TLS certificate to sign the domain linkage credential and counter sign it with the DID key. I’m not sure whether TLS cert could be used for such operation (technically can be done). BR, Alen On 21 Jul 2023, at 07:13, Vishwas Anand Bhushan <vishwas@hypermine.in<mailto:vishwas@hypermine.in>> wrote: Hey Orie, Thank you for quick response and that blog. So, as I understand, keeping did.json and did-configuration.json files in well-known folder is analogous to HTTP-01 challenge verification. And I think it depends on use case whether you need to go for DNS 01 challenge verification or not. I guess for most purpose HTTP-01 works. You prove control over a DID by signing with keys registered to it This I understood. You prove control over an origin, by placing that signature at a well known location. When you say signature, are you referring to Domain Linkage credential which will be self signed? The way I was thinking was: - We ask user to enter their domain name in a form, - then they generate did:web DID (in did.json file), - then we ask them to keep did.json in their .well-known folder - then we verify if they have added did.json file in that folder or not and also if they own that did or not (by verifying the signature) - then we issue them a domain linkage credential (in did-configuration.json) file which they can keep it in their .well-known folder. But not sure if this is correct way to do since as per spec domain linkage credential seems to be “self signed”. Thanks, Vishwas, CTO @ hypersign.id<http://hypersign.id/> On 20-Jul-2023, at 6:54 PM, Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> wrote: Sounds like you are trying to prove a bi-directional link exists between 2 identifiers. You prove control over a DID by signing with keys registered to it. You prove control over an origin, by placing that signature at a well known location. This was inspired by how Lets Encrypt works: https://letsencrypt.org/docs/challenge-types/ OS On Thu, Jul 20, 2023 at 1:47 AM Vishwas Anand Bhushan <vishwas@hypermine.in<mailto:vishwas@hypermine.in>> wrote: Hi everyone, We are from hypersign.id<http://hypersign.id/> and our DID method did:hid is approved in w3c did registry. We are trying to figure out how can we link a DID with domain. Seems like did:web is used for that where in domain owner can generate did.json to keep their DID, and did-configuration.json to keep their self signed domain linkage credential in their .well-known folder - as per spec<https://identity.foundation/.well-known/resources/did-configuration/>. But what I am unable to understand is, how does merely keeping some files in .well-known folder will prove that you own that domain unless you do ACME challenges (like DNS 01 challenge) verification. Say if you add TXT record and verify that then how does this verification can be linked to domain linkage credential since domain linkage credential seems to be a self signed credential by nature (see 5.1<https://identity.foundation/.well-known/resources/did-configuration/#did-configuration-resource-verification>). It's quite confusing to me. Could someone please clarify this or share any documentation related to this use case? Thanks, Vishwas, CTO @ hypersign.id<http://hypersign.id/> -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/> [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
Attachments
- image/png attachment: image001.png
Received on Friday, 21 July 2023 11:07:37 UTC