Should iss not be a DID PKH? Feels like we can collapse chainId + address into that?

Should iss not be a DID PKH? Feels like we can collapse chainId + address into that?

True. Thank you. When writing the first draft, I mistakingly looked at an old version of did-pkh specification, which did not include chain information. Changed the spec here.

Is there a preferred precision for the Unix time stamps? Microsecond? Nanosecond?

w3c/vc-data-model#846
^If we really wanted to be strict on time and future-proof against ecosystem-wide timestamp changes...

It seems there is a round-trip inconsistancy between SIWE's string representation and CACAO. Valid SIWE messages can contain timestamps which have timezone offsets, which is included in the signing/verification input. When such a message is converted to CACAO form the timestamps are converted into UNIX time, discarding the time zone. Verifying the signature for such a CACAO would fail, as re-serializing the fields into SIWE form will represent all timestamps as UTC. I'm not opposed to requiring/generally expecting UTC timestamps but the SIWE spec doesnt require it, so not all SIWE messages will be losslessly convertable to CACAO form.

@chunningham huh, I was under the impression that SIWE required the timestamp to always be UTC.

@chunningham thanks for the notice. Apparently, date-time per ISO8601 indeed contains time zone specifier, and it is not required to be UTC, which we lose when converting to unix timestamp. We should adjust the spec to retain that information.

@ukstv also, does ISO8601 support ms or not? If they do we need to solve for ms since UNIX timestamps are in seconds only.

@ukstv also, does ISO8601 support ms or not? If they do we need to solve for ms since UNIX timestamps are in seconds only.

It does. Instead of unix timestamp we have to use full ISO8601 specifier, as string.

If possible, I'd suggest RFC3339 as it's a little more restrictive, but in ways that most people would expect (ISO8601 allows for example "2022-100" = 100th day of 2022). IME when most people say ISO8601 they mean RFC3339. IIRC the SIWE spec is being updated to resolve the inconsistancy between ISO8601 in spec text and RFC3339 in the ABNF, in favour of RFC3339 everywhere (as ultimately the goal is for the message to be layperson-readable).

Updated the spec. Now date-time values are encoded as a string, which should be formatted as per RFC3339. Added a note on possible inclusion of milliseconds.

Also, updated the example. Now it contains correct dates and issuer now is proper did:pkh.

I was proposing to @oed a JSON-RPC method where a dapp can use a chain-agnostic interface to request a CACAO object by providing the payload params only and receiving a full object for CACAO with a header and a signature

However I think that the type for message construction (eg. eip-4361) should be specified from the dapp side as well and this would require splitting how CACAO types are currently specified

Essentially we now have two types:

• eip4361-eip191
• eip4361-eip1271
  But this includes both a standard for message construction and a standard for signature verification.

From my POV the responsibility of defining message construction is of the Dapp and and defining signature verification if of the wallet.. so if we split these two types then we could have a much better API between the two

The dapp requests a CACAO signature by providing a header and payload with type eip4361 and then the wallet can return the full CACAO object with a signature that includes the type eip191 or eip1271

So an example would be something like this?

{
  h: {
    t: 'eip4361'
  },
  p: { ... }
  s: {
    m: {
      t: 'eip191'
    },
    s: ...
  }
}

Or maybe assume signature always have a type?

{
  h: {
    t: 'eip4361'
  },
  p: { ... }
  s: {
    t: 'eip191'
    s: ...
  }
}

I'd assume signatures always have a type, to prevent ambiguity. Is it possible to include a compound object as the signature value? Specifically I've worked a little on a ZCAP-LD representation for CACAO with a linked data proof as the signature value (speculatively with type zcapld-ldp, but potentially distinguishing between invocation and delegation types, i.e. something like zcapInv-ldp and zcapDel-ldp).

@oed correct, the second one would be the preferred one

{
  h: {
    t: 'eip4361'
  },
  p: { ... }
  s: {
    t: 'eip191'
    s: ...
  }
}

Discussed on today's call: draft will be updated to reflect split typing, if ready for review before next meeting we will tag reviewers from both implementing companies and an editor.
Implementer's listing desired, we could add a self-PR registry to that CAIP.

Updated the spec for split typing, mentioning future registries for signatures and payloads.

@chunningham what is the best way to link to your CACAO implementation?

I'm still working around some ipld issues. I just moved laptops but will upload the repo shortly. I've also noticed that nonce is an int in this model, while SIWE uses alphanumeric strings, is that an issue?

@chunningham In the schema description, nonce is String. It is the example, that used integer nonce. Changed it.

I think I found a bug in the example:

{ ... "p": { ...
    "aud": "http://localhost:3000", ...
    "uri": "http://localhost:3000/login", ...
  }, ...
}

Shouldn't be this rather the following?

{ ... "p": { ...
    "aud": "http://localhost:3000/login", ...
    "domain": "localhost:3000", ...
  }, ...
}

Two things:

• domain according to SIWE is only the authority party
• uri should be called domain according to the payload spec, see below ...

type Payload struct {
  domain String // =domain
  aud String // =uri
  ...
}

Nice catch @awoie!

Thank you @awoie !! Changed the example to conform with the spec.