[{"author": "Christopher Patton", "text": "

Hi everyone!

", "time": "2023-11-09T14:02:29Z"}, {"author": "Renzo Navas", "text": "

Hello

", "time": "2023-11-09T14:04:20Z"}, {"author": "Christopher Patton", "text": "

What are our use cases for BBS signatures?

", "time": "2023-11-09T14:25:39Z"}, {"author": "David Waite", "text": "

Representing rich credentials with identity attributes which may be redacted, and presented without correlation

", "time": "2023-11-09T14:28:44Z"}, {"author": "Christopher Wood", "text": "

@ChrisP: Privacy Pass is one use case

", "time": "2023-11-09T14:30:43Z"}, {"author": "David Waite", "text": "

There Jose-json-web-proofs is attempting to describe a container format for these sorts of signatures/proofs

", "time": "2023-11-09T14:30:47Z"}, {"author": "Christopher Patton", "text": "

I'm a bit worried of having two non-PQ secure tools for the same purpose, but it sounds like this gets us something that RSA blind signatures don't get us.

", "time": "2023-11-09T14:34:02Z"}, {"author": "Richard Barnes", "text": "

meetecho camera is not capturing the speaker

", "time": "2023-11-09T14:35:02Z"}, {"author": "Christopher Patton", "text": "

^ @Nick Sullivan

", "time": "2023-11-09T14:35:44Z"}, {"author": "Lorenzo Miniero", "text": "

Richard: there doesn't seem to be one?

", "time": "2023-11-09T14:35:48Z"}, {"author": "Hubert Kario", "text": "

there a 3 microphones and 2 cameras, so I'm guessing that's why

", "time": "2023-11-09T14:35:49Z"}, {"author": "Lorenzo Miniero", "text": "

Or are they in a different spot?

", "time": "2023-11-09T14:35:54Z"}, {"author": "Richard Barnes", "text": "

not sure. sounded like they were in the room

", "time": "2023-11-09T14:36:36Z"}, {"author": "Lorenzo Miniero", "text": "

Hubert: that may be it, we have two cameras that are pointing at the mic lines in the corridor

", "time": "2023-11-09T14:37:21Z"}, {"author": "Kristina Yasuda", "text": "

To be very clear, EU eIDAS digital identity wallet work cannot use BBS signatures without JWP work (credentials/payload layer) in JOSE WG

", "time": "2023-11-09T14:38:14Z"}, {"author": "Nick Sullivan", "text": "

There are three mic lines, but I think only cameras on two of the three.

", "time": "2023-11-09T14:38:54Z"}, {"author": "Richard Barnes", "text": "

Also, it's not clear that \"issuing credentials frequently\" is a non-starter. There is also work on automating credential issuance that could support a fair degree of unlinkability without needing BBS

", "time": "2023-11-09T14:44:19Z"}, {"author": "Phillip Hallam-Baker", "text": "

We might be seeing a case here for moving from GCM to OCB for authenticated encryption - the Tamrin models will cost so much less to run.

", "time": "2023-11-09T14:54:03Z"}, {"author": "Christopher Patton", "text": "

This is very cool work.

", "time": "2023-11-09T14:56:11Z"}, {"author": "Phillip Hallam-Baker", "text": "

This might actually be a serious point, the state space required to verify will expand when using AEADs that are non nonce reuse resistant.

\n

Composing one protocol on another is going to cause things to grow expopnentially.

", "time": "2023-11-09T14:56:50Z"}, {"author": "Justus Winter", "text": "

(s/GPG/OpenPGP/g please)

", "time": "2023-11-09T14:57:21Z"}, {"author": "Alison Becker", "text": "

this would be great work to present/discuss to the UFMRG group as well!

", "time": "2023-11-09T14:57:56Z"}, {"author": "Richard Barnes", "text": "

tbh when i was reading the agenda, i read this as \"The Majestic VDAF\" on first pass, and was like \"awww yeah it is\"

", "time": "2023-11-09T14:58:23Z"}, {"author": "Christopher Patton", "text": "

lol

", "time": "2023-11-09T14:58:48Z"}, {"author": "Christopher Patton", "text": "

We can call it that if you want, Ricahrd

", "time": "2023-11-09T15:00:15Z"}, {"author": "Vasilis Kalos", "text": "

Richard Barnes said:

\n
\n

Also, it's not clear that \"issuing credentials frequently\" is a non-starter. There is also work on automating credential issuance that could support a fair degree of unlinkability without needing BBS

\n
\n

Agreed that it is not a \"non starter\". I think it depends on the use case. BBS seem better suited when unlinkability against the Issuer is desirable, (and also maybe cases that credentials will be used at a high rate).

", "time": "2023-11-09T15:01:17Z"}, {"author": "Richard Barnes", "text": "

@Vasilis Kalos What do you mean \"unlinkability agains the issuer\"? The point of a credential is to encode information the issuer associates with the subject, so presumably the verifier / relying party needs to know at least that the issuer is a party that the verifier trusts.

", "time": "2023-11-09T15:04:05Z"}, {"author": "Christopher Patton", "text": "

@Christopher Wood We don't yet have an apples-to-apples comparison. Probably the CPU time will be higher and the communication cost slightly higher.

", "time": "2023-11-09T15:09:20Z"}, {"author": "Christopher Wood", "text": "

As I said at the mic, I think performance is the least interesting aspect right now :)

", "time": "2023-11-09T15:12:10Z"}, {"author": "Vasilis Kalos", "text": "

Richard Barnes said:

\n
\n

Vasilis Kalos What do you mean \"unlinkability agains the issuer\"? The point of a credential is to encode information the issuer associates with the subject, so presumably the verifier / relying party needs to know at least that the issuer is a party that the verifier trusts.

\n
\n

That's correct. Sorry, should have clarified. I meant that the Issuer will not be able to \"track\" the credential. So if the Verifiers work together with the Issuer (or if they are the same entity), the Issuer will not be able to link a BBS proof presentation to the user that created it (or rather the signature/signed-messages that where used to generate it).

", "time": "2023-11-09T15:14:49Z"}, {"author": "Richard Barnes", "text": "

I see, thanks!

", "time": "2023-11-09T15:18:25Z"}, {"author": "Richard Barnes", "text": "

I agree that that's a property you can't get from simply issuing multiple credentials with standard signatures. though you might not need full BBS; a blinded signature seems like it could suffice

", "time": "2023-11-09T15:19:13Z"}, {"author": "Phillip Hallam-Baker", "text": "

I can't see any point in trying to move away from RSA 1.5, I am only supporting RSA for compatibility at this point.
\n(EC) Diffie Hellman based approaches do appear to be a lot more robust as a matter of structure.

", "time": "2023-11-09T15:24:08Z"}, {"author": "Hubert Kario", "text": "

as long as you have support for it, you will be vulnerable, even if it's just the compatibility API

", "time": "2023-11-09T15:28:02Z"}, {"author": "Vasilis Kalos", "text": "

Richard Barnes said:

\n
\n

I agree that that's a property you can't get from simply issuing multiple credentials with standard signatures. though you might not need full BBS; a blinded signature seems like it could suffice

\n
\n

Yes that's true. The hope is that BBS will provide an easier (and more efficient) way to provide the combination of those features (note unlinkability against the Issuer does not need blinding in BBS), together with the ability to be easily combined with other zk-protocols as well.

", "time": "2023-11-09T15:30:22Z"}]