Re: [OAUTH-WG] Call for adoption - SD-JWT

[Jaromir Talir <[e-mail]>]

On Tue, 2022-08-02 at 12:02 +0200, Torsten Lodderstedt wrote:
> 
> 
> > Am 02.08.2022 um 11:44 schrieb David Chadwick
> > <[e-mail]>:
> > 
> >  
> > 
> > On 01/08/2022 18:39, Warren Parad wrote:
> >  
> > > So the question is how many offline interactions are there, and
> > > what do those look like? 
> > 
> > This to me is the key question. If the vast majority of
> > transactions between the user/wallet and the RP are online (which I
> > believe that most will be), then the client/wallet/user can request
> > a short lived credential on demand from the RS containing just the
> > claims that the RP is requesting. The same access token should be
> > usable for this. This also solves the pair-wise ID issue between
> > the wallet/user and the RP, as the user's key inserted into the
> > credential will be ephemeral.
> > 
> 
> That is certainly feasible and it would solve selective disclosure
> and unlinkability on the RP side. 
> 
> However, it comes at a price. It will tell the issuer a lot about the
> frequency, the time, and the claims a user uses for accessing
> service, degrading privacy towards issuers.
> 
> That’s the reason I would not expect a lot of deployments to embrace
> this pattern. e.g. I would doubt eIDAS 2 goes that way.     

Agree. It definitely doesn't go this way. Here is citation from
regulation proposal:
"Wallet shall ensure that trust service providers of qualified
attestations of attributes cannot receive any information about the use
of these attributes"
http://timspeelman.nl/eidas/#A6a(4)(b)

I could also use another citation:
"Wallet shall enable user to securely request and obtain, store,
SELECT, combine and share, in a manner that is transparent to and
traceable by the user, the necessary legal person identification data
and electronic attestation of attributes to authenticate online and
offline in order to use online public and private services"
http://timspeelman.nl/eidas/#A6a(3)(a)

To emphasize this, regarding discussion whether there are use cases for
SD-JWT or not - there are 27 member states of EU that are working on
regulation where it looks like SD-JWT fits it's requirements. 

> > For those (possible few) transactions in which the wallet is
> > offline, then the wallet has to obtain the (possibly selectively
> > disclosed) credential before it is needed. But this is already the
> > case today with boarding passes. I load it onto my phone whilst I
> > am online at home, and then I present it offline at the airport
> > e.g. via a QR code. So using this model the user can go to the RS
> > when online, obtain a short lived selectively disclosed credential
> > that they know will be needed later (e.g. age over 18 for entering
> > a nightclub) and then present it offline when they arrive at the
> > nightclub.
> > For those (possibly even fewer) transactions in which the user is
> > suddenly caught offline e.g. on the top of a mountain by a police
> > officer, then I can see that the SD-JWT with blinded property names
> > and values is a suitable solution. The user might have a few of
> > these in their wallet, each being one-time use with a different
> > key, that once selectively disclosed are discarded. The user/wallet
> > can refresh the store periodically (or the wallet could do this
> > automatically ensuring that a small number are always present).
> > These would also need to be relatively short lived otherwise a
> > revocation mechanism would need to be introduced (horror of
> > horrors, especially on the top of a mountain with no access to the
> > revocation list).
> > Kind regards
> > David
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth