profile
viewpoint
Ted Thibodeau Jr TallTed @openlink Boston MA USA http://id.myopenlink.net/dataspace/person/tthibodeau Technical Evangelist for @openlink, OpenLink Software. Mac Geek. Human Middleware. Shamanic Witch. Shapeshifter. Singer. Drummer. Dancer. Dreamer.

openlink/virtuoso-opensource 729

Virtuoso is a high-performance and scalable Multi-Model RDBMS, Data Integration Middleware, Linked Data Deployment, and HTTP Application Server Platform

dbpedia/databus-content 0

Application metadata for display on the DBpedia Databus

TallTed/dbpedia-live-mirror 0

Keeps a mirror of DBpedia live in sync

TallTed/did-core 0

W3C Decentralized Identifier Specification v1.0

TallTed/did-wg-charter 0

An EXPERIMENTAL charter for the W3C Decentralized Identifier Working Group

TallTed/docker-sqitch 0

Docker Image packaging for Sqitch

TallTed/docker-virtuoso 0

Virtuoso Docker image

TallTed/easyrdf 0

EasyRdf is a PHP library designed to make it easy to consume and produce RDF.

TallTed/identity-hub 0

Storage and compute nodes for decentralized identity data and interactions

TallTed/information 0

Read the latest developments on This Week in Solid: https://github.com/solid/information/blob/master/weekly-updates/this-week-in-solid.md

issue commentopenlink/virtuoso-opensource

Options datatype and language are ignored by Literal classes

@galgonek -- It appears you have built from a packaged download of source from GitHub, which leaves out a key snippet, which you can get with a proper clone -- which changes the (000000) seen in the strings above, to a GitHead value (such as (1963b2bb52), which I got from the current DBpedia backend via SPARQL query). You may be able to manually glean the "latest commit ID" from the two source trees you built from, which will help us be sure we're looking at the same things.

galgonek

comment created time in 2 days

pull request commentw3c/did-spec-registries

Add bluetoqueagent

@mwherman2000 — As a practical matter, an industry-grade software project will wait 30 days — often longer, for many IETF and/or IANA registrations! — to assure desired interop and to prevent undesired collision. WildWest-style implementations will appear to succeed today, but fail tomorrow, because they didn't bother to register, while an apparently later-mover who did register and wait the time it took to do so gets the benefit of method name collision that leads resolvers to their implementation.

As a further practical matter, it's unclear what portion of the text in the picture you posted was intended to be taken as support of your argument. At a minimum, good netizenship asks that you provide a textual transcription of the JPEG (JPEG‽ a photographic, lossy, format for an image of plain, black-and-white text? Why do you not use the far more appropriate PNG or even GIF format for this image?) alongside that graphic, which is currently inaccessible by those with visual challenges, where actual text is fully accessible through a variety of tools. We (many others have expressed this sentiment in other threads with you) do not have time to read the entirety of large documents, nor to watch your videos, in order to get the few words or phrases or even sentences that you actually meant us to be swayed by.

mwherman2000

comment created time in 2 days

Pull request review commentw3c-ccg/traceability-interop

