Re: [Dance] [EXT] Re: Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries

[Orie Steele <[e-mail]>]

Inline:

On Fri, Jun 9, 2023 at 8:13 AM Jacques Latour <[e-mail]>
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": "[e-mail]",
  "contactWebsite": "https://blueskyweb.xyz/",
  "verifiableDataRegistry": "https://plc.directory"
}


> More reading required,
>
> Jack
>
>
>
>
> ------------------------------
> *From:* Orie Steele <[e-mail]>
> *Sent:* Thursday, June 8, 2023 11:21 AM
> *To:* [e-mail] <[e-mail]>
> *Cc:* Jacques Latour <[e-mail]>; [e-mail] <[e-mail]>;
> scitt <[e-mail]>
> *Subject:* [EXT] Re: Leveraging DNS in Digital Trust: Credential
> Exchanges and Trust Registries
>
> You don't often get email from [e-mail]. 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>