Hi all, in the last days, CAProck has gotten some attention and feedback, from people I happen to know are subscribed to this list. So rather than having multiple conversations in parallel, I'd like to summarize here for everyone what is being discussed, and then we can take things from here. (Note, of course, that it's still fine to reach out to me individually.) Post-quantum security There is some valid concern that PQ secure signatures will produce signatures larger than fit into the 64 Bytes that are currently allotted in the specific CAProck scheme, and perhaps even larger than will fit into the ~1200 Byte MTU we're assuming for our 0-RTT authorization. This is somewhat deliberately not addressed at this point, largely because as a practitioner I'm waiting for e.g. NIST recommendations on such signature schemes. But it's clear that this will need addressing.IETF Hackathon Yes, absolutely, if I can manage to attend an appropriate IETF conference, I would love to put this project on the hackathon list. Mostly, I have budget constraints that mean I'm more likely to attend EU conferences, but your employer *hint hint* may be open to make a donation.More complex assertations than authorization tuples MACAROONs or Soutei (not yet added to the draft) replace the authorization tuples with more complex scripts that a recipient can execute to verify whether the requester for a resource matches some attributes (or the object, for that matter) rather than identifying them directly. The result can be considered something of an ephemeral identity. Because a request will specify an action (implicitly or explicitly), and both subject and object can be ephemerally identified in this way, the notion that a request resolves to the boolean presence or absence of an authorization tuple still holds. But the draft is not very clear on this distinction, and in its current form requires that this resolution happens (by whichever means) on the side of the resource owner/issuer/grantor. It would likely be beneficial to open this up a little, and explain that the tuple can be replaced by other assertations without impacting the scheme overall *as long as* the assertation does not introduce some third party resource that can become an SPoF again. Let me know if you'd like to contribute appropriate section(s) to the draft(s); a simple PR on https://codeberg.org/interpeer/specs is a great starting point. And you may/should absolutely add yourself as co-authors if you make such contributions! Jens Interpeer gUG (haftungsbeschraenkt), Greifenberg Registered: Amtsgericht Augsburg, HRB 37686 Geschaeftsfuehrer: Jens Finkhaeuser https://interpeer.io/ ---- From: jens@interpeer.io To: interpeer@lists.interpeer.io Nov 5, 2023, 11:44:37 AM