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

Jump to bottom

feat: Add timestamp conversion for CACAOv3 #233

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

feat: Add timestamp conversion for CACAOv3 #233

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
17 changes: 8 additions & 9 deletions CAIPs/caip-196.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,11 +12,11 @@ replaces: 74

## Simple Summary

A Chain Agnostic CApability Object, or CACAO, is an [IPLD](https://ipld.io) representation of an object-capability.
A Chain Agnostic CApability Object, or CACAO, is an [IPLD](https://ipld.io) representation of an object-capability.

## Abstract

CACAO proposes a way to leverage [varsig](https://github.com/ChainAgnostic/varsig) and [multidid](https://github.com/ChainAgnostic/multidid/) as well as IPLD to create a common representation for various different object-capability formats, such as SIWE, SIWx, and UCAN. The IPLD representation contains common fields shared between these format. In addition this CAIP also registers varsig codes for both SIWE + ReCap and UCAN.
CACAO proposes a way to leverage [varsig](https://github.com/ChainAgnostic/varsig) and [multidid](https://github.com/ChainAgnostic/multidid/) as well as IPLD to create a common representation for various different object-capability formats, such as SIWE, SIWx, and UCAN. The IPLD representation contains common fields shared between these format. In addition this CAIP also registers varsig codes for both SIWE + ReCap and UCAN.

## Motivation

Expand Down Expand Up @@ -46,7 +46,7 @@ type CACAO struct {
iss Principal
aud Principal
s Varsig

v String
att Resources
nnc String
Expand Down Expand Up @@ -145,7 +145,7 @@ According to the [tezos namespace](https://namespaces.chainagnostic.org/tezos/ca

#### UCAN

Most fields in a UCAN should map 1-to-1 with the CACAO IPLD schema.
Most fields in a UCAN should map 1-to-1 with the CACAO IPLD schema.

**Additional fields**

Expand Down Expand Up @@ -326,13 +326,12 @@ uOqJlcm9vdHOB2CpYJQABcRIgEbxa4r0lKwE4Oj8ZUbYCpULmPfgw2g_r12IcKX1CxNlndmVyc2lvbgH

The values in SIWx are encoded as [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) strings, while CACAO requires unix timestamps (in seconds). The algorithm used to convert between the two is outlined below.

### RFC3339 to UNIX + tz-info

1. TODO
### RFC3339 to UNIX + tz-info, UNIX + tz-info to RFC3339

### UNIX + tz-info to RFC3339
Unix timestamp is defined in [POSIX specification](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) (as defined in The Open Group Base Specifications Issue 7, 2018 edition or IEEE Std 1003.1-2017).
It is derived from UTC: regardless of leap seconds, a day has to have 86400 seconds. We can rely on a conversion algorithm provided by an operation system thus.
Comment on lines +331 to +332
Copy link
Collaborator

@oed oed Jun 29, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Would be nice with some more detail here.

  1. If we have timeRFC, how do we get timeUnix and timeTzAndMills?
  2. If we have timeUnix and timeTzAndMills, how do we get timeRFC?

Basically how do we separate the one timestamp into the two fields and vice versa.

Copy link

Choose a reason for hiding this comment

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

instead of trying to split up the timestamp, could we instead just keep the whole timestamp in the fields? e.g.

fct: {
    iat-enc: "1985-04-12T23:20:50.52Z"
    exp-enc: "1990-12-31T15:59:60-08:00"
}

and require that the unix time of these matches those in iat, exp and nbf? it makes these fields slightly longer, but obviates the need for multiple fct fields per time field (i.e. instead of iat-tz and iat-mills we just have iat-enc), and also covers every base

Copy link
Collaborator

Choose a reason for hiding this comment

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

Whats the benefit of this though? We still need to do the conversion of the unix timestamp for verification.

I also never suggested two fct fields. would be more something like:

issued-at (RFC) turns into iat and fct.z-iat (the latter would contain both milliseconds and TZ info)

Copy link

Choose a reason for hiding this comment

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

ah I misunderstood, so we would represent everything after the seconds part? e.g.
1985-04-12T23:20:50.52Z => .52Z
1990-12-31T15:59:60-08:00 => -08:00
1990-12-31T15:59:60.52-08:00 => .52-08:00
In that case it seems to do the trick

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes exactly. And that's what I was hoping this appendix section would cover!

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 might miss or forget some discussion about timezones? Why does one need that? Also, milliseconds - are we in a high-frequency trading realm?

Unix timestamp is UTC (±1 second). You could always convert UTC to another timezone. A wallet definitely knows better how to display a timestamp in a user-friendly way, be it ISO8601 format or "20:00 next Monday".

Why do we have that even in CACAO spec instead of relying on a unix timestamp?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I might miss or forget some discussion about timezones? Why does one need that?

SIWE supports the message having tz info

Also, milliseconds - are we in a high-frequency trading realm?

No but SIWE messages support it so we also need to in this conversion algo. We need to describe it precisely here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh shoot. Right.


1. TODO
We have to have in mind though, that an instant of timestamp might be off by one _leap_ second. As CACAO is mostly consumed by human who care at most about minutes, this is an issue we can neglect.

## Links

Expand Down