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.

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

Consider implications of autonomous signing mechanisms #176

Open
iameli-streams opened this issue Sep 9, 2024 · 0 comments
Open

Consider implications of autonomous signing mechanisms #176

iameli-streams opened this issue Sep 9, 2024 · 0 comments
Milestone

Comments

@iameli-streams
Copy link

Following up on discussion in the meeting during discussion on https://github.com/creator-assertions/identity-assertion/pull/167/files, we considered supporting "autonomous" signing systems -- mechanisms for named actors to be their own credential holders. There exist a variety of draft DID mechanisms that support such use cases; did:key introduces a mechanism for using any keypair as an identifier, did:pkh contextualizes that method specifically for use in public blockchains, and ethereum-eip712-signature-2021-spec presents a signing scheme for using these methods with the particular mechanism of Ethereum wallet signing.

I posit that EIP-712 signing is the most user-friendly mechanism that presently exists for end users (named actors, in this context) to sign their own content with keys that remain in their possession. Ledger and Trezor have made hardware security mechanisms reasonably user-friendly, and WalletConnect provides a secure mechanism for software to delegate signing to an external device. Let's think of poor Charlie:

One morning, Charlie, an up-and-coming digital artist, woke up to find that one of their designs went viral on social media. Charlie felt upset to see their art detached from their name. Charlie had spent months working on their artwork and was disappointed not to receive credit or compensation for their work. Moving forward, Charlie decides to use the identity assertion to link their name, social media, and copyright information to the art they create. Now, when Charlie posts their content to social media platforms that display Content Credentials, viewers can easily link the artwork back to Charlie.

As one of Charlie's fans, I'm also interested in making sure his work is authentic -- how can I be confident that some new art is coming from him, and not someone who compromised his social media account? That content being signed with a hardware key that he keeps in his possession is one of the strongest possible forms of this; certainly it's much stronger than a third party warranting that they validated a social media account of his at some point. And the workflow is as smooth as possible for him; he hits "Save and Sign", the production software sends a WalletConnect request, his Ledger on the desk lights up, and he presses a button to accept the signing request. Simple, secure, fast.

Two takeaways here:

  1. We should support and encourage end-user signing flows; hardware security is the best available option for fulfilling our goals.
  2. The C2PA spec really needs to support the secp256k curve utilized by most major hardware wallets.
@scouten-adobe scouten-adobe added this to the post-1.1 milestone Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants