Re: [Dance] [EXT] Re: New Version Notification for draft-latour-dns-and-digital-trust-00.txt

[Jacques Latour <[e-mail]>]

Hi Michael,

Thanks for the feedback and I understand your concerns and lack of clarity on the ecosystem and it's applicable use.  

I'm trying to think of a better way to frame this and pretty sure Dance is the right home for this.

In any case, a DID is for all intent a document in a ledger with a public key for the issuer of the digital credentials, the digital credential that someone has on a phone would be signed by that issuer and verifiable via the DID (public key and other attributes),  and we use the TLSA records and labels in the DNS to add an additional layer of trust and functionality to search for a trust registry.

Some DNS code and examples here: https://github.com/CIRALabs/TrustyDID

This video explains how digital credentials and issuers work: https://www.loom.com/share/57db10ddc9f448bf8ff2fb7b10138283

So, two DANCE questions:
       1) can we use the TLSA record to express the public key of an issuer, and 
       2) can an issuer make a TLSA record available if the zone is not signed...  

Jack



-----Original Message-----
From: Michael Richardson <[e-mail]> 
Sent: May 2, 2023 1:30 PM
To: Jacques Latour <[e-mail]>; [e-mail]
Subject: [EXT] Re: [Dance] New Version Notification for draft-latour-dns-and-digital-trust-00.txt


I browsed your document, but I had difficulty understanding it's
applicability.  In my experience with Verified Credentials, they are just not
useable to individuals without the use of a smartphone.  Said smartphone has
no static IP address, so must use a mediator in order to go through
credential presentations, etc. Even if the smartphone did have a stable IPv6,
it probably doesn't have the battery power to be willing to be reachable at
all times.  To date, I haven't found a reasonable business model for
operation of the mediator service(s) which are critical to this entire model.

I mention this because I don't understand how/why your example in section 4.2
would be interacted with.  At first, I thought that I was going to interact
with it when I obtain a credential, but then I realized that was wrong.

If my university provides a credential attesting to my degree to me, I'm not
going to reach out to the university for this did; I think I already have it.

It would be the verifiers that might need this information.
But, when I do a credential presentation with some verifier, I would have
already provided them with the right links, or they would already have them.

I'm unclear how the privacy violating DNS lookup would help them with an
authorization decision.

Perhaps there is a better flow or example that could be used to explain this?
My observation from work in this area is that the "distributed ledgers" are
more of a liability than a feature, and that it would be a good thing if
"sovereign" entities could use the things they are already sovereign over,
namely their ccTLDs as anchors.

{I still think we did DNSSEC root wrong}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [