On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda <kristina.yas...@microsoft.com> wrote: > > First of all, BBS and SD-JWT are not comparable apple to apple. BBS is a > signature scheme and it needs to be combined with few other things like JWP > or BBS data integrity proof type (https://www.w3.org/TR/vc-di-bbs/) with > JSON-LD payload. While SD-JWT is a mechanism that can be used with any crypto > suite.
Agreed: the relevant comparison is at the level of systems based on these formats. That makes it more difficult to have a discussion of the security of the overall system when these documents go in other places, and this might not be the right vehicle for it. > > Second, how to do batch issuance of the credential (honestly, of any > credential format: not just SD-JWT VCs but also mdocs and JWT-VCs) and > whether it can be done low cost is out of scope of the credential format (or > any of its components) specification itself. Btw when using OpenID4VCI (an > extension of oauth), batch issuing SD-JWTs does not need a blind signature > and I do not know what you mean by exhaustion of the supply of tokens, there > are only access token and refresh token involved in a usual manner. So the issuer knows what it signed? Then it's capable of linking all presentations to each other because the signature and message is shown to each verifier even if different commitments are opened each time. That's a serious problem. Separately, if each SD-JWT is one use only, then the issuer needs to be available for refresh once the tokens are all used, which is a troublesome proposition. It's a very different model from a one time issuance. VC usecases are likely to lend themselves to things that don't look like oauth in terms of availability, and as we learned from OCSP running services that must be up is hard. I want to be clear: the threat model that's applicable to real people across the web has the issuer working with data sent to the verifiers to try to determine what the holder did. This is extremely unlike real world credential presentation where e.g. showing my drivers license to a bouncer doesn't mean the DMV knows what bar I went to. We have very clear guidance in RFC 8890 from the IAB that we are supposed to take these risks seriously, and privilege them over other considerations. The applications to Digital Wallets when combined with a push for Age Verification are exactly the sort of thing where people will make expedient choices (use SD-JWT with what's being issued) in a way that creates an enormous privacy risk that is not obvious to end users. Sincerely, Watson Ladd _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
