Evidence extension point (was: Improve tests for Evidence)

[OR13]

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.

[iherman]

@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:

1. Reserve the terms
2. Define abstract classes for all domain and range.
3. Specify domain and range for all predicates

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 range of a property is set, for example, to be xsd:string and, instead, the value would be an object, then the system may raise some sort of exception because the data is inconsistent. But sprinkling the vocabulary with extra statements just because we can is unnecessary.

So -1 to that.

This issue is only on the subject of evidence. My understanding of what you propose in https://github.com/w3c/vc-test-suite/issues/134 is identical to what I proposed in https://github.com/w3c/vc-test-suite/issues/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.

[TallTed]

domain/range statements are licenses to infer

Yes, that's true. There should be no problem with such inference happening if our domain/range statements are accurate.

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 range of a property is set, for example, to be xsd:string and, instead, the value would be an object, then the system may raise some sort of exception because the data is inconsistent

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 rdfs:Resource, when we know they're accurate.

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.

[OR13]

Getting into long philosophical arguments about the vocabulary overall sounds to me like an unnecessary discussion at this point.

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 Resource.

[alenhorvat]

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. Delegated Authorisation: We have a simple use case where an authority can delegate authorisations to other subjects. Some of them may have a right to delegate the same or a subset of authorisations to other subjects.

CredentialSubject defines the rights and delegation limitations. When an authorisation API receives a Verifiable Authorisation, it has to know, based on what delegation/mandate the authorisation can be issued.

We have 3 options a) put the VC with the delegation rights in the Evidence (VC will be embedded) b) share the VC with the delegation rights in a VP (but reference it in the Authorisation) c) share the VC with delegation rights in as part of the signer attributes (either in the JOSE header or in the DIP proof property; either signed or unsigned)

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?

[alenhorvat]

Or in general: Should evidence contain only subject-related credentials or could it contain also issuer-related credentials?

• based on evidence X I'm entitled to issue the VC
• based on evidence Y the credential has been issued to me

[OR13]

@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

[alenhorvat]

Use cases are:

• delegations, mandates
• accreditations
• other use cases when the credential subject claim values are constrained by the referenced credential

We started with a simple case: delegated authorisation issuer delegates authorisation rights to the holder. Issuer can delegate the same or a subset of permissions it has. To verify the delegated permissions, we need to know what permissions issuer had, hence the VC should be embedded or referenced.

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 https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf see: srAts in section 5.2.5

We're also working on a scenario that is using Terms Of Use. Is there a similar ticket for the TermsOfUse?

[alanhkarp]

(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.

[alenhorvat]

@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. Note that the VCs used for authorisation do not hold any claims and have a type "VerifiableAuthorisation". As you mention, their use and audience are very specific. We also distinguish between authorisation and delegation (and issue them as separate VCs).

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.

[TallTed]

[@alenhorvat] the VCs used for authorisation do not hold any claims and have a type "VerifiableAuthorisation".

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?

[OR13]

@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.

[longpd]

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 https://github.com/w3c/vc-test-suite/issues/134, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADYBFE6R57ZVQKJUR65IJDXZTTWXANCNFSM5OMENMUQ. You are receiving this because you were assigned.

[alanhkarp]

@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.

[alenhorvat]

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. We have a few questions/remarks. I'll open a ticket there to address them.

[alanhkarp]

Please tag me on your comments. I'd like to follow along.

[longpd]

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 :

• Keep the reserved term.

• Don't define an abstract class / domain or range.

• Encourage people to use the term however they like, as long as instances have an id and a type?

2: @iherman responded to a variant of this proposed by @OR13 which was to

Not saying anything about range or domain (or any other property of anything) in this or any ontology in this Open World of RDF means that the values of those properties must be treated as unknown.

If the values of those properties are in fact known, it behooves us to state them, not least because by leaving them unstated anyone else may assert any value(s) for them, including competing assertions of same and there is no authority to appeal to for the correct value.

3: @OR13 modified the proposal as follows

• Reserve the terms

• Define abstract classes for all domain and range.

• Specify domain and range for all predicates

4: To which @iherman replied:

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 range of a property is set, for example, to be xsd:string and, instead, the value would be an object, then the system may raise some sort of exception because the data is inconsistent. But sprinkling the vocabulary with extra statements just because we can is unnecessary.

So -1 to that.

5: @TallTed responded

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 rdfs:Resource, when we know they're accurate.

All that said, I won't lie down in the road on this.

I commented earlier that

I am not an expert in rdfs, but I’ve consulted a few recently on this question about the concern of rdfs properties and explicit or absent domain range settings. Among the things I’ve learned include advice from someone involved in Dublic Core (DCMI) who explained to me that none of the properties in that well established meta data initiative have explicit range or domain settings.

And followed up with this reference advocating the 'weak semantics' approach.

introduction to the Bulletin of the Association for Information Science and Technology, Special Section: Linked Data and the Charm of Weak Semantics (Volume41, Issue4, April/May 2015, Pages 10-12). “Linked data practice, in short, values pragmatic links alongside formal ontologies, prefers vocabularies specified with lightweight semantics for maximum reusability, defines overlapping profiles in place of monolithic data structures, sees data in terms of graphs and concepts more than formal classes, shuns over-formalized semantics, embraces flexible and iterative evolution over static standardization and accepts partial interoperability as the only realistically attainable goal in today's massively diverse web. The linked data movement has invented useful new roles for constructs and languages that are, by design, semantically weak.”

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.

• Don't define an abstract class / domain or range.
• Encourage people to use the term however they like, as long as instances have an id and a type

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

[OR13]

-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.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

#### 5.4. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870) _See github issue [vc-data-model#870](https://github.com/w3c/vc-test-suite/issues/134)._ **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. > *Dmitri Zagidulin:* that's my recollection as well. **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.

[David-Chadwick]

@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)

[longpd]

@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.

1. https://www.imsglobal.org/spec/clr/v2p0/ Specifically here - https://www.imsglobal.org/spec/clr/v2p0/#evidence There 7 companies that have committed to implement CLRv2 with this extension
2. https://1edtech.github.io/openbadges-specification/ob_v3p0.html Specifically here - https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence There are 8 companies that have committed to implement OBv3 with this extension

Both have multiple commercial implementations that support the evidence extension point.

[Sakurann]

@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.

[iherman]

The issue was discussed in a meeting on 2023-09-26

• no resolutions were taken

View the transcript

#### 2.7. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870) _See github issue [vc-data-model#870](https://github.com/w3c/vc-test-suite/issues/134)._ **Kristina Yasuda:** We don't have Orie, but let's pick this up. … The `evidence` extension point. … Orie is saying that `evidence` property is poorly defined. Similar conversation with terms of use. … Here, looking at the comments it feels like there are many more implementations of this property. … The question is, how can we better define this? **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. … We can try to tighten it up a little, but it seems it has been implemented or is in the process of being implemented with a number of different orgs/companies. … It is certainly meeting the two implementations requirement. … I think the big issue was defining the range and domain of the term. … I'll leave it at that. … It's in place and working and we should probably leave it alone. **Kristina Yasuda:** Thank you so much for summarizing the discussion in your comment. > *Kristina Yasuda:* summary of the discussion: [https://github.com/w3c/vc-test-suite/issues/134](https://github.com/w3c/vc-test-suite/issues/134). **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. … We have `CredentialEvidence` as the base class now. > *Manu Sporny:* [https://w3c.github.io/vc-data-model/#vocabularies](https://w3c.github.io/vc-data-model/#vocabularies). **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. … For a concrete example. … We can update the example using a 1EdTech spec with the OpenBadges v3 thing and point over there. … We can point at that global standards org that has adopted it with multiple implementers. … We should not get rid of the property, we have demonstrated usage by a global settings org with multiple implementers. We should just update the evidence section to use a real / concrete example. … And be done with it. … `evidence` should be off the chopping block for being deprecated, we just need a new example. **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. … If folks want to raise a separate issue on examples, that should be a separate issue, regardless of closing / not closing. **Manu Sporny:** +1 to that, Kristina. I was getting ready to raise that issue. … Sebastian, to your point, I think all examples are non-normative. … It's fine for us to point to an external document and specification in a non-normative capacity, this one is a bit different though, 1EdTech is a global standards setting org and they do education standards and they are using VCs for their standards. … We're not just pointing out to the Web, we're point to another standards setting org. … For that reason, I think it's fine for us to link that way. > *Kristina Yasuda:* this PR added an abstract class [https://github.com/w3c/vc-data-model/pull/1272](https://github.com/w3c/vc-data-model/pull/1272). **Kristina Yasuda:** We're at time. … Thank you everyone for joining. Tomorrow's WG call, let's go through the PRs, let's talk about the controller documents in DI and vc-jose-cose and if we have time, let's talk about issues. ---

[OR13]

This issue could be moved to test suites, assuming the extensions are now defined well enough to be testable.

[OR13]

the issue could also be closed, as the extensions will be removed if they are not tested (they are already marked as at risk).

[OR13]

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.