Slightly more complex use-cases?

[quartzjer]

I think Oberon is very interesting, I understand it to be a very clean and simple boolean token, minimalist.

I can imagine a lot of use cases right away though where just a bit more policy is needed, even if it's as simple as adding an expiration.

You mention in the crypto definition that attributes can be easily added, is that on the roadmap to also document/support or do you want to keep Oberon very lightweight/focused on just yes/no access?

[mikelodder7]

I'm interested in adding it yes. I've only been wanting to add things as needed. However, this could handle that already in its given state by concatenating the id to the expiration. If the expiration is always disclosed then this is the preferred option. If you'd like to not disclose it then I'd have to add some more work.

[quartzjer]

Expiration being linkable, wouldn't want it exposed for privacy use-cases.

That does also imply requiring a "exp < now" zkp step also though to keep it unlinkable.

[mikelodder7]

Expiration is usually exposed for quick checks. The easier solution is the public key is rotated every epoch which avoids the need for that field.
ZKP based range proofs are expensive relatively speaking.

[tmarkovski]

@mikelodder7 it seems exposing the id as an array would be fairly straight-forward and It'll allow us to feed in ID message statements, instead serializing them into byte string. This wouldn't add much value, but it seems like a required work for adding selective disclosure next, which I'd be happy to see being added.
Thanks for releasing this.