Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda
 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

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Kristina Yasuda]

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

From: Watson Ladd 
Sent: Thursday, August 24, 2023 9:08 PM
To: Daniel Fett 
Cc: Hannes Tschofenig ; oauth@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  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

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Thu, Aug 24, 2023 at 3:44 AM Daniel Fett  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

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Daniel Fett]

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.


-Daniel

Am 24.08.23 um 11:55 schrieb Hannes Tschofenig:

Hi Watson,


deploying technologies can be complex because the incentives need to
align. Not everything that looks great on paper gets adopted in the time
frame or manner we like. In this specific case U-Prove has not been seen
excitement in the industry. There are reasons but it is difficult to say
what those exactly are.


In the OAuth group we have been trying hard to rally the community
around the use of specific technologies. I see SD-JWT as a stepping
stone in the right direction. As time progresses we will see other
technologies surface again and we have the JSON Web Proof work in our
pipeline.


In any case, we have to not just look at the list of features but also
reach out to those who deploy the technologies in question and to listen
to them.


Ciao

Hannes


Am 23.08.2023 um 07:32 schrieb Watson Ladd:

Dear all,

I read with alarm that the EU Digital Wallet is mandating SD-JWT,
perhaps under the illusion that it meets the standard, 22 year old
security definition for schemes of this type. It of course doesn't, as
said quite clearly in the security considerations section 10.4 and
10.5. Why on earth are we pursing this "solution" when actual
solutions to the problems presented have existed for 19 years? There's
been substantial research on this area, as seen in Microsoft's U-Prove
system just to name one instance.

This is apparently an article of discussion on the EU Digital Wallet
project as well, but I think the IETF needs to have its own discussion
of the issues here and not just say "well, it would be nice if we had
an RFC for this" especially given the negative privacy impacts.

Sincerely,
Watson Ladd

PS: they appear quite aware, but apparently convening the right
committee to approve the signature scheme is too hard. Anyway, not
relevant to us in the IETF.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Rebecca Warren]

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Hannes Tschofenig]

Hi Watson,


deploying technologies can be complex because the incentives need to
align. Not everything that looks great on paper gets adopted in the time
frame or manner we like. In this specific case U-Prove has not been seen
excitement in the industry. There are reasons but it is difficult to say
what those exactly are.


In the OAuth group we have been trying hard to rally the community
around the use of specific technologies. I see SD-JWT as a stepping
stone in the right direction. As time progresses we will see other
technologies surface again and we have the JSON Web Proof work in our
pipeline.


In any case, we have to not just look at the list of features but also
reach out to those who deploy the technologies in question and to listen
to them.


Ciao

Hannes


Am 23.08.2023 um 07:32 schrieb Watson Ladd:

Dear all,

I read with alarm that the EU Digital Wallet is mandating SD-JWT,
perhaps under the illusion that it meets the standard, 22 year old
security definition for schemes of this type. It of course doesn't, as
said quite clearly in the security considerations section 10.4 and
10.5. Why on earth are we pursing this "solution" when actual
solutions to the problems presented have existed for 19 years? There's
been substantial research on this area, as seen in Microsoft's U-Prove
system just to name one instance.

This is apparently an article of discussion on the EU Digital Wallet
project as well, but I think the IETF needs to have its own discussion
of the issues here and not just say "well, it would be nice if we had
an RFC for this" especially given the negative privacy impacts.

Sincerely,
Watson Ladd

PS: they appear quite aware, but apparently convening the right
committee to approve the signature scheme is too hard. Anyway, not
relevant to us in the IETF.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Leif Johansson]

On 2023-08-24 02:02, Michael Prorock wrote:

"Who exactly has an environment where any of the already existing
pairing implementations, or a forthcoming BBS signature scheme
wouldn't be available?"

I have customers who are required to send regulatory trade data that may 
have redactions with FIPS compliant cryptography.  They are ok with 
linkability, but still need selective disclosure capabilities.


A good example would be an agricultural inspection, where the result 
(pass/fail) might be disclosed to some parties, but not to others.


The FIPS and other requirements means we are looking at ES384 and 
similar as our preferred approaches for signatures and would still like 
to selectively disclose data.




