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

[Torsten Lodderstedt <[e-mail]>]

> 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.     
> 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