Orie, ATDT555-1212 - was my first thought 🙂 but I like what I read on Bluesky and the AT protocol, it's different but related worlds and I think there could be some synergies, I don't see any mention of DNSSEC usage in the AT protocol?
example-issuer.ca plays the role of the verifiable digital credential DC issuer. Like a university or a gov driver's license department that issues different forms of DCs.        issuer A role an entity<https://www.w3.org/TR/vc-data-model/#dfn-entities> can perform by asserting claims<https://www.w3.org/TR/vc-data-model/#dfn-claims> about one or more subjects<https://www.w3.org/TR/vc-data-model/#dfn-subjects>, creating a verifiable credential<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> from these claims<https://www.w3.org/TR/vc-data-model/#dfn-claims>, and transmitting the verifiable credential<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> to a holder<https://www.w3.org/TR/vc-data-model/#dfn-holders>. So with TLSA records, standard labels and URI/PTR (whatever scheme we decide to use) and DNSSEC, trust of issuers can be asserted. The I-D is about finding trust registry relationships in the DNS, for global interoperability of different ecosystems. In your example below, it's _atproto.wyden.senate.gov, I think it's the "end user" direct AT protocol credential DID and information, not the same thing.... more research/reading required. a TXT record pointing to a DID which returns : _atproto.wyden.senate.gov. 10777 IN TXT "did=did:plc:ydtsvzzsl6nlfkmnuooeqcmc" where does on go to resolve a DID:PLC? is the DID for the user "wallet" or the "account"? More reading required, Jack ________________________________ From: Orie Steele <orie@transmute.industries> Sent: Thursday, June 8, 2023 11:21 AM To: da...@ietf.org <da...@ietf.org> Cc: Jacques Latour <jacques.lat...@cira.ca>; uta@ietf.org <uta@ietf.org>; scitt <sc...@ietf.org> Subject: [EXT] Re: Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries You don't often get email from orie@transmute.industries. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Original thread: https://mailarchive.ietf.org/arch/msg/dance/g0eSMxmZzb1ucsFtgkVkICV5Hh8/ I read https://www.ietf.org/archive/id/draft-latour-dns-and-digital-trust-00.html Previously I had read: - https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/ - https://identity.foundation/.well-known/resources/did-configuration/ (I'm co-author) I don't understand the role that "example-issuer.ca<http://example-issuer.ca>" is playing in these records. Why is there a need to structure the record "key" to include CA information? Is https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/ relevant to this conversation? I wanted to share some related work, from BlueSky: They support linking https://www.w3.org/TR/did-core/ to specific domains, this allows for the natural control of a domain to be used to establish the natural authority of an identifier, For example: dig -t txt _atproto.wyden.senate.gov<http://atproto.wyden.senate.gov> | grep 'did=' | grep -o '"did=.*"' | jq -r 'split("=")[1]' https://github.com/w3c/did-spec-registries/pull/515 I would like to see a standard way to link decentralized identifiers to domains documented somewhere at IETF. Including UTA & SCITT in case there are folks with relevant comments. Regards, OS -- ORIE STEELE Chief Technology Officer www.transmute.industries [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries>
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