This is also the most common case in govt to citizen use-cases.

Unlinkability really isn't an option because most govt have some form of 
linkable identifiers for citizens anyway and insists on using them.


Having said that I know some people are looking at single use sd-jwt 
(you batch issue multiple tokens basically) to introduce some limited 
support for unlinkability.


Just for clarity I repeat: anyone who tells you they know what this 
space is going to look like in the EU probably doesn't understand how 
the process works or are trying to sell you something... or both.


Cheers Leif

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Leif Johansson]

I support adoption too24 aug. 2023 kl. 08:31 skrev Vladimir Dzhuvinov :
  

  
  
I support adoption.

Vladimir Dzhuvinov
On 23/08/2023 20:01, Rifaat Shekh-Yusef
  wrote:


  
  
All,
  
  This is an official call for adoption for the Protected
Resource Metadata draft:
  https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
  
  Please, reply on the mailing list and let us know if you are
  in favor of adopting this draft as WG document, by Sep
6th.
  
  Regards,
   Rifaat & Hannes
  

  
  
  
  ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


  

___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Vladimir Dzhuvinov]

I support adoption.

Vladimir Dzhuvinov

On 23/08/2023 20:01, Rifaat Shekh-Yusef wrote:

All,

This is an official call for adoption for the *Protected Resource 
Metadata* draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *Sep 6th.*


Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[David Waite]

I support adoption

> On Aug 23, 2023, at 11:44 PM, Aaron Parecki 
>  wrote:
> 
> I support adoption.
> 
> Aaron
> 
> 
> On Wed, Aug 23, 2023 at 8:02 PM Rifaat Shekh-Yusef  > wrote:
>> All,
>> 
>> This is an official call for adoption for the Protected Resource Metadata 
>> draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>> 
>> Please, reply on the mailing list and let us know if you are in favor of 
>> adopting this draft as WG document, by Sep 6th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> --
> ---
> Aaron Parecki
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Amir Sharif]

I support adoption of this draft.


On Thu, 24 Aug 2023 at 06:41, Tobias Looker  wrote:

> I support adoption of this draft.
>
>
>
> Thanks,
>
> [image: MATTR website] 
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> tobias.looker@mattr.global 
>
> [image: MATTR website] 
>
> [image: MATTR on LinkedIn] 
>
> [image: MATTR on Twitter] 
>
> [image: MATTR on Github] 
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it – please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
>
> *From: *OAuth  on behalf of Heather Flanagan <
> h...@sphericalcowconsulting.com>
> *Date: *Thursday, 24 August 2023 at 10:51 AM
> *To: *Steinar Noem , oauth 
> *Subject: *Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
>
> EXTERNAL EMAIL: This email originated outside of our organisation. Do not
> click links or open attachments unless you recognise the sender and know
> the content is safe.
>
>
>
> Hi all,
>
>
>
> I have to chime in on this one. +1 to supporting it for adoption!
>
>
>
> -Heather
>
>
>
> On Aug 23, 2023, at 3:46 PM, Steinar Noem  wrote:
>
>
>
> I support adoption
>
>
>
> ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com>:
>
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vennlig hilsen
>
>
>
> Steinar Noem
>
> Partner Udelt AS
>
> Systemutvikler
>
>
>
> | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
*Amir Sharif*
*Researcher*
*Security and Trust Research Unit*
*Cybersecurity Center*
*Fondazione Bruno Kessler, Trento, Italy*
personal page:https://st.fbk.eu/people/amir-sharif
FBK web: www.fbk.eu
Security  web: st.fbk.eu

-- 
--
Le informazioni contenute nella presente comunicazione sono di natura 
privata e come tali sono da considerarsi riservate ed indirizzate 
esclusivamente ai destinatari indicati e per le finalità strettamente 
legate al relativo contenuto. Se avete ricevuto questo messaggio per 
errore, vi preghiamo di eliminarlo e di inviare una comunicazione 
all’indirizzo e-mail del mittente.

--
The information transmitted is 
intended only for the person or entity to which it is addressed and may 
contain confidential and/or privileged material. If you received this in 
error, please contact the sender and delete the material.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth