CIP-0093? | Authenticated Web3 HTTP requests

[jmagan]

(rendered CIP document in branch)

[rphair]

This is a sensible and useful proposal (thanks @matiwinnetou @jmagan for the proofreading):

[jmagan]

UPDATE: I added a new implementation with Next JS and Auth JS.

cardano-nextjs-web3-skeleton

[jmagan]

I have changed the url property to uri as I believe uri is a more general term.

[rphair]

@jmagan thanks for the updates. I'm basing my own review, to get ready to promote this to a candidate, on @KtorZ's last review (#442 (review)) so my comments are above in that review. Most issues have been progressed but a few are still unresolved in my opinion.

I think this is currently ready to be marked as a candidate because the pending review items deal with the explanations in the CIP document rather than the soundness of the proposal itself.

So I'd be ready to green-check this as soon as the nitpick below & items still marked unresolved in #442 (review) are addressed and a candidate CIP number is assigned.

[jmagan]

@rphair I did my best in order to improve the quality of this CIP. I hope the changes are good enough. We could talk to include it in a CIP Editor Meeting when you consider it done. Thanks for your time and your valuable feedback. 🙂

[rphair]

@jmagan thanks, I'm marking the issues above resolved because I think they've been addressed; @KtorZ @matiwinnetou please re-open if you think otherwise:

#442 (comment)
#442 (comment)
#442 (comment)
#442 (comment)
#442 (comment)

I've suggested it for our Review agenda for the meeting # 66 in 6 days to consider promotion to a CIP candidate.

[rphair]

@jmagan this is up for Review on our CIP meeting agenda in 20 minutes (see Discord channel)... hope you can participate; will post feedback here in case you can't make it.

[rphair]

Consensus at CIP meeting today is to promote this to a CIP candidate & assign a CIP number (cc @KtorZ).

[jmagan]

Hey @matiwinnetou, I've incorporated the suggested changes:

• Added an actionText field to enhance globalization capabilities.
• Included the option of including either the timestamp or slot field for time.
• Mentioned that additional properties can also be objects.
• Added a new section emphasizing the common usage of JWT tokens for efficient session management.

I hope this covers all the modifications you requested! Let me know if there's anything else I can assist you with.

[rphair]

@jmagan thanks for attending today's CIP editors' meeting and allowing us to move this forward to Last Check in our meeting scheduled 2 weeks from today. In the meantime:

There was a suggestion that the Cardano Foundation (mentioning @matiwinnetou) is using a part of this mechanism in an application, but we agreed today not to require it in Path to Active which only requires implementation in wallets. If it should be merged as Active on the basis of the CF implementation then please adjust the Path to Active accordingly and change the status to Active in the document header. cc @KtorZ

[AndrewWestberg]

I find signData to be a bit of a dead-end when it comes to hardware wallets. Many users are moving to hardware wallets, but everyone using signData for things limits dApp reach considerably. Signing an expired transaction (TTL in the past) with the necessary information achieves the same results and is accessible to hardware wallets in addition to software wallets. It's also easy for wallets to display an expired tag on these types of transactions that are being signed.

[jmagan]

Hello @AndrewWestberg, I'm huge fan of your videos. Actually, I was talking about this today in the CIP Editor Meetings channel on Discord. The CIP-8 already approachs this issue and the wallet can pass to the hardware wallet a hash of the unprotected headers:

Payload encoding

To solve E3, signed_message body header MUST contain hashed: bool as an unprotected header which defines whether or not we signed the payload OR the Blake2b224 hash of the payload. The hash MUST be used in the following two cases

1. The size of the raw payload would otherwise be too big to fit in hardware wallet memory (see E1). Note that the exact size for which this is the case depends on the device.
2. The payload characters (ex: non-ASCII) that cannot be displayed on the hardware wallet device (see E3)

We RECOMMEND showing the user the full payload on the device if possible because it lowers the attack surface (otherwise the user has to trust that the hash of the payload was calculated correctly).

Blake2b224 was chosen specifically because 224 bits is already a long string for hardware wallets.

Maybe, some CIP-30 modification is necessary in order to choose the hash version of the payload.

[rphair]

@jmagan thanks for discussing this at today's CIP Editors' meeting. My understanding of the reservations expressed is that we should take off the Last Check status until the questions are answered about

• whether CIP8 headers should be used instead
• whether alternatives to JSON (particularly CBOR) should be used in the specification.

I apologise for the rough description & if you can to go into detail about those reservations for the record here then please do so.

We also noted that the change to CIP8 would be nontrivial and time-consuming relative to the work you can put into this CIP. Therefore I'm taking off the Last Check label & if you think it will take multiple meeting intervals to progress these issues then please say so and we'll mark this Waiting for Author.

[jmagan]

Hi @rphair, thank you for your comments. I'm planning to address the reasons for not using CIP-8 in the CIP's rationale. Essentially, I will explain that adopting that approach would necessitate modifying both CIP-8 and CIP-30, as well as waiting for corresponding wallet implementations. In contrast, the current implementation is ready to be deployed, allowing us to provide immediate value to the Cardano Web3 ecosystem. However, this doesn't mean that this CIP is intended as a temporary solution while those CIPs are being modified, potentially leading to their deprecation or use as legacy in the future.

Regarding the choice of JSON over CBOR, the CIP already discusses this matter. The requirement for the string to be human-readable is the primary factor, which CBOR does not fulfill. Additionally, JSON is more user-friendly for web developers, who are the target users of this CIP.

[rphair]

@jmagan I am happy to hear that the suggestions about CIP-8 don't need to block this proposal from being merged. Your documenting that part of the rationale will help people decide whether to follow your suggested implementation or to use CIP-8 instead and perhaps write their own "competitive" CIP for it.

From my own experience I agree with your point about the human readability being an important factor for web implementations... similar decisions were made to favour human readable formats in our NFT related CIPs.

Given your last response I think it's appropriate to leave the Last Check label on this CIP because once you've documented the CIP-8 alternative then we'll have addressed the last of the comments that were brought up in yesterday's meeting (cc @Ryun1 @KtorZ @SebastienGllmt)... just please add the CIP-8 additional rationale before our next meeting scheduled in 13 days. 🤓

[jmagan]

Hi @rphair. I had a discussion this morning with @matiwinnetou, and we concluded that the current version of this CIP holds value and can be implemented as is. We also carefully considered the concerns raised by @SebastienGllmt, and we agree that making this CIP idiomatic with Cardano using CBOR would be ideal. Our proposed solution is to proceed with this CIP while simultaneously working on modifying CIP-8 and CIP-30 to define the Payload format as either JSON or CBOR. This approach would allow sufficient time for browser developers to meet the requirements for human readability and make necessary adjustments to the wallet API. Consequently, we can introduce a version 2 of this CIP incorporating COSESign and CBOR, accommodating both realms and ensuring broad support.

[jmagan]

Hi @rphair, I have made the requested modifications. I have added an extension to the rationale section to address the CBOR and JSON dilemma. Additionally, I have included a suggestion from @matiwinnetou to allow numeric strings in the timestamp and slot fields.

Extended rationale:

Alternative implementations

During discussions about this specification, the possibility of modifying CIP-0008 to incorporate the standards defined here was considered. However, a thorough evaluation revealed that this approach would require extensive modifications to CIP-0008 and CIP-0030, leading to significant changes in the Cardano wallet API. Moreover, it would result in a lengthy waiting period for browser wallet developers to implement the necessary requirements. This could potentially bypass important security measures outlined in this CIP, such as the requirement for human readability.

While this alternative approach brings advantages, such as defining the payload in CBOR, which aligns well with Cardano, it also presents challenges. JSON and CBOR offer different levels of expressiveness, and the choice between the two depends on the specific needs of the application. JSON provides a more flexible and widely supported data format, whereas CBOR offers a more compact and efficient representation, particularly beneficial when working with the blockchain.

Considering these factors, it was concluded that deploying this standard as it currently stands, while coexisting with a future version that allows users to choose between JSON and CBOR payloads, would be the most practical approach. This would provide sufficient time for modifying CIP-0008 and CIP-0030, enabling browser wallet developers to fulfill the requirements for human readability and make necessary adjustments to the wallet API. Consequently, a version 2 of this CIP can be introduced, incorporating COSESign and CBOR, accommodating both realms, and ensuring broad support.

New JSON Schema:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "uri": {
      "type": "string",
      "format": "uri"
    },
    "action": {
      "type": "string"
    },
    "actionText": {
      "type": "string"
    },
    "timestamp": {
      "anyOf": [
        {
          "type": "integer"
        },
        { "type": "string", "pattern": "^\\d+$" }
      ]
    },
    "slot": {
      "anyOf": [
        {
          "type": "integer"
        },
        { "type": "string", "pattern": "^\\d+$" }
      ]
    }
  },
  "required": ["uri", "action"],
  "oneOf": [{ "required": ["timestamp"] }, { "required": ["slot"] }],
  "additionalProperties": {
    "type": ["string", "object"]
  }
}

