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.
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. Best, Kristina Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Watson Ladd <watsonbl...@gmail.com> Sent: Thursday, August 24, 2023 9:08 PM To: Daniel Fett <m...@danielfett.de> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; oauth@ietf.org <oauth@ietf.org>; draft-ietf-oauth-selective-disclosure-jwt....@ietf.org <draft-ietf-oauth-selective-disclosure-jwt....@ietf.org> Subject: Re: SD-JWT does not meet standard security definitions [You don't often get email from watsonbl...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Thu, Aug 24, 2023 at 3:44 AM Daniel Fett <m...@danielfett.de> wrote: > > Thanks, Hannes. > > The fact that technologies like AnonCreds are based on such old principles, > yet they are not uniformly standardized, often times limited to a few > implementations that may or may not be secure, are full of security footguns, > lack hardware support, and are just extremely hard or impossible to deploy > speaks for itself. > > That's why things like SD-JWT exist and gain traction. > > Yes, you have to jump through hoops to get unlinkability, but it is not > impossible, and it seems to be a good tradeoff for many. Is there a document describing this that we can compare to the BBS version? Because it's a lot harder than you think: you need a blind signature and cut and choose for the credential openings (or rerandomization via structure preserving signatures, hello pairings), you need to deal with exhaustion of the supply of tokens, your issuance process has to be repeatable at low cost, so that's also getting messy, and then the hardware binding has its own special problems. None of that is in this draft, and I think it would be a lot better if we spelled it out here or someplace else to get a better sense of the tradeoffs. I would also like to point out that if end users don't like the privacy aspects, they simply won't use this technology. That's a very serious deployment issue. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