Refine proposal for discovery

 This is trivial, simply do: HTTP GET https://platform.example/organization/123/did.json => didDocument.json ``` -2. Review the `alsoKnownAs` section of the did document.+2. Review the `alsoKnownAs`, `assertionMethod` and `authentication` sections of the did document. -```json-{-  "alsoKnownAs": [-    "did:example:123",-    "did:key:z6Mk...",-    "did:web:another.platform.example:organization:456"-  ]-}-```+#### `alsoKnownAs`++> This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.++See [alsoKnownAs](https://www.w3.org/TR/did-core/#dfn-alsoknownas).++This entry MUST be present.+This entry MUST have a first element that is the base URL for a VC-API that supports presentation exchange.++#### `assertionMethod`++The set of supported `assertionMethod` DID URLs for the organization.+See [assertionMethod](https://www.w3.org/TR/did-core/#assertion). -Resolve each of these DIDs. -The set of supported `assertionMethod` DID URLs for the organization is the aggregation of the `assertionMethod` for each listed DID.+#### `authentication` -The set of supported `authentication` DID URLs for the organization is the aggregation of the `authentication` for each listed DID.+The set of supported `authentication` DID URLs for the organization.+See [authentication](https://www.w3.org/TR/did-core/#authentication).++The `didDocument` MAY contain a `verificatonMethod` section, which MAY be used to support `did:web` based verification relationships.++The `didDocument` MUST NOT contain `verificatonMethod`'s where the controller is different from the DID Subject.  All `Ed25519VerificationKey2018` types support `Ed25519Siganture2018`  All `JsonWebKey2020` types support `JsonWebSignature2020` AND `VC-JWT`. +For example:++```json+{+  "@context": [+    "https://www.w3.org/ns/did/v1",+    {+      "@vocab": "https://www.w3.org/ns/did/#"+    }+  ],+  "id": "did:web:platform.example:organization:123",+  "alsoKnownAs": [+    "https://platform.example/organization/123",+    "did:key:z6MksSdhqJH3VvzcX8WP6VbdB85e6T7aaL5yLLYeJLJrto8V",+    "did:key:z82LkpR3sPw87xdgs72J3EzGXChciBmhV6ukkbeAGFtCpauXHiEwtM2tyDcphRnLmKsB1fi"+  ],+  "assertionMethod": [+    "did:key:z6MksSdhqJH3VvzcX8WP6VbdB85e6T7aaL5yLLYeJLJrto8V#z6MksSdhqJH3VvzcX8WP6VbdB85e6T7aaL5yLLYeJLJrto8V",+    "did:key:z82LkpR3sPw87xdgs72J3EzGXChciBmhV6ukkbeAGFtCpauXHiEwtM2tyDcphRnLmKsB1fi#z82LkpR3sPw87xdgs72J3EzGXChciBmhV6ukkbeAGFtCpauXHiEwtM2tyDcphRnLmKsB1fi"+  ],+   "authentication": [+    "did:key:z6MksSdhqJH3VvzcX8WP6VbdB85e6T7aaL5yLLYeJLJrto8V#z6MksSdhqJH3VvzcX8WP6VbdB85e6T7aaL5yLLYeJLJrto8V",+    "did:key:z82LkpR3sPw87xdgs72J3EzGXChciBmhV6ukkbeAGFtCpauXHiEwtM2tyDcphRnLmKsB1fi#z82LkpR3sPw87xdgs72J3EzGXChciBmhV6ukkbeAGFtCpauXHiEwtM2tyDcphRnLmKsB1fi"+  ],+  "services": [+    {+      "id": "did:web:platform.example:organization:123#traceability-api",+      "type": "TraceabilityAPI",+      "serviceEndpoint": "https://platform.example/organization/123"+    }+  ]+}+```++In this example, the organization suports authentication and credential issuance with the same 2 keys, identified via the DID URLs in the relationships.
In this example, the organization suports authentication and credential issuance with the same two keys, identified via the DID URLs in the relationships.
OR13

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentw3c-ccg/traceability-interop

Refine proposal for discovery

 This is trivial, simply do: HTTP GET https://platform.example/organization/123/did.json => didDocument.json ``` -2. Review the `alsoKnownAs` section of the did document.+2. Review the `alsoKnownAs`, `assertionMethod` and `authentication` sections of the did document. -```json-{-  "alsoKnownAs": [-    "did:example:123",-    "did:key:z6Mk...",-    "did:web:another.platform.example:organization:456"-  ]-}-```+#### `alsoKnownAs`++> This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.++See [alsoKnownAs](https://www.w3.org/TR/did-core/#dfn-alsoknownas).++This entry MUST be present.+This entry MUST have a first element that is the base URL for a VC-API that supports presentation exchange.++#### `assertionMethod`++The set of supported `assertionMethod` DID URLs for the organization.+See [assertionMethod](https://www.w3.org/TR/did-core/#assertion). -Resolve each of these DIDs. -The set of supported `assertionMethod` DID URLs for the organization is the aggregation of the `assertionMethod` for each listed DID.+#### `authentication` -The set of supported `authentication` DID URLs for the organization is the aggregation of the `authentication` for each listed DID.+The set of supported `authentication` DID URLs for the organization.+See [authentication](https://www.w3.org/TR/did-core/#authentication).++The `didDocument` MAY contain a `verificatonMethod` section, which MAY be used to support `did:web` based verification relationships.
The `didDocument` MAY contain a `verificationMethod` section, which MAY be used to support `did:web` based verification relationships.
OR13

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentw3c-ccg/traceability-interop

Refine proposal for discovery

 This is trivial, simply do: HTTP GET https://platform.example/organization/123/did.json => didDocument.json ``` -2. Review the `alsoKnownAs` section of the did document.+2. Review the `alsoKnownAs`, `assertionMethod` and `authentication` sections of the did document. -```json-{-  "alsoKnownAs": [-    "did:example:123",-    "did:key:z6Mk...",-    "did:web:another.platform.example:organization:456"-  ]-}-```+#### `alsoKnownAs`++> This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.++See [alsoKnownAs](https://www.w3.org/TR/did-core/#dfn-alsoknownas).++This entry MUST be present.+This entry MUST have a first element that is the base URL for a VC-API that supports presentation exchange.++#### `assertionMethod`++The set of supported `assertionMethod` DID URLs for the organization.+See [assertionMethod](https://www.w3.org/TR/did-core/#assertion). -Resolve each of these DIDs. -The set of supported `assertionMethod` DID URLs for the organization is the aggregation of the `assertionMethod` for each listed DID.+#### `authentication` -The set of supported `authentication` DID URLs for the organization is the aggregation of the `authentication` for each listed DID.+The set of supported `authentication` DID URLs for the organization.+See [authentication](https://www.w3.org/TR/did-core/#authentication).++The `didDocument` MAY contain a `verificatonMethod` section, which MAY be used to support `did:web` based verification relationships.++The `didDocument` MUST NOT contain `verificatonMethod`'s where the controller is different from the DID Subject.
The `didDocument` MUST NOT contain `verificationMethods` where the controller is different from the DID Subject.

Style choice -- either "verificationMethods" or "verificationMethods" (that is, `verificationMethod`s or `verificationMethods`); I think the latter is better.

OR13

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentw3c-ccg/traceability-interop

Refine proposal for discovery

 This is trivial, simply do: HTTP GET https://platform.example/organization/123/did.json => didDocument.json ``` -2. Review the `alsoKnownAs` section of the did document.+2. Review the `alsoKnownAs`, `assertionMethod` and `authentication` sections of the did document.
2. Review the `alsoKnownAs`, `assertionMethod`, and `authentication` sections of the DID document.
OR13

comment created time in 2 days

Pull request review commentw3c-ccg/traceability-interop

doc: added section discussing selective disclosure

 <h2>Key Management</h2>         </p>       </section> +      <section class="normative">+        <h2>Selective Disclosure from Credentials</h2>+        <p class="issue">+          All current approaches to selective disclosure are active works in progress with+          notable security or other considerations.  These are actively being tracked in+          <a href="https://github.com/w3c-ccg/traceability-interop/issues/39">Issue #39</a>. +          Selective Disclosure using any mechanism SHOULD NOT be used for production data +          at this time until further testing and security analysis has been performed.+          Selective Disclosure mechanisms MAY be used for testing and validation purposes.+        </p>+        <p>+          Selective disclosure of certain values from signed credentials is a highly desireable+          feature that is actively being worked towards.  At the moment, two general approaches +          exist for this particular feature:+          <ul>+            <li>BBS+</li>+            <li>Merkle Tree Proofs</li>+          </ul>+        </p>+        <section class="normative">+          <h2>BBS+</h2>+          <p>+            BBS+ approaches to signatures for use with selective disclosure rely on pairing+            friendly curves, specifically BLS12-381 in the current specifications.+          </p>+          <p class="issue">+            <a href="https://w3c-ccg.github.io/ldp-bbs2020/">BBS+ Signatures 2020</a> +            MUST NOT be used due to issues related to one or more blank nodes as well+            as sensitivity around the ordering of a signed message.  See issue+            <a href="https://github.com/w3c-ccg/ldp-bbs2020/issues/62">#62</a> for more+            details.+          </p>+          <p>+            The <a href="https://github.com/decentralized-identity/bbs-signature">+              BBS+ Signature Scheme+            </a> specification is consolidating work towards an updated version of +            BBS+ signatures that aim to resolve prior issues.+          </p>+        </section>+        <section class="normative">+          <h2>Merkle Tree Proofs</h2>+          <p>+            <a href="https://computersciencewiki.org/index.php/Merkle_proof">Merkle Tree</a> +            based proofs for selective disclosure attempt to resolve+            concerns around requirements for pairing friendly curves leveraged in+            BBS+ and other approaches to selective disclosure by not mandating the+            hashing and signature suite mechanism so that those algorithms may be+            selected to meet the needs of a particular operating envrionment.+          </p>+          <p>+            At the current time, merkle proofs are unsuitable for production use, but have test implementations supporting both+            <a href="https://w3c-ccg.github.io/Merkle-Disclosure-2021/">LD Signatures</a> +            and <a href="https://w3c-ccg.github.io/Merkle-Disclosure-2021/jwp/">Json Web Proofs</a>+          </p>+          <p>+            This approach should permit usage of Merkle Tree based methods for selective disclosure+            with NIST approved cryptography, and should also faciliate cryptographic agility+            with the introduction of +            <a href="https://csrc.nist.gov/projects/post-quantum-cryptography">+              Post Quantum Cryptography (PQC)+            </a>.+          </p>+          <p>+            Until there is more work done on both the specification, reference implementations, and+            evaluation of Merkle Tree Proofs they SHOULD NOT be used in production, but MAY be used
            evaluation of Merkle Tree Proofs, they SHOULD NOT be used in production, but MAY be used
