Richard Barnes said:

Daniel Fett said:

Richard Barnes said:

Daniel Fett said:

Richard Barnes said:

Daniel Fett said:

Richard Barnes said:

the key binding is the only thing that makes the three-party model work!

There are applications where key binding is not required or enforced. This allows for replaying credentials, but that may be intentional.

C'est magnifique, mais ce n'est pas la modèle à trois

Of course it still is.

As above, it's an Aleph-Null-party model, since you can have an infinite chain of verifiers replaying the token to one another. Honestly, I'm kind of baffled as to why anyone wants this. Key binding is not that hard.

A Verifier might be interested in learning that a credential was issued (e.g., XYZ License for John Doe), but may not care about who presents it in that moment.

I would be interested to understand the use case where the Verifier gets useful information from the credential, but does not associate it with the presenter.

BTW that still doesn't seem like a three-party model, because you don't have a meaningful Holder -- the Holder is just a store-and-forward relay for the credential, doesn't have an actual role in the protocol. Even if you ignore replay, it's a two-party model.

Yes, the holder would be 'degraded' to stora-and-forward in this case.

Examples: For better or worse, covid vaccination credentials were not key-bound. That was convenient for paper-based presentation and having your family's credentials on your own phone.

Another real-life example: I recently had to sent a picture of my physical driver's license to a company just to prove that it exists (for insurance purposes, so that they can record me as a permitted driver for a friend's car). They didn't care who presented it. So while the credential supports holder binding (here via biometrics), not all verifiers are interested in checking it.

Meeting Chat Log		Web Authorization Protocol (oauth) WG
Title		Chat Log IETF118: oauth: Wed 14:30
Session		Materials
Last updated		2023-11-08

Chat Log IETF118: oauth: Wed 14:30 chatlog-118-oauth-202311081430-00

Chat Log IETF118: oauth: Wed 14:30
chatlog-118-oauth-202311081430-00