Re: Call for adoption: draft-hardt-httpbis-signature-key-08 (Ends 2026-09-07)

[Anders Rundgren <[e-mail]>]

On 2026-08-21 17:57, Dick Hardt wrote:
> Anders, HTTP Message Signatures authenticate the HTTP request, which is why the verifier needs a way to get a key before checking the signature. Your example signs a payload and carries its keys inline, so no key resolution question arises at the HTTP layer.

Hi Dick,
The EU Digital Identity Wallet (EUDIW) builds on OpenID4VP where the signature, key (or key identifier), and associated data are provided in the Body of HTTP requests or responses.

This makes sense for schemes depending on serialized data. In the example, objects are stacked as a result of a multi-step process.  It is not very clear how you would do that using HTTP signatures.

However, my message should only be seen as a comment ("for the record"), not as an objection to draft-hardt-httpbis-signature-key-08.

Regards,
Anders


> 
> On Fri, Aug 21, 2026 at 4:22 PM Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     I'm not objecting to adopting draft-hardt-httpbis-signature-key-08.  However, when it comes to universality of HTTP-based signature solutions, there may be more to come.
> 
>     Below is a an example of a fictitious payment-authorization scheme where an outer Merchant-signed authorization-object embeds a Payer-signed authorization-object.  HTTP POST Body element:
> 
>     1010(["https://payment.std/merchant-authz <https://payment.std/merchant-authz>", { # Object type indicator
>         1: "https://mybank.fr/pay <https://mybank.fr/pay>",    # Target URL
>         2: "DE02202208000051066366",   # Merchant receive account
>         3: "2025-04-23T09:34:08-05:13",
> 
>     # Embedded Payer authorization
>         4: 1010(["https://payment.std/payer-authz <https://payment.std/payer-authz>", { # Object type indicator
>           1: {
>             1: "Space Shop",
>             2: "435.00",
>             3: "USD"
>           },
>           2: "spaceshop.com <http://spaceshop.com>",
>           3: "FR7630002111110020050014382",   # Payer source account
>           4: "https://banknet2.org <https://banknet2.org>",          # Payment network/scheme
>           5: "2025-04-23T09:34:08-05:00",
>     # Payer signature
>           simple(99): {   # Reserved signature container label
>             1: -19,  # COSE algorithm (Ed25519)
>             4: {     # COSE public key
>               1: 1,
>               -1: 6,
>               -2: h'fe49acf5b92b6e923594f2e83368f680ac924be93cf533aecaf802e37757f8c9'
>             },
>             6: h'1801a1e636aabd090a79ce5373ea88f9c43be0c10ff24147e86c8cbd9069441ed63cd94d6a6fc706aabeda410dd070306b9746f0e702b7a6783ce0c925014a0a'
>           }
>         }]),
>     # End Payer authorization
> 
>     # Merchant signature
>         simple(99): {   # Reserved signature container label
>           1: -9,   # COSE algorithm (ESP256)
>           4: {     # COSE public key
>             1: 2,
>             -1: 1,
>             -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5',
>             -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8'
>           },
>           6: h'd8388c53e1c339ebc6af784a4c7aefa51de65fdc3f30d2dda16291f9e8388baa7d2bec6f114ccb3b4fed34fa0bd1c096bf56fe5bcc569283aea65aebc4a2bb4c'
>         }
>     }])
> 
> 
>     Note: this scheme is using Deterministically Encoded CBOR.  For readability purposes only, CBOR data is shown in diagnostic (textual) notation.
> 
>     Thanx,
>     Anders
>     https://test.webpki.org/csf-lab/home <https://test.webpki.org/csf-lab/home>
>