Re: Confusion regarding Domain linkage

Hi,

> If you use well known did configuration, they will all be marked as "equivalent" to the origin.... Which might not be what you want.

Honestly there is no customer requirement as such with us, but what we ideally want is, an origin should prove control of one (or more) DID. Not really expecting them to own just one, if that’s what you meant? 

But thanks for rest of clarifications. 


Thanks,
Vishwas, CTO @ hypersign.id

> On 22-Jul-2023, at 7:00 PM, Orie Steele <orie@transmute.industries> wrote:
> 
> Any did method will work.
> 
> That spec was originally built to help make did:ion (Bitcoin / sidetree) be discovered for web origins.
> 
> This highlights a problem with it.
> 
> Let's say you have 5 did webs on the same origin.
> 
> If you use well known did configuration, they will all be marked as "equivalent" to the origin.... Which might not be what you want.
> 
> I think it would be better to be able to bind each web pages or routes to DIDs, so that for example, Twitter handles could be linked to DIDs, without saying that all the DIDs are equivalent to "Twitter.com".
> 
> There was a project some of us where working on called "rebase" that took the same challenge approach and tried to achieve this. 
> 
> Spruce has a demo of it, not sure if it's still actively maintained.
> 
> OS
> 
> 
> On Fri, Jul 21, 2023, 11:21 PM Vishwas Anand Bhushan <vishwas@hypermine.in <mailto:vishwas@hypermine.in>> wrote:
> Hi Niels, 
> 
> Thanks, now that clarifies my doubt, I guess. 
> 
> The owner of the origin has to first create a DID with service end point and store did.json in /.well-known, then issue themselves a domain linkage credential with origin and store that credential in /.well-known folder as well in did-configuration.json file. 
> 
> Whoever wants to verify, they first fetch domain linkage credential, get the origin from credential subject then match with the domain name. 
> 
> My last question is, is it necessary to use did:web did method for creating DID for this purpose or any other did method can also be used?  
> 
> Apologies for my stupid questions. 
> 
> 
> Thanks,
> Vishwas, CTO @ hypersign.id <http://hypersign.id/>
> 
>> On 21-Jul-2023, at 4:37 PM, Niels Klomp <nklomp@sphereon.com <mailto:nklomp@sphereon.com>> wrote:
>> 
>> 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 <mailto:vishwas@hypermine.in>> 
>> Sent: vrijdag 21 juli 2023 11:24
>> To: Alen Horvat <horvat.alen@yahoo.com <mailto:horvat.alen@yahoo.com>>
>> Cc: Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries>>; public-credentials@w3.org <mailto:public-credentials@w3.org>; Pratap Mridha <pratap@hypermine.in <mailto: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> 
>>  
>> <image001.png>
>>  
>> 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/ <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://transmute.industries/>
>>  
>>  
>>  
>