Re: [OAUTH-WG] OAuth Digest, Vol 178, Issue 51

[Hector Zepeda <[e-mail]>]

Download and install please

On Thu, Aug 24, 2023 at 6:50 PM <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> 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 <[e-mail]>
> To: Daniel Fett <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>, [e-mail],
>         [e-mail]
> Subject: Re: [OAUTH-WG] SD-JWT does not meet standard security
>         definitions
> Message-ID:
>         <CACsn0cm4crt-F4GJcZHGnhzcBdgZ+JL-DxJ+K=VV3L9UdXD=
> [e-mail]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 24, 2023 at 3:44?AM Daniel Fett <[e-mail]> 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 <[e-mail]>
> To: Watson Ladd <[e-mail]>, Daniel Fett
>         <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>, "[e-mail]"
>         <[e-mail]>,
>         "[e-mail]"
>         <[e-mail]>
> Subject: Re: [OAUTH-WG] SD-JWT does not meet standard security
>         definitions
> Message-ID:
>         <
> [e-mail]
> >
>
> 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 <[e-mail]>
> Sent: Thursday, August 24, 2023 9:08 PM
> To: Daniel Fett <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>
> Subject: Re: SD-JWT does not meet standard security definitions
>
> [You don't often get email from [e-mail]. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Thu, Aug 24, 2023 at 3:44?AM Daniel Fett <[e-mail]> 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 <[e-mail]>
> To: Kristina Yasuda <[e-mail]>
> Cc: Daniel Fett <[e-mail]>, Hannes Tschofenig
>         <[e-mail]>,  IETF oauth WG <[e-mail]>,
>         [e-mail]
> Subject: Re: [OAUTH-WG] SD-JWT does not meet standard security
>         definitions
> Message-ID:
>         <CACsn0cntKgk-nQf71XbdVtbVUXxwt6Njsd3pTg4TB=
> [e-mail]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda
> <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 178, Issue 51
> **************************************
>
-- 
null