vc-data-model
vc-data-model copied to clipboard
w3c
Standardize recording a pre-issuance DID Auth VP as evidence property
It is generally considered best practice to perform a DID Auth before issuing a VC with a particular DID as subject.
However, there is currently no agreed-upon way for a verifier to verify that this best practice was performed for a particular VC.
A standard way to record the result of that DID Auth in the VC itself would allow verifiers to prove a DID Auth was performed before issuance.
The simplest way to do this would be to simply put the VP from the DID Auth directly in the evidence property. In many cases, this will be overkill, but for others, it will enable a rigorous verification.
A more sophisticated way would be to have the challenge nonce include a hash of the to-be-issued unsigned VC, such that the DID Auth challenge proves not just that the issuer had a VP from a DID Auth with the subject ID, but that, in fact, the DID Auth was provably for the VC in question.
I might call this an elite practice, meaning that it's the best you can do--and not always worth the trouble. However it would give the verifier proof that at the time of issuance, the issuer had proven that the subject controlled over the DID used in that particular VC.
This came up during the VC API call last week, transcription is here: https://w3c-ccg.github.io/meetings/2022-07-26-vcapi/#topic-3
I agree that this is an interesting topic to consider, and while it might be overkill for a chunk of use cases, we might want to put in the effort to define this in more detail (for example, in the Implementation Guide).
Could this be related to @awoie 's ideas about holder binding? https://github.com/w3c/vc-data-model/issues/882
Anyway this sounds useful. Not sure if this would go into the VC Data Model spec, or Implemenation Guide, or maybe in a separate "evidence scheme" spec (e.g. DIDAuthVPEvidence2022 ?), just like there are dedicated specs for certain proof types, revocation mechanisms, etc.
This sounds to me like it's bleeding over into protocols - which we're not doing - rather than data model.
@selfissued I see it as providing the data model to express a common best practice for identity assurance.
The point is not a protocol that defines how such an evidence property should be constructed, in terms of over-the-wire interactions. Rather, it's how do we represent, in a pure data model, the information that would allow a verifier to verify that a particular form of identity assurance was performed by the Issuer prior to issuing.
Right now, there is no standard, so anyone using evidence in this fashion is doing so in an non-interoperable way. Seems like it would be good to develop consensus on a common way to do this.
I am a huge fan of the evidence property, and I always wished there was some way of registering, harmonizing, open sourcing, or even just documenting usages of it. Doesn't have to get more detailed in the spec, but just a pointer to some ways some systems use it might be non-normative nudge enough...
I can definitely see a lot of value in expanding on the evidence property. I think these make more sense in the VC extensions registry rather than the core data model spec. Not just for encouraging best practices in auth, but also for expressing existing schemes like NIST or eIDAS levels of assurance.
As mentioned by @logpo and @peacekeeper, I agree: it's not clear where the best landing spot is for this evidence specification. Maybe something like @peacekeeper's DIDAuthVPEvidence2022 would be a good, but separate from core, normative specification produced by the group.
See https://w3c-ccg.github.io/vp-request-spec/#did-authentication
We need to relate DID Auth to Evidence, by example...
Then encourage or discourage its use in that manner.
Can't be ignored though, because we see guidance emerging in the wild.
Needs an example credential with "Evidence" that related to DID Auth.
Some additional data, Jobs for the Future did use DIDAuth across a number of implementations (17+)... so we do have a data structure that could be put in evidence... but perhaps it would be best to define that outside of the WG for now and reference it in the upcoming "VC Directory Of Things We Know About"... that would demonstrate interop and use of the property w/o the VCWG having to normatively define something (and invite debate around the specifics).
Is anyone using evidence in this way?
We probably don't have enough implementations to keep it through CR, so we're marking pending close.
The issue was discussed in a meeting on 2023-06-06
- no resolutions were taken
View the transcript
1.3. Standardize recording a pre-issuance DID Auth VP as evidence property (issue vc-data-model#896)
See github issue vc-data-model#896.
Brent Zundel: Add DIDAuth as evidence property -- is this pre/post CR?
Joe Andrieu: Unfortunately, same concerns, I think it's the right way to do things, but no one is doing it? We should ask if anyone is doing this, and mark it pending close.
Brent Zundel: ok, done, any opposition to marking as pending close? (with the additional details)?
all: No objections, marked as pending close.
