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

CIP-0104? | Web-Wallet Bridge - Account public key #588

Merged
merged 11 commits into from
May 14, 2024
Merged

CIP-0104? | Web-Wallet Bridge - Account public key #588

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
a6e11b8
CIP-???? | CIP-30 ext: Account public key
Scitz0 Sep 3, 2023
5ea1f65
Update CIP-XXXX/README.md
rphair Sep 10, 2023
81a0f53
standard form for copyright footer
rphair Sep 10, 2023
7b80406
Update according to #590
Scitz0 Sep 10, 2023
d77d858
Update CIP-XXXX/README.md
Scitz0 Sep 11, 2023
47d548c
change delimiter character as per #594
rphair Sep 19, 2023
ddce93b
title delimiter changed to - as per #594 update
rphair Sep 21, 2023
de648c8
assign CIP number 104
rphair Oct 4, 2023
f7fa913
Updates according to assigned CIP number
Scitz0 Oct 4, 2023
3982706
updates according https://github.com/cardano-foundation/CIPs/pull/601
Scitz0 Oct 17, 2023
df4234e
Move access line to spec section
Scitz0 May 2, 2024
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
46 changes: 46 additions & 0 deletions CIP-XXXX/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
---
CIP: ?
Title: CIP-30 ext: Account public key
Ryun1 marked this conversation as resolved.
Show resolved Hide resolved
Category: Wallets
Status: Proposed
Authors:
- Ola Ahlman <[email protected]>
- Andrew Westberg <[email protected]>
Implementors: [Eternl, newm-chain]
Scitz0 marked this conversation as resolved.
Show resolved Hide resolved
Discussions:
- https://github.com/cardano-foundation/cips/pulls/?
rphair marked this conversation as resolved.
Show resolved Hide resolved
Created: 2023-09-03
License: CC-BY-4.0
---

## Abstract
This CIP extends [CIP-30 (Cardano dApp-Wallet Web Bridge)](https://cips.cardano.org/cips/cip30/) to provide an additional endpoint for dApp to get the extended account public key from a connected wallet.

## Motivation: why is this CIP necessary?
Normally it's up to the wallet to handle the logic for utxo selection, derived addresses etc through the established CIP-30 api. Sometimes however, dApp needs greater control due to subpar utxo selection or other specific needs that can only be handled by chain lookup from derived address(es). This moves the control and complexity from wallet to dApp for those dApps that prefer this setup. A dApp has better control and can make a more uniform user experience. By exporting only the account public key, this gives read-only access to the dApp.

## Specification
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is there a need to support wallet's proving ownership of the shared account key?

Perhaps CIP-30's signed data just be used (if the dApp derives payment/stake keys)?

Copy link
Contributor

Choose a reason for hiding this comment

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

This would add extra friction. All we really need here is a popup asking for permission from the user.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think its enough to handle it through the normal enable() call, if this extension is requested, just show enable popup to either allow or disallow.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah no, what I meant was adding a separate endpoint where the wallet signs with this key to prove ownership.
But I dont think this is needed as existing signData could be used (albeit with extra steps for the verifier).

A new endpoint is added namespaced according to this cip extension number that returns the connected account extended public key as [cbor\<T>](https://cips.cardano.org/cips/cip30/#cbort) defined in CIP30.

### 1. api.cip????.getAccountPub(): Promise\<cbor\<Bip32PublicKey>>

Errors: APIError

Returns hex-encoded string representing cbor of extended account public key. Throws APIError if needed as defined by CIP30.

Copy link
Collaborator

Choose a reason for hiding this comment

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

How should this proposal be versioned? see specification from CIP-0001.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

🤔 ... any recommendation for wording on this?
I'm open to any suggestion really.

Copy link
Collaborator

Choose a reason for hiding this comment

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

something like

"This CIP is not to be versioned using a traditional scheme, rather if any large technical changes are required then a new proposal must replace this one. Small changes can be made if they are completely backwards compatible with implementations, but this should be avoided."

## Rationale: how does this CIP achieve its goals?
Raw cbor is returned instead of bech32 encoding to follow specification of other CIP30 endpoints. Wallets implementing this CIP should, but not enforced, request additional access from the user to access this endpoint as it allows for complete read access to account history and derivation paths.
Copy link
Collaborator

Choose a reason for hiding this comment

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

this CIP should, but not enforced

Should they or not? IMO sharing public keys should not require permission.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's a bit subtle, but connecting a wallet tells the dApp about all the currently used utxos and addresses of a wallet. Sharing the account public keys tells the dApp about any currently used utxos and addresses along with PAST/FUTURE addresses. It's basically asking for an updatable read-only copy of the user's wallet instead of just the current snapshot of a user's wallet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think wallets SHOULD request additional access for the reason Andrew mentioned. But I wasn't sure if CIP should mention it as enforced or just as a recommendation. This is why I expressed myself as I did. In addition to past/future addresses, it will also allow you to derive not just payment and stake keys but also upcoming DRep pub keys (CIP-95).


## Path to Active

### Acceptance Criteria
In order for this standard to be active, the following should be true:
- Implemented by at least two wallets.
- Adopted and used by at least one dApp or infrastructure tool to prove usability.

### Implementation Plan
Communication with additional wallets established to widen availability

## Copyright
[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode
rphair marked this conversation as resolved.
Show resolved Hide resolved