Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

describe query parameter passing for public keys #37

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

describe query parameter passing for public keys #37

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 30 additions & 12 deletions did-pkh-method-draft.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,9 +160,25 @@ these if they are not needed in particular DID documents.

### Create

The blockchain account id is validated according to [CAIP-10][] and then appended to
`did:pkh:{network}:`, where `{network}` is the supported prefix corresponding to
the blockchain where it is valid.
The blockchain account id is validated according to [CAIP-10][] and then
appended to `did:pkh:{network}:`, where `{network}` is the supported prefix
corresponding to the blockchain ecosystem within which it is valid. No DID
Document should be returned for a DID URL that is not a valid [CAIP-10][] URI.

In some contexts, such as in web-based interfaces for Solana or Tezos wallets, a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In some contexts, such as in web-based interfaces for Solana or Tezos wallets, a
In some contexts, such as web-based interfaces for Solana or Tezos wallets, a

public key is traditionally passed by wallets to counterparties as part of
authentication, without which signatures cannot be verified and submitted to
public ledgers. In other contexts, such as in web-based interfaces for Ethereum
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public ledgers. In other contexts, such as in web-based interfaces for Ethereum
public ledgers. In other contexts, such as web-based interfaces for Ethereum

wallets, a public key is cryptographically [recoverable][EC Recovery for
secp256k1] from a signature over a known message, but unknowable without one. In
all of these cases, a DID URL containing only the public-key hash will not be
enough to recover the corresponding public key and thus generate a useful DID
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
enough to recover the corresponding public key and thus generate a useful DID
enough to recover the corresponding public key and use it to generate a useful DID

document; instead, a query parameter `pk` (i.e. `?pk=`) can be appended to a DID
PKH URL such that a DID document can be generated for that DID PKH URL. For a
valid DID URL (i.e. one conforming to [CAIP-10]) without the additional
Comment on lines +176 to +178
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
document; instead, a query parameter `pk` (i.e. `?pk=`) can be appended to a DID
PKH URL such that a DID document can be generated for that DID PKH URL. For a
valid DID URL (i.e. one conforming to [CAIP-10]) without the additional
document; instead, the query parameter `pk` can be appended to a DID
PKH URL (i.e., `?pk=`), and a DID document can be generated for that DID PKH URL. For a
valid DID URL (i.e., one conforming to [CAIP-10]) without the additional

information needed to generate a DID Document, an "empty" DID document
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
information needed to generate a DID Document, an "empty" DID document
information needed to generate a DID document, an "empty" DID document

(containing no key material) should be created to signify failure to
authenticate the wallet or inadequate access to such information.

### Read (Resolve)

Expand Down Expand Up @@ -242,7 +258,7 @@ pkh implementations). It is expected that this is a relatively safe operation,
but implementers might consider that there exists no mathematical proof that
confirms this assumption.

## Ref Impl
## Known Implementations

|Author|name of implementation|link to pkh libraries|date registered|
|:---:|:---:|:---:|:---:|
Expand All @@ -252,14 +268,14 @@ confirms this assumption.
## Appendix: Legacy Support

An earlier version of this specification used more human-readable submethod
namespacing rather than referring mapping directly to the CAIP naming
convention. It also defaulted to main-net for `did:pkh:eth` in the absence of an
explicit chainID. As the scope has grown of this project, and with forward
compatibility in mind, both of these patterns have been removed, required
explicitly naming the EVM by its registered [CAIP-2][] code and explicitly
naming the `chain_id` (as specified in [CAIP-10][]) as well. The legacy aliases
that Spruce's implementation also supports for backwards-compatibility with
credentials already issued look like this:
namespacing rather than referring directly to the CAIP naming convention. It
also defaulted to main-net for `did:pkh:eth` in the absence of an explicit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
also defaulted to main-net for `did:pkh:eth` in the absence of an explicit
also defaulted to `main-net` for `did:pkh:eth` in the absence of an explicit

chainID. As the scope has grown of this project, and with forward compatibility
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
chainID. As the scope has grown of this project, and with forward compatibility
`chainID`. As the scope of this project has grown, and with forward compatibility

in mind, both of these patterns have been removed, required explicitly naming
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
in mind, both of these patterns have been removed, required explicitly naming
in mind, both of these patterns have been removed, now requiring explicitly naming

the EVM by its registered [CAIP-2][] code and explicitly naming the `chain_id`
(as specified in [CAIP-10][]) as well. The legacy aliases that Spruce's
implementation also supports for backwards-compatibility with credentials
already issued look like this:
Comment on lines +277 to +278
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
implementation also supports for backwards-compatibility with credentials
already issued look like this:
implementation also supports for backwards-compatibility with previously
issued credentials look like this:


| prefix | example (linked to sample DID document) |
|:---:|:---:|
Expand Down Expand Up @@ -287,3 +303,5 @@ credentials already issued look like this:
[SIWX]: https://chainagnostic.org/CAIPs/caip-122
[CACAO]: https://chainagnostic.org/CAIPs/caip-74
[eip712]: https://github.com/uport-project/ethereum-eip712-signature-2021-spec
[EC Recovery for secp256k1]: https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages#ecdsa-verify-signature
[ECDSA Recovery]: http://www.secg.org/sec1-v2.pdf