Define use case for this status attestation mechanism

[awoie]

It is not clear to me why other status mechanisms cannot be used instead of the proposed one. It would be good to understand under which circumstances the proposed status mechanism has clear benefits. I believe it is mostly saving HTTP requests for RPs, right?

I don't necessarily agree with the statements made on privacy and trust model that are included in the document. IMO, OAuth Status List is privacy preserving and the trust model could be the same as for the proposed option. In fact, some people are implementing Status List using the existing issuer trust model.

[peppelinux]

@awoie Does the status list prevent the monitoring of the credential status over time, outside the scope of the authentication?

Could you please provide which part of the privacy and trust model statements you don't agree?

this specification enables an OCSP stapling like approach, nothing prevents to merge this approach within the status list specification (as proposed before the born of this specs)

[OR13]

@awoie I think the main benefit is probably presentation size, and verifier complexity.

It's true a holder could present a reasonably fresh signed CRL instead of use OCSP.

It's also true that the status attestation refresh window could impose some connectivity limits on the holder.

As a general rule, many systems are forbidden from calling out to check status, and transmitting an entire CRL only to support a single certificate validation is wasteful from the holder perspective... It also communicates status changes for previously transmitted credentials, or yet to be received credentials... So it leaks information regarding other transactions.