Inline: On Fri, Jun 9, 2023 at 8:13 AM Jacques Latour <jacques.lat...@cira.ca> wrote:
> 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. > The structure of this example name confused me, perhaps something like: contoso.university.example.edu, manufacturer.example.com, mobile.software.example, or regulatory.example.gov would be better? The `.ca` threw me off. In the VC Data Model, issuer's are identified with `@id` property from JSON-LD.... See https://www.w3.org/TR/json-ld11/#node-identifiers Most common examples of issuer identifiers are: https URLS did URLS It would also be possible to use a URN for a key, such as https://datatracker.ietf.org/doc/rfc9278/ Or other URNs for keys or certificates. urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs jwk supports x5c, and x5u, see - https://datatracker.ietf.org/doc/html/rfc7517#section-4.6 Not sure about cose key... https://www.rfc-editor.org/rfc/rfc9360.html#name-x509-cose-header-parameters 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. > > I see, so for example: regulatory.gov Might point to identifiers for issuers of related claims... as an example https://www.sec.gov/ Might point to: - https://www.fincen.gov - did:example:123 - https://treasury.gov - did:example:456 - https://www.imf.org - did:example:789 > 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. > > You are right, I think its the other half of the example I gave above: https://www.sec.gov - did:example:000 > 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"? > AFAIK, it's a DID for the account & wallet (same thing for now, but maybe this splits in the future... I could be wrong about this.), see their spec registration details: { "name": "plc", "status": "registered", "specification": "https://github.com/bluesky-social/did-method-plc";, "contactName": "Bluesky PBLLC", "contactEmail": "proto...@blueskyweb.xyz", "contactWebsite": "https://blueskyweb.xyz/";, "verifiableDataRegistry": "https://plc.directory"; } > 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" 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 | 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://transmute.industries> > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