mprorock

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentw3c-ccg/traceability-interop

doc: added section discussing selective disclosure

 <h2>Key Management</h2>         </p>       </section> +      <section class="normative">+        <h2>Selective Disclosure from Credentials</h2>+        <p class="issue">+          All current approaches to selective disclosure are active works in progress with+          notable security or other considerations.  These are actively being tracked in+          <a href="https://github.com/w3c-ccg/traceability-interop/issues/39">Issue #39</a>. +          Selective Disclosure using any mechanism SHOULD NOT be used for production data +          at this time until further testing and security analysis has been performed.+          Selective Disclosure mechanisms MAY be used for testing and validation purposes.+        </p>+        <p>+          Selective disclosure of certain values from signed credentials is a highly desireable+          feature that is actively being worked towards.  At the moment, two general approaches +          exist for this particular feature:+          <ul>+            <li>BBS+</li>+            <li>Merkle Tree Proofs</li>+          </ul>+        </p>+        <section class="normative">+          <h2>BBS+</h2>+          <p>+            BBS+ approaches to signatures for use with selective disclosure rely on pairing+            friendly curves, specifically BLS12-381 in the current specifications.+          </p>+          <p class="issue">+            <a href="https://w3c-ccg.github.io/ldp-bbs2020/">BBS+ Signatures 2020</a> +            MUST NOT be used due to issues related to one or more blank nodes as well+            as sensitivity around the ordering of a signed message.  See issue+            <a href="https://github.com/w3c-ccg/ldp-bbs2020/issues/62">#62</a> for more+            details.+          </p>+          <p>+            The <a href="https://github.com/decentralized-identity/bbs-signature">+              BBS+ Signature Scheme+            </a> specification is consolidating work towards an updated version of +            BBS+ signatures that aim to resolve prior issues.+          </p>+        </section>+        <section class="normative">+          <h2>Merkle Tree Proofs</h2>+          <p>+            <a href="https://computersciencewiki.org/index.php/Merkle_proof">Merkle Tree</a> +            based proofs for selective disclosure attempt to resolve+            concerns around requirements for pairing friendly curves leveraged in+            BBS+ and other approaches to selective disclosure by not mandating the+            hashing and signature suite mechanism so that those algorithms may be+            selected to meet the needs of a particular operating envrionment.+          </p>+          <p>+            At the current time, merkle proofs are unsuitable for production use, but have test implementations supporting both
            At the current time, Merkle proofs are unsuitable for production use, but test implementations support both
mprorock

comment created time in 2 days

issue commentopenlink/virtuoso-opensource

Options datatype and language are ignored by Literal classes

@galgonek -- Please confirm the exact version of Virtuoso in use for this test, with the first stanza of output from the command-line virtuoso-t -? or virtuoso-odbc -? (or otherwise adjusted to match the Virtuoso executable name in your environment).

@pvk @HughWilliams @imitko @IvanMikhailov @openlink -- Please look into this issue with User-defined Custom Data Types.

galgonek

comment created time in 2 days

issue commentw3c-ccg/vc-api

Plugfest March 2021 Feature freeze date

Overtaken by events, it is not 2022. No longer relevant. Closing.

s/not 2022/now 2022/

OR13

comment created time in 4 days

delete branch TallTed/vc-wg-charter

delete branch : patch-1

delete time in 5 days

