Skip to content

Commit

Permalink
Spelling
Browse files Browse the repository at this point in the history
  • Loading branch information
expede committed Jul 1, 2024
1 parent f9b2dda commit 059e3af
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 1 deletion.
1 change: 1 addition & 0 deletions .custom-words.txt
Original file line number Diff line number Diff line change
Expand Up @@ -110,6 +110,7 @@ btc
codec
codecs
crudGraph
cryptocurrency
cryptographic
cryptographically
cryptosuite
Expand Down
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -565,7 +565,7 @@ It is possible to use other algorithms, but doing so limits interoperability wit

## Why must those specific signature algorithms be supported?

In an ideal world, a single algorithm (Ed25519) would be available everywhere. For many historical reasons, P-256 and `secp256k1` are the only practical options for many applications, such as the [WebCrypto API] and many cryptocurrency wallets. A design goal of UCAN is to leverage existing public key infrastructure (PKI), and supporting these three algoritms achieves that goal. Requiring multiple signature types for broad interoperability is not an unusual design choice; for example, [JWT] suports multiple signature algorithms for a similar reason.
In an ideal world, a single algorithm (Ed25519) would be available everywhere. For many historical reasons, P-256 and `secp256k1` are the only practical options for many applications, such as the [WebCrypto API] and many cryptocurrency wallets. A design goal of UCAN is to leverage existing public key infrastructure (PKI), and supporting these three algorithms achieves that goal. Requiring multiple signature types for broad interoperability is not an unusual design choice; for example, [JWT] supports multiple signature algorithms for a similar reason.

# Related Work and Prior Art

Expand Down

0 comments on commit 059e3af

Please sign in to comment.