Download and install please On Thu, Aug 24, 2023 at 6:50 PM <oauth-requ...@ietf.org> wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: SD-JWT does not meet standard security definitions > (Watson Ladd) > 2. Re: SD-JWT does not meet standard security definitions > (Kristina Yasuda) > 3. Re: SD-JWT does not meet standard security definitions > (Watson Ladd) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Aug 2023 13:07:39 -0700 > From: Watson Ladd <watsonbl...@gmail.com> > To: Daniel Fett <m...@danielfett.de> > Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>, oauth@ietf.org, > draft-ietf-oauth-selective-disclosure-jwt....@ietf.org > Subject: Re: [OAUTH-WG] SD-JWT does not meet standard security > definitions > Message-ID: > <CACsn0cm4crt-F4GJcZHGnhzcBdgZ+JL-DxJ+K=VV3L9UdXD= > y...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > > > ------------------------------ > > Message: 2 > Date: Thu, 24 Aug 2023 20:32:02 +0000 > From: Kristina Yasuda <kristina.yas...@microsoft.com> > To: Watson Ladd <watsonbl...@gmail.com>, 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: [OAUTH-WG] SD-JWT does not meet standard security > definitions > Message-ID: > < > sa1pr00mb13101b25440011fd872fd7eee5...@sa1pr00mb1310.namprd00.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230824/f2163fef/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Thu, 24 Aug 2023 16:49:45 -0700 > From: Watson Ladd <watsonbl...@gmail.com> > To: Kristina Yasuda <kristina.yas...@microsoft.com> > Cc: Daniel Fett <m...@danielfett.de>, Hannes Tschofenig > <hannes.tschofe...@gmx.net>, IETF oauth WG <oauth@ietf.org>, > draft-ietf-oauth-selective-disclosure-jwt....@ietf.org > Subject: Re: [OAUTH-WG] SD-JWT does not meet standard security > definitions > Message-ID: > <CACsn0cntKgk-nQf71XbdVtbVUXxwt6Njsd3pTg4TB= > g6qwh...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 178, Issue 51 > ************************************** > -- null
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
