query language requirements discussion: based on credential status?

[Sakurann]

Should a verifier be able to specify a requested credential based on credential's status - is it active or not (not revoked, not suspended, etc.)? (one comment on this issue, not enough discussion)

[awoie]

IMO, this should not be a requirement. That is purely verification policy related and we would start entering a rabbit hole with this.

Furthermore, it would also force the wallet to obtain the latest status which cannot be done in all situations.

[jogu]

I think we need to be very clear on the terminology and what's being discussed here.

e.g. There are at least some use cases where a passport or driving license that is beyond it's "date of expiry" (and hence no longer valid for driving/travel purposes), or where driving privileges have been suspended/revoked, can still be used for identity verification.

I think those things are all part of the credential data, and already intended to be possible to query on, and hence not what this issue is talking about.

It would be good to know what use cases the people proposing this are thinking about.

On Oliver's comment:

Furthermore, it would also force the wallet to obtain the latest status which cannot be done in all situations.

I don't think that automatically follows; we could view it as a best effort where the wallet at least wouldn't let the user return a credential that the wallet already knows has been revoked/suspended.

[awoie]

I think we need to be very clear on the terminology and what's being discussed here.

e.g. There are at least some use cases where a passport or driving license that is beyond it's "date of expiry" (and hence no longer valid for driving/travel purposes), or where driving privileges have been suspended/revoked, can still be used for identity verification.

I think those things are all part of the credential data, and already intended to be possible to query on, and hence not what this issue is talking about.

It would be good to know what use cases the people proposing this are thinking about.

On Oliver's comment:

Furthermore, it would also force the wallet to obtain the latest status which cannot be done in all situations.

I don't think that automatically follows; we could view it as a best effort where the wallet at least wouldn't let the user return a credential that the wallet already knows has been revoked/suspended.

I would object adding this feature as a requirement.

[jogu]

I would object adding this feature as a requirement.

For clarity, are you objecting to the query language supporting this concept, or objecting to it being mandatory to implement?

[awoie]

I would object adding this feature as a requirement.

For clarity, are you objecting to the query language supporting this concept, or objecting to it being mandatory to implement?

IMO, I would object to both. I don't think there is enough clarity on that. We don't have a lot of implementation experience with any status method, nor with status flags issuers might use. For example, suspended was mentioned as one example in the mDL context, but for mDL the status does not even refer to the underlying document validity, it refers only to the proof (i.e. MSO) and would only reflect revoked/not revoked.

[David-Chadwick]

My favoured approach is to not include this feature in the initial protocol support. It's up to the verifier to determine its requirements after receiving the credential from the user.

[selfissued]

I would need to be convinced that querying for credentials with a particular status can't be accomplished by querying based on claims in the credential before supporting it as a separate feature.

[Sakurann]

For VCs this can be quite complex, as a credential can be expired and suspended at the same time. The credentialStatus can contain multiple sources and the possible states are fully custom (though only suspended & revoked are common). Expiration of a VC is independent of its status. With current implementations in the VC world (e.g. Bitstring Status List), just sharing the credential status information also has major impact on the privacy - being able to selectively share it could be a use case (though it's hard for me to come up with good examples).

this was the original comment.

[Sakurann]

WG call: no support to add this as a separate requirement. the problem space and status list space are both seems to be underspecified. + it is the responsibility of the verifier to check the validity of the credential based on its policy