[rphair]

@jmagan thanks for taking care of this & I believe the new Alternative implementations section satisfies the conversation that came up in this week's CIP meeting.

It also seems logical to me that you've also ticked off the two conversation & review items under "Implementation plan" because we've now done this extensively on GitHub and the meetings.

So I guess this is cleanly back to Last Check again scheduled for merge at the next meeting and will ping the other reviewers to confirm & to see if there are any other issues before then.

[Ryun1]

Well written and discussed proposal, good work @jmagan! 🚀

[rphair]

OK @KtorZ I think the proposer has done a great job adapting this proposal to challenges whenever necessary and so it's ready to hit the merge button at the CIP meeting today unless you or anyone express any reservations there (or here). 🚀

[jmagan]

Thank you, @rphair and @Ryun1, for your kind words and the invaluable support provided throughout this journey. Your contributions have been greatly appreciated.

[gitmachtl]

@jmagan is it possible that the libs you provide for cip93 reference implementation do not support hashed payload content?
there are some issue currently with the message signing via hw wallet on voting.summit.cardano.org (https://github.com/cardano-foundation/cf-cardano-ballot) and i am not sure where the failure point it. the hw wallet signs the data normally as a hashed payload (until the payload is super short), but after the wallet connector passes the answer back to the dApp a "INVALID_CIP93_ENVELOPE" comes up.

[jmagan]

Hi @gitmachtl, yes. I'll take a look to it. It's an important feature to be implemented. Can you give me further details about the packages you are using or some way to reproduce the error?

[gitmachtl]

@jmagan turnes out that the used https://github.com/cardano-foundation/cip30-data-signature-parser functions did not support the { "hashed": true/false } header to verify the correct response. but there are already PRs going on to fix it.

[gitmachtl]

i have implemented the CIP8/30 specs pretty early on in https://github.com/gitmachtl/cardano-signer and therefore i went with the full specs for it. from time to time i stumble across implementations that do now have the information about a hashed payload in it. but its clearly stated in the CIP here:

CIPs/CIP-0008/README.md

Line 255 in f389cda

To solve `E3`, `signed_message` body header MUST contain `hashed: bool` as an `unprotected` header which defines whether or not we signed the `payload` OR the `Blake2b224` hash of the `payload`. The hash MUST be used in the following two cases

and now that hardware wallets also implemented message signing, this can cause issues. because the message length for hardware wallets to sign is super limited. therefore the message/payload must be hashed and the COSE_Sign1 signature than includes the { "hashed": true } information. which must be interpreted by a verification function ofcourse, otherwise the signature would not line up.

[jmagan]

@gitmachtl I've spoken with @matiwinnetou and the problem was addressed and there are multiple PRs almost ready to merge. It will be fixed soon.