Evidence extension point (was: Improve tests for Evidence) #134
Comments
|
cc @bumblefudge |
|
Please do not remove this. There are some use cases where providing evidence of the pre-issuance DID auth is exceptionally valuable. This property is meant to be an extension point and we should keep it as such. |
|
@jandrieu can you point to examples of this extension that are being used in the wild today? I know folks have been considering it, we should gather evidence that it's being used or being considered, and if we can't we should try and remove it to simplify the spec. |
|
I can't, today, speak publicly about either of the two initiatives I know of who are expecting this capability. What I will say is that without evidence of having performed did-auth embedded in the VC itself, we have no mechanism to verify whether or not the issuer, in fact, proofed control of the DID before issuance. For those subject=holder use cases that rely on the verifier to compare the VP signer to the Subject ID to perform a second step in identity assurance, the evidence property is the only way (within the current spec) that I know of to demonstrate that the first step was completed satisfactorily. This extension point exists for a reason. Removing it just to "simplify the spec" isn't appropriate here. |
|
I think @selfissued also knows of some folks considering this feature, we should strive to get it covered in the test suite, if it really is being used. |
|
Blocked by an item in the VC extensions directory that defines evidence that we can point to and test against? |
|
Yes an example has been added to the Directory |
|
It points to the use of the OIDF Identity Assurance draft standard as an example of Evidence |
|
I suggest the following:
Similar argument would apply to the other properties that are in the core spec, but for which we have no evidence (cough)... of actual implementation or use. |
|
Example from Open Badges "evidence": [
{
"id": "https://1edtech.edu/credentials/3732/evidence/1",
"type":
"Evidence"
,
"narrative": "# Final Project Report \n This project was ...",
"name": "Final Project Report",
"description": "This is the final project report.",
"genre": "Research",
"audience": "Department"
},
{
"id": "https://github.com/somebody/project",
"type":
"Evidence"
,
"name": "Final Project Code",
"description": "This is the source code for the final project app.",
"genre": "Research",
"audience": "Department"
}
], |
|
assigning Oliver to find out what needs to be done to resolve that issue |
|
Example from OIDF eKYC and IDA Evidence {
"evidence": [{
"type": ["https://openid.bitbucket.io/ekyc/openid-connect-4-identity-assurance.html#name-verification-element"],
"verification": {
"trust_framework": "uk_tfida",
"scheme": "idconnect",
"assurance_level": "idconnect_kyc_partial",
"assurance_process": {
"policy": "GPG_45",
"scheme_policy": "idconnect_kyc",
"procedure": "L1B",
"scheme_procedure": "dlnl_sm",
"gpg45_confidence_level": "low",
"assurance_details": [{
"assurance_type": "evidence_validation",
"assurance_classification": "3",
"evidence_ref": [{
"txn": "WED-85762937582385444",
"evidence_classification": "3"
}]
},
{
"assurance_type": "address_validation",
"assurance_classification": "2",
"evidence_ref": [{
"txn": "idv-7567445464543",
"evidence_classification": "3"
}]
},
{
"assurance_type": "verification",
"assurance_classification": "3",
"evidence_ref": [{
"txn": "BIO-8576293758238555"
}]
}
]
},
"time": "2021-05-11T14:29-01:00",
"verification_process": "7675D80F-57E0-AB14-9543-26B41FC22",
"evidence": [{
"type": "document",
"check_details": [{
"check_method": "vri",
"sub_check_method": "vri",
"organization": "wedocu",
"txn": "WED-85762937582385444"
},
{
"check_method": "bvr",
"sub_check_method": "bvr",
"organization": "biotrick",
"txn": "BIO-85762937582385555"
}
],
"time": "2021-04-09T14:12Z",
"document_details": {
"type": "driving_permit",
"document_number": "MORGA753116SM9IJ35",
"date_of_issuance": "2021-01-01",
"date_of_expiry": "2030-12-31",
"attachments": [{
"desc": "image_of_document",
"content_type": "image/png",
"content": "Wkd0bWFtVnlhWFI2Wlc0Mk16VER2RFUyY0RRMWFUbDBNelJ1TlRjd31dzdaM1pTQXJaWGRsTXpNZ2RETmxDZwo="
}],
"issuer": {
"name": "DVLA",
"country_code": "GBR"
}
},
"claims": {
"given_name": "Sarah",
"family_name": "Meredyth",
"birthdate": "1976-03-11",
"place_of_birth": {
"country": "UK"
},
"address": {
"locality": "Edinburgh",
"postal_code": "EH1 9GP",
"country": "UK",
"street_address": "122 Burns Crescent"
}
}
},
{
"type": "electronic_record",
"check_details": [{
"check_method": "data",
"sub_check_method": "cra_record_primary",
"organization": "theIdP",
"txn": "idv-7567445464543"
}],
"time": "2021-04-09T14:12Z",
"record": {
"type": "cra_account",
"authoritative_source": "equiexpunion",
"authoritative_source_reference": "gg54y4y5y5433443",
"created_at": "2021-01-01",
"date_of_expiry": "2030-12-31",
"date_last_updated": "2022-01-31",
"outcome_of_check": "positive",
"source": {
"name": "idvalidation4u",
"address": {
"street_address": "300 Bath Street",
"postal_code": "G2 4LH",
"country_code": "SCO"
}
}
},
"claims": {
"given_name": "Sarah",
"family_name": "Appleby",
"birthdate": "1976-03-11",
"address": {
"locality": "Leeds",
"postal_code": "LS12 6GT",
"country": "UK",
"street_address": "45 White Rose Road"
},
"start_date": "01-01-2020",
"end_date": "31-12-2020"
}
}
]
}
}]
} |
|
Based on the 2 examples in the vc-specs dir, it seems people are using "type" in different ways... if there are 2 independent implementations of either of these, I think |
|
Related issue: w3c/vc-data-model#893 |
|
The issue was discussed in a meeting on 2023-04-04
View the transcript1.12. Improve tests for Evidence (issue vc-data-model#870)See github issue vc-data-model#870. Kristina Yasuda: By Orie, about evidence. Anyone willing to take this one?.
Ivan Herman: I don't really understand.. The title says you have to improve tests, which suggests this is about tests, not the spec. The text talks about better defining the property or removing it. What is this about? Question is to Orie.. Orie Steele: I believe we had the spectre of objections in the context of our RDF terms for which there have been no implementation. I believe "evidence" is one of them. In order to retain this in the core spec, this was the original intention of the issue. As far as I am aware, we have not provided any concrete examples of using the "evidence" property.. Ivan Herman: I understand. I suggest we postpone this to when we get to CR exit criteria. We have to say what it means for a property to pass the CR line. The issue wasn't clear from the description.. David Chadwick: Part of the NGI Atlantic project, we did a simple example which referred to NIST and eIDAS levels of assurance. There would have been two independent implementations, but the project ran out of time.. Oliver Terbu: To proceed with this issue, does somebody have to register an "evidence" type in the directory, and then write a test that uses this "evidence" type? Implementers don't need to anything, but they should not fail if they encounter an "evidence" property of this specific type, is this correct?. David Chadwick: This is a discussion we had with termsOfUse and nonTransferable, whether these properties can be ignored by recipients. I think DavidC added something to this discussion.. Oliver Terbu: Whoever gets assigned to this issue, should be someone who knows an "evidence" type that is used somewhere, and it should be registered in the VC directory. Does this make sense?. Dave Longley: Trying to respond to ignoring extension points. This was certainly the intention.. Kerri Lemoie: We have OpenBadges 2.0 use "evidence". I will share a link..
Kerri Lemoie: It's a bit confusing, because they are using the "evidence" property from the VC spec, but they are using it in their own way with their own properties. This is important for EDU community, but they have their own testing. There is overlap, not sure what to do with it. I don't know if we can test it if they already test it in their own way..
Michael Jones: It's not a question whether they can ignore "evidence". They must be able to ignore it. In our test suite we should inject random elements and ensure that implementations don't fail if they encounter them.. Kristina Yasuda: Anyone willing to be assigned to this issue?. Oliver Terbu: You can assign me to find out what actually needs to be done, if anything needs to be changed in the test suite..
|
|
@OR13 To me it is not entirely clear what this issue is about. The title of the issue seems to imply we have to update the test suite. In that case, we should move this issue to https://github.com/w3c/vc-test-suite. Would you agree? If this is not the case, then we should close this issue and create a new one that describes what you wanted to get fixed. If you want to remove For reference, the W3C test suite has one test case for evidence, which uses the following evidence object: It seems that the type
I'm supportive on using an evidence type in the W3C test suite that has been registered in the VC directory instead. Currently, there is just one which is the OIDF eKYC one which doesn't define a context/vocab which makes it hard to be included in the W3C VC test suite. |
|
There should be 2 places where tests are improved:
I'm not volunteering to do either for evidence, but if neither is done well, I will argue against continuing to keep evidence in the core spec. |
A third is that this type is not a URI. |
|
I believe this is blocked by w3c/vc-data-model#1082 since if we decide to include @OR13 let's close this issue after w3c/vc-data-model#1082 was resolved. If tests for evidence still have to be improved, please close this issue and open a new issue in the test suite repository. |
|
Could @awoie or @OR13 please state what you expect the conformance tests to test.
|
|
Ideally we could test both conformance to the data model, and business logic associated with evidence production and consumption. The latter would need to be in a different test suite from the core data model. |
|
I agree that testing business logic should not be part of the VCDM test suite. My question to you was about tests for the VCDM. |
brentzundel
changed the title
|
@TallTed I read your reply as a request to specify domain and range for all normative vocabulary items. Is there any reason why we might only domain? Second concrete proposal:
|
It is a bit more than that. If the environment makes a minimal amount of RDF(S) reasoning, then domain/range statements are licenses to infer. If the vocabulary says: and the actual data includes the statement then a reasoner can infer that the following is also true: which may be good or bad, depending on the application. |
I am afraid all this would overcomplicate the data, for no real gain. What would you want to achieve with that? We put range/domain if the aforementioned license to infer might be used to, e.g., warn us of issues in the data. If the So -1 to that. This issue is only on the subject of evidence. My understanding of what you propose in #134 is identical to what I proposed in #134. That seems to be enough of a basis for solving this issue. Getting into long philosophical arguments about the vocabulary overall sounds to me like an unnecessary discussion at this point. |
Yes, that's true. There should be no problem with such inference happening if our domain/range statements are accurate.
Such exceptions are indeed a significant reason why domain/range statements are included in vocabularies, and why I believe it's worth putting even such broad domain or range statements as All that said, I won't lie down in the road on this. I reserve the right to say "told you so" if the lack of such statements turns out to be a problem with wide deployment. |
I don't think thats what this issue is about. Its supposed to be about what a verifier knows (or learns) from processing our data model, when they see evidence. Its ok for us to say: "we don't know anything about this", if thats what the recommendation is for RDF, it weakens the value of processing the data model as something other than JSON, but I am looking for specific examples, where the verifier might be applying what they know from domain and range to do "reasoning" or otherwise benefit from the RDF. I think its a mistake to not improve on these definitions beyond |
|
Hi. It's a very long thread :) Use case that we have and I'd like to discuss with you whether or not Evidence is the right place to put the information. CredentialSubject defines the rights and delegation limitations. We have 3 options Option A seems to be the best from contextual point of view - You can use this evidence to verify that I'm entitled to issue a given statement. Is this a good place for the question? Any recommendations? |
|
Or in general:
|
|
@alenhorvat do you have an idea how we might close this issue? What language could we add to the core data model to recognize the work you cited here: https://lists.w3.org/Archives/Public/public-credentials/2023Sep/0024.html |
|
Use cases are:
We started with a simple case: delegated authorisation For JOSE-based signatures, if delegations chains are long, it is recommended to reference the VC (id+digest) and share all the VCs in the VP, else the root VC will be encoded N times, when the chain length is N. We'll add the option to reference the VCs next week. Maybe the language can follow the "signer attribute" language as introduced in JAdES We're also working on a scenario that is using Terms Of Use. Is there a similar ticket for the TermsOfUse? |
|
(A very long thread that I only read the end of, but I've participated in such discussions before.) While VCs are great for making claims, do not use them for granting permissions. There are a number of issues. Invocation: A permissions VC must designate a specific object that the invocation request applies to, and the invocation may include delegation to the invokee of permissions to parameters being passed. A claims VC typically designates some entity, e.g., the person granted a driver's license, and invocation makes no sense. Delegation: You must support attenuated delegation chains for permissions. Relatively few claims are delegatable. When they are, the mechanisms are quite different, e.g., Alice acting as manager while Bob is on vacation vs. Alice using some permissions that Bob explicitly delegated to her. Revocation: You don't know who will be verifying a claims VC, but you do know who will be verifying a permissions VC. As a result, the revocation mechanisms are completely different. As a result of these differences, there are certain fields that must appear in a claims VC that make no sense in a permissions VC, and vice versa. You are creating a lot of confusion for both creators and consumers of VCs if you overload them this way. That being said, you can reuse the VC infrastructure for both if there is a field in the VC that denotes whether the credential is for a claim, e.g., driver's license, or a permission, e.g., authorization to read some object. If you do, you'll need 2 intertwined specs given the subtleties of using certificates for authorization. Perhaps you'd be better off using something like zcap-ld for authorizations. |
|
@alanhkarp thank you for your valuable feedback. We'll check the zcap-ld terminology and probably re-use it in the next iteration. However, we'd like to re-use the existing VC infrastructure. We do need a way to link and transport parent VCs based on which the permissions/authorisation have been granted. (In one scenario we have 3-4 layers). For this case we saw the vc.evidence property as an appropriate way to reference or embed the VCs. If there's any other work we can learn from, we'd greatly appreciate the references. |
That may be true for your implementation, but so far as I'm aware, it's not (yet) part of the VC Data Model nor any documentation produced by the VCWG, and that means it may not be true for anyone else's implementation. Perhaps you could write up your use case, and some details of your implementation and deployment, toward inclusion in a future VCDM revision? |
|
@alenhorvat sorta related to the topic of using "W3C Verifiable Credentials" as "Authorization Capabilities"... https://github.com/transmute-industries/authorization-credentials I personally don't think it's "good" to split these use cases / standardize them as "separate concepts" because it introduces an artificial constraint on a use case, that impacts the cost / price of services / apis that solve for this.... However it could be very true that the W3C Verifiable Credentials WG does not have the experts needed to tackle authorization, as a concept separate from authentication, or claims an issuer makes about subjects. |
|
You beat me to it @alan - Delegating permissions is not within the scope of the evidence extension point.
… On Sep 9, 2023, at 6:21 PM, Alan Karp ***@***.***> wrote:
(A very long thread that I only read the end of, but I've participated in such discussions before.)
While VCs are great for making claims, do not use them for granting permissions. There are a number of issues.
Invocation: A permissions VC must designate a specific object that the invocation request applies to, and the invocation may include delegation to the invokee of permissions to parameters being passed. A claims VC typically designates some entity, e.g., the person granted a driver's license, and invocation makes no sense.
Delegation: You must support attenuated delegation chains for permissions. Relatively few claims are delegatable. When they are, the mechanisms are quite different, e.g., Alice acting as manager while Bob is on vacation vs. Alice using some permissions that Bob explicitly delegated to her.
Revocation: You don't know who will be verifying a claims VC, but you do know who will be verifying a permissions VC. As a result, the revocation mechanisms are completely different.
As a result of these differences, there are certain fields that must appear in a claims VC that make no sense in a permissions VC, and vice versa. You are creating a lot of confusion for both creators and consumers of VCs if you overload them this way.
That being said, you can reuse the VC infrastructure for both if there is a field in the VC that denotes whether the credential is for a claim, e.g., driver's license, or a permission, e.g., authorization to read some object. If you do, you'll need 2 intertwined specs given the subtleties of using certificates for authorization. Perhaps you'd be better off using something like zcap-ld <https://w3c-ccg.github.io/zcap-spec/> for authorizations.
—
Reply to this email directly, view it on GitHub <#134>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYBFE6R57ZVQKJUR65IJDXZTTWXANCNFSM5OMENMUQ>.
You are receiving this because you were assigned.
|
|
@alenhorvat I understand the desire to reuse the VC infrastructure for authorizations. There's a lot of work that's gone into the code for encryption and signing. Why not reuse it? One reason is that it's overloading something designed for one use for something that's quite different. I've done that many times, and I always come to regret it. Each time I promise myself not to do it again, but I always do. As I said, you can reuse all that crypto code if you include a field in the credential that clearly states if it is for a claim or a permission. You can then have a separate spec for each. Just be careful. There are a number of subtleties involving multi-argument invocations, return values, attenuated delegation, and revocation. Those are all well handled by zcap-ld. Another project you can look at is UCAN, but I don't think they are as far along in handling all those issues. |
|
Thank you for the feedback and the valuable information. We checked the zcap-ld and the design is nice, however, the specification requires some work. |
|
Please tag me on your comments. I'd like to follow along. |
|
As is evident in the length of this comments, I think we've had a robust discussion and we need to wrap this up with some concrete next steps. As I see the discussion as it's played out the key points that seem most relevant are: 1: A proposal offered by @OR13 :
2: @iherman responded to a variant of this proposed by @OR13 which was to
3: @OR13 modified the proposal as follows
4: To which @iherman replied:
5: @TallTed responded
I commented earlier that
And followed up with this reference advocating the 'weak semantics' approach.
As I noted above I do not think delegation of authority is the intention of the evidence extension point, and therefore believe it as out of scope for issue#870. I would like to have a vote on the proposal offered by @OR13 with the modification that since we have formal implementations of the use of evidence keeping is in alignment with the current support the community has shown for it. Therefore the mod to @OR13's proposal is we keep this as a reserved term given the aforementioned two implementations and the use of it in a recently awarded grant extending LinkedClaims that uses it, as well to ask simply: For the evidence extension point please vote (+1, 0, -1) for this conclusion to the issue.
A +1 or 0 leaves the evidence extension point as a reserved term and leaves domain and range undefined for the now. My vote is +1 |
|
-1. I believe we should be consistent and define abstract classes for all extensions points, and comment on them in both the main spec and the vocab. We seem to be taking that path for other reserved terms which are marked at risk, evidence should not be treated differently. |
|
The issue was discussed in a meeting on 2023-09-14
View the transcript5.4. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870)See github issue vc-data-model#870. Brent Zundel: Everyone please read this issue. Dmitri Zagidulin: The issue of stating domain and range for all vocabulary items is not relevant to this GitHub issue, in my opinion.
Brent Zundel: I recollect that we would keep it as a reserved term even if the specification text is dropped. Ivan Herman: I recollect us deciding that the corresponding item in the vocabulary would not have an explicit domain. It's very easy to implement, but it is a recursing point of disagreement. David Chadwick: I think that if there are two interoperable implementations for it, it should stay. Manu Sporny: I think we could just close this issue, because we have a default situation: if there is no normative document, we'll reserve the property and drop the text. |
|
@OR13 And I thought that an additional requirement for the VCDM v2 was two independent interoperable implementations of at least one instance of the extension point. (Because all v1 implementations can conform to supporting all extension points by ignoring them, which we said was not good enough for v2) |
We have at least two implementations of implementations that use evidence.
Both have multiple commercial implementations that support the evidence extension point. |
|
@OR13 abstract class for evidence property has been added in PR w3c/vc-data-model#1272: https://github.com/w3c/vc-data-model/blame/main/index.html#L6091 anything else concrete that you would like to see for this property to be better defined? if not, closing in a week. |
|
The issue was discussed in a meeting on 2023-09-26
View the transcript2.7. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870)See github issue vc-data-model#870. Kristina Yasuda: We don't have Orie, but let's pick this up. Phillip Long: There are anywhere from 8... depending on which spec you look at, there are maybe 15 different companies implementing with Evidence as currently defined. Kristina Yasuda: Thank you so much for summarizing the discussion in your comment.
Kristina Yasuda: So the question is whether we need an abstract class or not. Manu Sporny: Yes, I think we now ... because of that other merged PR, we have an abstract class.
Kristina Yasuda: That addresses Orie's point, right? Manu Sporny: Correct. We should probably mark this as pending close with a new issue that says -- refer to the OpenBadges v3 spec. Kristina Yasuda: Thank you for the proposal. Sebastian Crane: I'm not sure if we have an example anywhere else that refers to a separate real life example to a non-W3C spec. This is a use case. We are ... would be adding an example that references a real life use case. I'm not sure we want to go down that path without looking at competition implications. Kristina Yasuda: For the sake of this issue, my proposal would be to mark it pending close ... point to the fact that the abstract class that Orie asked for has been added. Manu Sporny: +1 to that, Kristina. I was getting ready to raise that issue.
Kristina Yasuda: We're at time. |
|
This issue could be moved to test suites, assuming the extensions are now defined well enough to be testable. |
|
the issue could also be closed, as the extensions will be removed if they are not tested (they are already marked as at risk). |
|
An abstract class won't help with interop, ideally we handle this issue the same way we are handling terms of use, and we add tests that cover specific types of evidence, and remove the at risk label, after interop on the feature is confirmed. |
See https://www.w3.org/TR/vc-data-model/#evidence
DocumentVerification2018...this tremendously poorly defined and should be defined for all serializations or removed.
Ideally we would have a test suite that shows how this property supports interoperability, and that suite would cover popular feature such as identity assurance in sufficient detail.
The text was updated successfully, but these errors were encountered: