> Am 02.08.2022 um 11:44 schrieb David Chadwick > <d.w.chadw...@verifiablecredentials.info>: > > > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