Pull request review commentperl5-dbi/DBD-ODBC

Remove links to ohloh, annocpan and cpanratings

 schema required and the versions of software you are using. If you are unsure whether you have found a bug report it anyway or post it to the dbi-users mailing list. -=item pod comments and corrections--If you find inaccuracies in the DBD::ODBC pod or have a comment which-you think should be added then go to L<http://annocpan.org> and submit-them there. I get an email for every comment added and will review-each one and apply any changes to the documentation.

Perhaps this should be edited to provide different instructions for the described feedback (github issues, maybe?), rather than simply deleted, leaving no path for that feedback?

mbeijen

comment created time in 6 days

PullRequestReviewEvent

PR opened w3c/vc-wg-charter

re-tweaked cryptosuite deliverables

same changes were submitted (and, I thought, applied) previously, but they weren't in main when I just checked, so here they are again

+3 -3

0 comment

1 changed file

pr created time in 10 days

push eventTallTed/vc-wg-charter

Ted Thibodeau Jr

commit sha df9891debfb5f0827f941f3814a32c8d8e6a093c

re-tweaked cryptosuite deliverables same changes were submitted (and, I thought, applied) previously, but they weren't in main when I just checked, so here they are again

view details

push time in 10 days

fork TallTed/vc-wg-charter

Developing a new charter for the VC WG.

https://w3c.github.io/vc-wg-charter/

fork in 10 days

Pull request review commentw3c-ccg/did-pkh

Update considerations

 Construct the DID Document for *did* as follows: - Construct an empty DID Document metadata object, *docMeta*. - Return *resMeta*, *doc*, and *docMeta*. + ### Update -No updates possible. did:pkh DID Documents are, like [did:key] documents, intended for local-only usage.+No updates possible. did:pkh DID Documents are, like [did:key] documents, +intended for local-only usage.  ### Delete -No deletion possible. did:pkh DID Documents are, like [did:key] documents, intended for local-only usage.+No deletion possible. did:pkh DID Documents are, like [did:key] documents, +intended for local-only usage.
No deletion possible. `did:pkh` DID Documents, like [`did:key`] documents,
are intended for local-only usage.
bumblefudge

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentw3c-ccg/did-pkh

Update considerations

 # did:pkh Method Specification+ Authors: Wayne Chang, Charles Lehner, Juan Caballero, Joel Thorstensson Status: Draft+ ## Introduction+ ### Problem Statement+ There are over hundreds of billions of on-chain, balance-holding accounts across the major 50 or so blockchains, all secured and namespaced using similar technologies. Almost all of these derive identifiers from hashed or otherwise obscured public keys, which are provided at time of transaction.+ These accounts are used to protect billions of dollars in assets and critical digital infrastructure. They are also actively being piloted and used by enterprises and governments. They are rapidly becoming a major form of shared data infrastructure across verticals and continents.+ DIDs should favor usability where possible, and it is extremely beneficial from a security & human computer interaction perspective to have DIDs that readily correspond to their equivalents on decentralized networks. This corresponds neatly to end-users' understanding of what an "account" is on an existing network.  There are knock-on security effects to having an immediately-recognizable "address" double as a DID for usage elsewhere.  + It also allows most if not all blockchain accounts to instantly leverage an existing identity/account and deploy a W3C Decentralized Identifier from it in a standards-conformant way. This "DID-wrapping" of an existing identifier can be used in combination with other DID-compatible technologies, such as W3C Verifiable Credentials or Authorization Capabilities, and produce proper signature-suite definitions, such as "metamask-signing" (signing according to the [[eip712]] protocol, soon to be a work item at W3C-CCG).+ ### Relationship to other DID architectures+ did:pkh bears many similarities to [did:key](https://w3c-ccg.github.io/did-method-key/#introduction) except it is optimized for identifiers derived from hashes of public keys according to well-known algorithms (commonly referred to as "public key hashes" because in most cases they are a public key hashed according to a standard hash function).+ ### Combination with other DID methods+ Another difference from did:key is that did:pkh is design to have many "upgrade paths" for DIDs deterministically generated from existing keypairs.  Namely: - if a did:pkh is controlled by a keypair which is valid for generating a   blockchain-published DID document according to another method (for instance,   did:tz, did:btcr or did:ethr), its did document can be translated to the form
- if a `did:pkh` is controlled by a keypair which is valid for generating a
  blockchain-published DID document according to another method (such as `did:tz`,
  `did:btcr`, or `did:ethr`), its DID document can be translated to the form
bumblefudge

comment created time in 10 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentw3c-ccg/did-pkh

Update considerations

 # did:pkh Method Specification+ Authors: Wayne Chang, Charles Lehner, Juan Caballero, Joel Thorstensson Status: Draft+ ## Introduction+ ### Problem Statement+ There are over hundreds of billions of on-chain, balance-holding accounts across the major 50 or so blockchains, all secured and namespaced using similar technologies. Almost all of these derive identifiers from hashed or otherwise obscured public keys, which are provided at time of transaction.+ These accounts are used to protect billions of dollars in assets and critical digital infrastructure. They are also actively being piloted and used by enterprises and governments. They are rapidly becoming a major form of shared data infrastructure across verticals and continents.+ DIDs should favor usability where possible, and it is extremely beneficial from a security & human computer interaction perspective to have DIDs that readily correspond to their equivalents on decentralized networks. This corresponds neatly to end-users' understanding of what an "account" is on an existing network.  There are knock-on security effects to having an immediately-recognizable "address" double as a DID for usage elsewhere.  + It also allows most if not all blockchain accounts to instantly leverage an existing identity/account and deploy a W3C Decentralized Identifier from it in a standards-conformant way. This "DID-wrapping" of an existing identifier can be used in combination with other DID-compatible technologies, such as W3C Verifiable Credentials or Authorization Capabilities, and produce proper signature-suite definitions, such as "metamask-signing" (signing according to the [[eip712]] protocol, soon to be a work item at W3C-CCG).+ ### Relationship to other DID architectures+ did:pkh bears many similarities to [did:key](https://w3c-ccg.github.io/did-method-key/#introduction) except it is optimized for identifiers derived from hashes of public keys according to well-known algorithms (commonly referred to as "public key hashes" because in most cases they are a public key hashed according to a standard hash function).+ ### Combination with other DID methods+ Another difference from did:key is that did:pkh is design to have many "upgrade
Another difference from `did:key` is that `did:pkh` is designed to have many "upgrade
bumblefudge

comment created time in 10 days

Pull request review commentw3c-ccg/did-pkh

Update considerations

 # did:pkh Method Specification+ Authors: Wayne Chang, Charles Lehner, Juan Caballero, Joel Thorstensson Status: Draft+ ## Introduction+ ### Problem Statement+ There are over hundreds of billions of on-chain, balance-holding accounts across the major 50 or so blockchains, all secured and namespaced using similar technologies. Almost all of these derive identifiers from hashed or otherwise obscured public keys, which are provided at time of transaction.+ These accounts are used to protect billions of dollars in assets and critical digital infrastructure. They are also actively being piloted and used by enterprises and governments. They are rapidly becoming a major form of shared data infrastructure across verticals and continents.+ DIDs should favor usability where possible, and it is extremely beneficial from a security & human computer interaction perspective to have DIDs that readily correspond to their equivalents on decentralized networks. This corresponds neatly to end-users' understanding of what an "account" is on an existing network.  There are knock-on security effects to having an immediately-recognizable "address" double as a DID for usage elsewhere.  + It also allows most if not all blockchain accounts to instantly leverage an existing identity/account and deploy a W3C Decentralized Identifier from it in a standards-conformant way. This "DID-wrapping" of an existing identifier can be used in combination with other DID-compatible technologies, such as W3C Verifiable Credentials or Authorization Capabilities, and produce proper signature-suite definitions, such as "metamask-signing" (signing according to the [[eip712]] protocol, soon to be a work item at W3C-CCG).+ ### Relationship to other DID architectures+ did:pkh bears many similarities to [did:key](https://w3c-ccg.github.io/did-method-key/#introduction) except it is optimized for identifiers derived from hashes of public keys according to well-known algorithms (commonly referred to as "public key hashes" because in most cases they are a public key hashed according to a standard hash function).
`did:pkh` is similar in many ways to
[`did:key`](https://w3c-ccg.github.io/did-method-key/#introduction), except that
`did:pkh` is optimized for identifiers derived from hashes of public keys according
to well-known algorithms (commonly referred to as "public key hashes", because, in
most cases, they are a public key hashed according to a standard hash function).
bumblefudge

comment created time in 10 days

PullRequestReviewEvent
more