Re: [Identity-discuss] US/DHS/SVIP Call + Industry Day || Privacy Preserving Digital Credential Wallets and Verifiers

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Aug 11, 2023 at 3:15 PM Dick Hardt <[e-mail]> wrote:

> Hey Jon, thanks for posting this.
>
> I don't know if you intended it, but the “Preventing Forgery &
> Counterfeiting of Certificates and Licenses
> <https://www.dhs.gov/science-and-technology/blockchain-portfolio>” links
> to your Blockchain Portfolio page.
>
> FWIW: I'm amused by "*support the broad range of credentials possible
> with W3C VCDM/DID standards*"
>
> The DID "standard" consists of there being a string that starts with
> "did:" that eventually resolves to a key
>

The DID scheme appears to be following the URN scheme anti-pattern.

Back at the dawn of the Web, a group of people showed up who were very
insistent that they knew a lot about naming and had lots of ideas that
absolutely HAD to be put into the specs. One of these was to rename URLs
URI because the identifier might not support location. OK, whatever. So
having been bullied into recognizing the existence of URLs and URNs as
different things, the next demand was that URLs should start url: and URNs
should start urn: and Web browsers should insist on this tremendously
important 'idea'.

So needless to say, that was kicked out quickly enough. But the sad legacy
was that there was now a separate registry for URNs and some notion that
since this existed, it should be used for something. And so instead of
assigning a legacy identifier a URI prefix, foo: they got urni:foo:


Some standardized mechanisms for identifying keys would be really useful.
But that isn't what a DID is, a DID is simply an opaque string that
identifies 'something' in a particular scheme and has no defined semantics
outside that scheme, even the inference it identifies a cryptographic key
is kinda fuzzy. So basically the only thing DIDs have achieved is
avoiding cluttering up the URI registry.

My  current proposal for naming things with hashes is UDF,
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/

When I presented that as part of the Mesh BOF in Singapore, someone asked
if I had read RFC6920:
https://www.rfc-editor.org/rfc/rfc6920.html

Fortunately, I always read drafts I am an author on. The main difference
between ni and UDF is that the assumption in ni was that the hashes would
never be seen by a user and hence it uses Base64 encoding and an existing
registry of hash algorithms.

ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk


The starting point for UDF was 'what would OpenPGP hashes look like if we
redid them using a modern approach but with the aim of having something
that would still work on a business card. So the corresponding UDF is
something like:

MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4


That is by definition a SHA-2-512 digest algorithm being used (UDFs can be
truncated to any length). You can also use SHA-3-512, specify nonces,
private key generation seeds, and some other interesting stuff.

Having one way to identify keys throughout an application is really useful.
But make sure it is compatible with case-insensitive file systems, so use
Base32, not 64.


Note however, that it is an identifier for the key, it is NOT a name, since
it has type secondness, a given RSA or ECDH key will have exactly one UDF
value which can be specified at whatever precision is required to achieve
the desired work factor.

I have deliberately not specified a URI scheme for UDF because the idea is
you might use them as building blocks inside of a scheme.

So I might have an OpenPGP entry in my contacts:

mailto:[e-mail];opgp=MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4