Avoiding confusion by renaming 'credentialSubject'

RieksJ commented 5 years ago

In section 4.4, the term 'credentialSubject' is defined, suggesting a relation between the credential in which it is included and a 'Subject', i.e. an entity about which claims are made. However, the credentialSubject section contains a list of claims, rather than a (or more) subject(s).

This issue calls for renaming 'credentialSubject', and provides the following suggestions

'credentialSubjectProperties'
'claims'

brentzundel commented 5 years ago

+1 to claims

awoie commented 5 years ago

+1 to claims

ken-ebert commented 5 years ago

+1 to claims

jandrieu commented 5 years ago

+1 to claims

David-Chadwick commented 5 years ago

We have been round this one many times, and the reason it was changed from claims is that the ID is not the iD of the claim, but the ID of the subject. So the object needs to have subject somewhere in its name.

brentzundel commented 5 years ago

@David-Chadwick, I agree that it makes sense to those of in the group to call it the credentialSubject for the reasons you mentioned. This doesn't change the fact that it is confusing for others. We say that a verifiable credential contains claims, then show a data model that (for valid, yet pedantic reasons) has a credentialSubject property. We then have to explain that that's where claims should go, and then explain why the property is not just called "claims," since that is what a verifiable credential supposedly contains.

Rather than requiring this educational moment every time someone new looks at the data model, I support the proposal to change credentialSubject back to claims.

jandrieu commented 5 years ago

I think there was also confusion about the embedded graph container, making the RDF subject of the claims confusing. We have examples in the focal use cases where there are multiple subjects, for example in a birth certificate and marriage certificate.

"CredentialSubject" strongly suggests that there is always single subject of the credential, but that's demonstrably untrue.

@dlongley could you provide an example of how an issuer would construct a VC with multiple subjects?

I scanned the current spec, but only found examples such as the following:

...
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    }
...

Am I correct that simply replacing that single object with an array works?

  "credentialSubject": [{
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    },{
    "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
    "parent": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "type": "Mother"
    }]

If that's correct, I believe @David-Chadwick's issue isn't with CredentialSubject but with the id.

The example says, in effect, that the subject of the first claim is the mother of the subject of the second claim.

In this case, I think the best we can do is explain clearly that "id" is the "id" of the subject of just the each claim. That's something we need to clarify, but my understanding is that the way JSON-LD works the "id" field is necessary. Or is it possible to change the "id" field to "claimSubject"? That's the semantic meaning in this situation. Can we make it explicit?

In any case, when you see the multi-subject "CredentialSubject", it doesn't make sense.

David-Chadwick commented 5 years ago

The way out of this dilemma is to have a claims object that contains within it one or more credentialSubject objects. Then it is clear that the VC contains claims, and that the ID is that of the subject. Eg.

"claims": [
 "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
    },
"credentialSubject": {
    "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
    "parent": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "type": "Mother"
    }
]
...

jandrieu commented 5 years ago

That's not bad, except I believe the "credentialSubject" is actually a "claimSubject" in your example.

talltree commented 5 years ago

I like it too. And with that context, wouldn't just "Subject" work as the name?

On Wed, Apr 3, 2019 at 7:17 AM Joe Andrieu notifications@github.com wrote:

That's not bad, except I believe the "credentialSubject" is actually a "claimSubject" in your example.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/480#issuecomment-479509031, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTbh3PPL8HF2VN9ODFBEYubXA5nBwks5vdLgBgaJpZM4cNFRu .

jandrieu commented 5 years ago

Maybe. I think folks get wrapped around the singular subject, thinking a credential can only have one subject. ClaimSubject focuses it nicely on this particular claim, gently inviting credentials that have claims about many subjects.

msporny commented 5 years ago

I will note that the conversation in this issue is all over the place and is pretty classic bike shedding during the Candidate Recommendation phase (typically, a terrible, horrible time to bike shed core properties in the specification since implementers are already busy implementing using the properties that are currently being bikeshedded in this issue).

-1 to anything plural (claims, subjects, properties, etc.). schema.org made that mistake years ago and has been busy playing whack-a-mole to remove all the plural properties. The same goes for the Web Payments specification. We have over a decade of experience now naming properties that will go back-and-forth between JSON and RDF and the best practice is to NOT use plural form.

-1 to claim (and I say this as the person that initially put that in the specification). You are expressing "one or more credential subjects". The language in the spec may lead people to a different conclusion, and if it does, we should fix that specification text (not change the property to something that it's not).

I also note that the WG has many more things to worry about at present than bike shedding a name. Can we please just drop this issue and focus on things that are a better use of the WGs time? I'm concerned that this issue is going to consume a lot of time that should be spent doing things like getting the VC extension registry up and running, working on use case finalization, etc.

@RieksJ -- perhaps there is some non-normative text that you would like added to the specification to explain why the "credentialSubject" property is named what it is named?

RieksJ commented 5 years ago

I appreciate that there is a lot to do. However, I don't consider heavy workloads as a valid argument for deciding to skip issues in a standardization process. I would support it as an argument to postpone the transition to a next phase, because standards should be solid. And in particular, discussions about what might seem to be details should be done carefully, because that's where the devils tend to be, and in my experience as expert in ISO SC27/JTC1, fixing standards is much harder once they're out there.

Note that this is not an argument to discuss every detail - relevance of the discussion must be shown first. The relevance of this issue is to prevent confusion and misinterpretation by readers (standards should be unambigous and clear). The term 'credentialSubject' suggests that there is a relation between the credential and a single subject (which isn't there). But even if we say that this standard uses singulars, then 'credentialSubject' still has the word 'Subject', and that doesn't cover its payload (which is a set of Claims). It is like having a sign on the door of a restroom that says 'Chair'.

To me, it is relevant that standards do not have these kinds of things in them. But if there is a consensus that preventing such confusion is irrelevant, then I have no problems with closing this issue, because that's how standardization works.

@msporny: I don't think it is up to me to elaborate on why 'credentialSubject' is named as it is, because I did not invent that name (and I wouldn't have named it that in the first place for the same reasons I created this issue).

dlongley commented 5 years ago

@RieksJ,

Using a relationship named credentialSubject makes sense in the data model, particularly if you think of the data as a graph, which is what we're modeling.

A credential is a node in this graph. If you want to represent something about this node, you create a link emanating out from the credential node that connects to another node in the graph. For example, if you want to identify the issuer of the credential, you can create a link named issuer and use it to connect the credential node to another node that represents the issuer. If you want to say that a credential is about a subject, you can link the credential node with a link called credentialSubject that connects to the subject node. If you want to say that the credential is about yet another subject, you create yet another link called credentialSubject and connect that to that other subject.

You can see from this why using plural names for links doesn't make much sense. The links identify the relationship between two nodes in a graph; if you want to say one node has the same kind of relationship with two other nodes, you add two links of the same name to the graph, each connecting to one of the other nodes.

Now, if you want to say things about any one of those subjects, you repeat this process -- you link the subject node you want to say something about to another node through another relationship. For example, you could create a link called alumniOf that connects the subject node to a node that represents a literal string value of Example University.

In the JSON and JSON-LD syntax, links are represented as JSON keys, where the JSON key id is a special key that is used as an identifier for a node. Nodes are represented as JSON objects or, if a node represents a literal value, it can be a string, number, boolean, etc. Other syntaxes may do something different while still being compliant with the data model.

At a high level, the entire graph is therefore comprised of sentences that include a "subject" (a node), a "property" (a link), and an "object" (another node/literal value). These sentences are the "claims" -- and in our model they are understood to have been made by the entity identified as the "issuer".

We have a picture of a graph showing how this works in the data model:

Credential Graph

RieksJ commented 5 years ago

Section 4.4 Credential Subject says "This specification defines a credentialSubject property for the expression of claims about one or more subjects". Since JSON-LD does not allow duplicate keys, then what does a credential look like (in JSON-LD) that has claims (or better: JSON-LD graphs) about two different subjects? And might the figure need clarification so that it better shows how multiple claims on different subjects are done?

dlongley commented 5 years ago

@RieksJ,

Since JSON-LD does not allow duplicate keys, then what does a credential look like (in JSON-LD) that has claims (or better: JSON-LD graphs) about two different subjects?

Instead of using a single object for the value of credentialSubject an array of objects is used:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "credentialSubject": [{
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe"
  }, {
    "id": "did:example:3d5c623bf63156cb1",
    "name": "John Doe"
  }],
  "proof": { ... }
}

And might the figure need clarification so that it better shows how multiple claims on different subjects are done?

+1. If you could propose some concrete text that helps clarify things for you we'll be able to pull it in much more quickly. And if you or someone else has the time to add another picture showing multiple credentialSubject links that would also be great.

RieksJ commented 5 years ago

W.r.t. the figure: I've tried to do some quick stuff with svg, but I've trouble getting it done. I propose the following changes (decreasing importance):

draw a box around the yellow boxes; this box is similar to that of 'credential graph' and 'proof graph' and could be named 'claims'.
draw this box several times at a slightly different place, thus suggesting that multiple such claims can be referended
add some more yellow boxes such that it becomes clear that there is a linked data graph here.

W.r.t. texts: the comments above by various people indicate that the texts that describe what a credential, a subject, a claim, etc. is, is far from clear, even for people that are consistent contributers to the text. While the issue I raised was just a part of this discussion, it seems to me that a decision is called for to determine whether to revise the text so as to address these issues, or leave it as it is. While it is my preference to do the first, I don't make these decisions.

burnburn commented 5 years ago

Decision on VCWG call 7 May 2019: RESOLUTION: The Working Group has discussed issue #480 and is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase. The Working Group is interested in exploring non-normative resolutions to the issue. The WG would like to defer the issue so it can be considered when work continues beyond VC 1.0.

kdenhartog commented 3 years ago

We discussed this on the maintainence working group call and believe that this PR can be closed due to the impact on the number of implementations already done today. If the author believes this should still be addressed it can be handled in V2 and they can reopen it.

iherman commented 3 years ago

The issue was discussed in a meeting on 2021-08-11

no resolutions were taken

View the transcript

#### 4.6. Avoiding confusion by renaming 'credentialSubject' (issue vc-data-model#480) _See github issue [#480](https://github.com/w3c/vc-data-model/issues/480)._ **Wayne Chang:** this would add a huge breaking change, renaming a major component > *Manu Sporny:* +1 this would be a huge breaking change. > *Dave Longley:* +1 to close > *Manu Sporny:* +1 to closing **Wayne Chang:** probably good to close, but we'd need to see broad support for changes like this in the new working group to re-open

RieksJ commented 3 years ago

I am disappointed by the way this issue has been treated and has come to a close, as it might have been properly dealt with around the time it was raised. Instead, it has been lying around for over two years, thereby implicitly instructing all implementations to follow the contested practice. Allowing this issue to remain unaddressed caused it to become a 'huge breaking change', and continues to do so up to at least v2. It is like instructing people to litter a place and then refuse to participate in cleaning it up, suggesting that you can have another shot at it when you build a new place (v2). I consider this a bad practice for a standardization group.

msporny commented 3 years ago

I am disappointed by the way this issue has been treated and has come to a close, as it might have been properly dealt with around the time it was raised.

@RieksJ, while I can understand your frustration, the reality is that the group did discuss the issue at depth: namely, in issue https://github.com/w3c/vc-data-model/issues/207

Then, when you raised this issue (during the Candidate Recommendation phase), the group did debate it again and came to the conclusion that it did not want to make the change you were suggesting: https://github.com/w3c/vc-data-model/issues/480#issuecomment-490116412

Since then, there has been hardly any discussion on the issue, which signals to the group that it has not been a concern for people building solutions using Verifiable Credentials.

While you are free to be disappointed with the outcome, the concepts that you raised in the issue did get very broad discussion in the group and the group did come to consensus on the path forward.

Fundamentally, the flaw with the argument in this issue is this: "the credentialSubject section contains a list of claims, rather than a (or more) subject(s)."

The credentialSubject section does, in fact, provide an associated list of credential subjects (that's why the name was picked), identified explicitly by credentialSubject.id or implicitly by an auto-generated identifier (blank node identifier). This is why the credentialSubject property was where the group ended up. We then hang claims off of each credential subject identifier. I personally would've preferred something else, but that's neither here nor there... credentialSubject is what achieved group consensus.

mwherman2000 commented 3 years ago

RE: ...or implicitly by an auto-generated identifier (blank node identifier).

@msporny Where is this implied or, better, stated?

mwherman2000 commented 3 years ago

@rieksj @mspony A major part of the root cause of this issue appears earlier in the specification with a series of statements about Claims that are, generally and fundamentally, not true.

See https://github.com/w3c/vc-data-model/issues/790

msporny commented 3 years ago

RE: ...or implicitly by an auto-generated identifier (blank node identifier). @msporny Where is this implied or, better, stated?

https://www.w3.org/TR/json-ld11/#node-identifiers https://www.w3.org/TR/json-ld11/#identifying-blank-nodes https://www.w3.org/TR/json-ld11-api/#node-map-generation https://www.w3.org/TR/json-ld11-api/#generate-blank-node-identifier

msporny commented 3 years ago

A major part of the root cause of this issue appears earlier in the specification with a series of statements about Claims that are, generally and fundamentally, not true.

There is a flaw in that assumption that I've documented here: https://github.com/w3c/vc-data-model/issues/790#issuecomment-897710929

mwherman2000 commented 3 years ago

RE: ...or implicitly by an auto-generated identifier (blank node identifier). @msporny Where is this implied or, better, stated?

https://www.w3.org/TR/json-ld11/#node-identifiers https://www.w3.org/TR/json-ld11/#identifying-blank-nodes https://www.w3.org/TR/json-ld11-api/#node-map-generation https://www.w3.org/TR/json-ld11-api/#generate-blank-node-identifier

Thank you @msporny for the interesting links about the mechanics of JSON-LD.

Where in the VC Data Model specification is the connection made between credentialSubject id being optional and, say, for example, https://www.w3.org/TR/json-ld11/#identifying-blank-nodes? Where in the VC data model specification does it say how a non-existent elements like credentialSubject id is first detected and then subsequently identified as a blank node, etc. etc.

RieksJ commented 3 years ago

@msporny the issue wasn't dealt with in #207. Rather, the resolution of #207 caused the issue to be raised, and subsequent comments suggest there is/was support for it to be actually resolved. While the decision to defer the resolution of the issue appears to have been discussed, there is no mention of the motivation, which I can live with but reflects a way of doing things that in my opinion could be improved. The subsequent decision to close the issue is a 'maintenance decision' rather than a reflection on the actual content. While this might be appropriate for a repo of software code, but I consider it inappropriate for a repo of standardization issues.

brentzundel commented 3 years ago

As there is opposition to closing this issue, I will re-open it. As a resolution to this issue lies beyond the scope of the current working group, I am going to label it defer-v2

mwherman2000 commented 3 years ago

@mspony Where in the VC data model specification does it say how a non-existent elements like credentialSubject id is first detected and then subsequently identified as a blank node, etc. etc. [I don't believe past issues are an official part of the specification. The specification needs to stand on its own, doesn't it?

Also where in the VC data model specification tied to JSON-LD and where/how is an intelligent reader supposed to deduce this? Most people will not even get to section 6: https://www.w3.org/TR/vc-data-model/#json-ld

JSON-LD, if applicable, needs to be introduced at the beginning of the specification and incorporated into the explanations of what a Claim is and what a Credential is because JSON-LD introduces requirements are unnatural and will be unexpected for most intelligent readers. The linkages need to be made clear.

msporny commented 3 years ago

@mwherman2000 wrote:

Where in the VC Data Model specification is the connection made between credentialSubject id being optional and, say, for example, https://www.w3.org/TR/json-ld11/#identifying-blank-nodes? Where in the VC data model specification does it say how a non-existent elements like credentialSubject id is first detected and then subsequently identified as a blank node, etc. etc.

The specification doesn't state that explicitly because there was a contingent of people both inside and outside of the WG that didn't want that sort of binding to be made to between the VC spec and JSON-LD (this was the JSON-only contingent). So, we were not able to get to making any statements of the sort in the specification that would have reached consensus. From what I remember, we didn't try elaborating on that fact in https://www.w3.org/TR/vc-data-model/#syntactic-sugar, which we probably could do without a big scuffle in the group... it would be a non-normative statement because it's just stating a fact of JSON-LD. However, there would be no such assertion for JSON, because JSON doesn't have the concept of graph/nodes/node identifiers, etc. So, it would still remain woefully underspecified for the JSON expression.

JSON-LD, if applicable, needs to be introduced at the beginning of the specification and incorporated into the explanations of what a Claim is and what a Credential is because JSON-LD introduces requirements are unnatural and will be unexpected for most intelligent readers.

The initial specification did this... and after multiple objections, we had to remove that language from the specification and enable a JSON-only mode as well (which didn't answer many of the important points you're raising). That is, we did not have consensus at the time to do what you are suggesting... quite the opposite, there was a consistent opposition to doing what you're suggesting (which I personally support) until we removed that from the specification.

mwherman2000 commented 3 years ago

So the JSON-LD links provided above aren't directly relevant to the question I first asked:

RE: ...or implicitly by an auto-generated identifier (blank node identifier). @msporny Where is this implied or, better, stated?

The implication is so indirect and vague that it is, in effect, non-existent.

msporny commented 3 years ago

@RieksJ wrote:

The argument in the 'maintenance decision' to close the issue might be appropriate for a repo of software code, but I consider it inappropriate for a repo of standardization issues.

You can always object to the issue being closed and request that it be re-opened. My expectation is that will trigger the group to formally close the issue (which you probably don't want at this time). The maintenance WG is a smaller group and will come to a decision much more swiftly than a larger group. If you truly want this to be debated more than it already has, I'd defer to v2... but then, that creates time for credentialSubject to further ossify.

I expect this ship has sailed (for all the reasons outlined above), but if you want to insist that the group discusses this, v2 is probably your best bet. If we do it between now and the end of the year, there is a high likelihood that it'll be closed with an explicit resolution (or deferred to be picked up in v2).

In any case, requesting that it be re-opened is your right... you will want to do so with either 1) a statement of new information that should be considered, or 2) a statement that the group did not appropriately contemplate your issue before closing it, or 3) you are asserting a W3C Process violation (please don't do this one, because AFAICT, there was no process violation).

msporny commented 3 years ago

The implication is so indirect and vague that it is, in effect, non-existent.

I don't disagree with you. Hopefully you understand that many wanted a more direct linkage, but it met opposition in the group and we were unable to get to consensus to do what you (and I) wanted. I have suggested one path that might work, maybe... other suggestions (that have a high likelihood of achieving consensus) on what to do are welcome.

RieksJ commented 3 years ago

@msporny: as I said in my comment right after closing the issue, my disappointment comes from the way in which the decision was made, specifically because we're dealing with a standard here. I commented earlier that I find arguments that do not address the issue itself to be invalid for standardization (examples of which are a heavy workload, characterizing the issue so as to make it seem inappropriate to deal with (e.g. calling it bike shedding, etc.).

It was obvious that the issue needed more discussion and a better understanding. That's what happens in standardization, and deferring a resolution to V2, as it is currently marked for, is also ok. I sincerely hope that this standardization process will value the creation of a common understanding of issues, possible resolutions and arguments for (not) wanting them and only then deciding what it will be, of more value than an an approach that allows issues to be closed (not: resolved) because of operational arguments.

While the latter is ok for software (of which the scope is limited to that software), it is not for standardization. And precisely because changes in a standard may have far reaching effects, it SHOULD be imperative that issues are properly addressed, documented and resolved, allowing users of such a standard to be prepared for changes at places where there are issues (which they SHOULD be prepared for).

I think I've made my point (perhaps even stronger than I originally set out to do), and will leave it at that.

msporny commented 3 years ago

I find arguments that do not address the issue itself to be invalid for standardization

Let me try and be a bit more blunt, because it seems that the point about the issue being addressed was missed. The issues states the following:

the credentialSubject section contains a list of claims, rather than a (or more) subject(s).

That is false. The issue starts off by making a false assumption.

The credentialSubject is an association of the Verifiable Credential with a subject. The credentialSubject section contains a list of credential subjects. Those credential subjects are then associated with claims about the credential subject.

Using either credentialSubjectProperties or claims would create confusion and be misleading. That is where the consensus of the group was, and perhaps we should have said that more explicitly in this issue rather than stating that the group didn't want to make a breaking change in CR.

I hope this helps convey the argument that underpins the rejection of your proposed alternatives. I don't expect any aspect of that argument to change in v2... but you never know, WGs change and can vary in opinion from one iteration to the next.

mwherman2000 commented 3 years ago

The credentialSubject is an association of the Verifiable Credential with a subject. The credentialSubject section contains a list of credential subjects. Those credential subjects are then associated with claims about the credential subject.

@msporny Manu, there's a lot of folklore/tribal knowledge that IMO are being surfaced inappropriately in these discussions as factual evidence - that might not or are not necessarily locatable in the VC data model specification.

When you make an assertion like that above, can you include a specific reference/link into the VC data model specification document to support the assertion. For example, the previous assertions about the spec. and its relationships with the JSON-LD specifications you referenced was not supported in the specification text.

Back to...

The credentialSubject is an association of the Verifiable Credential with a subject. The credentialSubject section contains a list of credential subjects. Those credential subjects are then associated with claims about the credential subject.

Wrt to this assertion, the text in the specification that might back up your assertion is vague/unclear ...especially when you include the fact the the id element can be completely omitted from the credentialSubject element: (reference: https://www.w3.org/TR/vc-data-model/#credential-subject)

credentialSubject The value of the credentialSubject property is defined as a set of objects that contain one or more properties that are each related to a subject of the verifiable credential. Each object MAY contain an id, as described in Section § 4.2 Identifiers.

The above statements, for example, do not support your assertion (based on the above statements as worded in the specification).

RieksJ commented 3 years ago

@msporny I get your point. I do. No need to get blunt.

The point that I tried to make immediately after the earlier (and reverted) closure of this issue is not related to the content of the issue, but to the process of dealing with the issue.

The resolution of this issue in VCWG call of 7 May 2019 states that the Working Group is not willing to make a substantive change to the specification that would trigger another Candidate Recommendation phase, and decides to defer the issue. I can see the logic of that given the amount of discussion, and I accept that the (the content of) the issue itself will be addressed later.

However, the @kdenhartog's comment says "We discussed this on the maintainence working group call and believe that this PR can be closed due to the impact on the number of implementations already done today", on which @iherman commented that no resolutions were taken.

As a person that is (still) motivated to contribute (albeit that I can only do so through issues), I conclude from the above that

the maintainence working group is not (always) clear about which decisions it actually makes;
it is acceptable for this working group / standardization effort to close an issue
- regardless of whether there is a proper documentation of the conclusion (if not consensus) about how to deal with the issue as it was raised (not: as what it has turned into in the course of time);
- on the basis of a hallucination about the outcome of a proper treatment of the issue, and the impact on the number of implementations that this outcome might have.

The point I try to make here is that I would like to see this way of working improved, not only because I strongly believe in the creation and maintenance of high quality standards, but also to prevent my motivation for contributing to vanish. Suggestions for improvements include:

when making any decision regarding some issue, document that in the issue (e.g. refer to the meeting minutes, provide the argument/conclusion of the discussion);
when closing some issue, make sure that the argument(s) for doing so actually contribute to (the quality of) the standard.
realize that standardization is a time consuming process. We are with many, we want consensus (this takes time), and several people have more important things to do (so they need time as well if they want to contribute)
...

mwherman2000 commented 3 years ago

@RieksJ let me amplify 2 concepts from your post: standardization effort and hallucination ...

It is a hallucination that the effort to produce the VC Data Model Specification document is an effort to produce a standards document.

This is the light that was turned on for me last night by @brentzundel, @msporny, and others. There is a miles wide difference between a standards document and a W3C consensus-based data model specification for verifiable credentials. With this characterization, I can appreciate and accept the document in its current form (i.e. the current version 1 W3C consensus-based data model specification). I (and I believe others) should not accept the current document as representing any form of standard.

I've proposed the following new document title to reflect this clarification: https://github.com/w3c/vc-data-model/issues/791 : W3C Consensus-based Data Model Specification for Verifiable Credentials

The former takes on the air of being a Standards document - but the current version 1 document does not reach that bar. The version 1 document lacks cohesiveness, connectedness and reliability - which makes it unattractive and unacceptable as a "standards" document.

p.s. Sounds like the W3C community consensus process is very similar to the process the US Congress uses: https://en.wikipedia.org/wiki/Pork_barrel (not sure what made me think of this but the metaphor seems accurate):

The term pork barrel politics usually refers to spending which is intended to benefit constituents of a politician in return for their political support, either in the form of campaign contributions or votes.

msporny commented 3 years ago

I (and I believe others) should not accept the current document as representing any form of standard.

What standards do you believe should be accepted? What standards process do you find acceptable? Can you provide concrete examples?

msporny commented 3 years ago

@RieksJ wrote:

when making any decision regarding some issue, document that in the issue (e.g. refer to the meeting minutes, provide the argument/conclusion of the discussion);

We did this here: https://github.com/w3c/vc-data-model/issues/480#issuecomment-897342950

when closing some issue, make sure that the argument(s) for doing so actually contribute to (the quality of) the standard.

It is believed that this was done here: https://github.com/w3c/vc-data-model/issues/480#issuecomment-897342950. By changing the name at this point, it would be a big breaking change w/o any upside. In addition, I further explained why it contributes to the quality of the standard here: https://github.com/w3c/vc-data-model/issues/480#issuecomment-898503183

realize that standardization is a time consuming process. We are with many, we want consensus (this takes time), and several people have more important things to do (so they need time as well if they want to contribute)

I believe this is broadly understood in the WG. There are a fair number in the group that have decades of experience in the space, have participated in many standardization activities, and understand this. It is also repeated to the new members in the group about how much time it takes to get through the process.

So, I believe the WG is already operating with your suggestions as a standard practice. That is not to say that we can't improve, of course that's possible and the WG strives to do that. However, in order to do that, you need to give us suggestions that are outside of our standard practice.

If I can try and summarize what I think the real issue is: It seems like you think your issue was deferred due to esoteric W3C Process ("We're in Candidate Recommendation, we can't make that change now... let's defer the issue so that we'll never be able to make the change.")... and I can understand why, based on earlier communication, that you're coming away with that impression. IMHO, the reality is that it was a misguided idea from the beginning and rather than tell you that directly, the WG attempted to soften the blow by using process rationale rather than saying "That's a misguided idea." That's the mistake that I think the WG made.

The issue is re-opened, the WG will discuss it, I expect it to come back with a stronger position and a concrete resolution this time based on the conversation happening in this issue.

@RieksJ, I hope that helps in some way.

msporny commented 3 years ago

@mwherman2000 wrote:

The term pork barrel politics usually refers to spending which is intended to benefit constituents of a politician in return for their political support, either in the form of campaign contributions or votes.

Please refrain from casting these sorts of aspersions on the group. Everyone that I know of in the group is acting in good faith, engaging publicly and transparently, the debates use logic and sound rationale, decisions are made by consensus as defined here: https://www.w3.org/2020/Process-20200915/#Consensus .

In other words, it's different in significant ways from pork barrel politics... and that you continue to repeatedly cast these aspersions on the group is most likely harming some of the good input that you do have.

mwherman2000 commented 3 years ago

What standards do you believe should be accepted? What standards process do you find acceptable? Can you provide concrete examples?

IMO, this is a redherring/diversionary question. The issues are with the current version of the spec by itself.

@msporny you yourself have described a number of places in the current specification that don't hang together, are not well connected ....that the specification lacks cohesion: the conceptual model diagrams, the fact that credentialSubject id doesn't have to be present, the fact that JSON-LD is thrown into the specification but not integrated throughout.

The current specification, based on my reading of your previous comments and the specification itself, IMO sounds, looks, and reads like a #porkbarrel ...a #bunchofstuff.

mwherman2000 commented 3 years ago

By changing the name at this point, it would be a big breaking change w/o any upside.

Please cease to use this as an excuse @msporny. It is/was a draft specification. If some early adopters/innovators/first movers (reference: model 1 in https://hyperonomy.com/2019/10/16/technology-adoption-models/) chose to bet their resources/energies/companies on a draft specification, this should not ever impact that is considered a needed change.

Also, by making this types of assertions, it amounts to #cliquespeak ...you're trying to stymie a conversation for what I consider is an unjustifiable reason.

Similarly the following comment in https://github.com/w3c/vc-data-model/issues/790#issuecomment-897745086 amounts to #cliquespeak but putting down the chances of new input being accepted before it's fully presented. You're in effect signaling to the community to disregard the suggestions before they's presented. @msporny please stop engaging in #cliquespeak (reference: https://hyperonomy.com/2019/04/09/clique-speak/)

Remember that you have at least 60+ people (number of people/implementers in the WG) you're going to need to convince on that new direction. More power to you if you figure out something simpler that achieves consensus.

mwherman2000 commented 3 years ago

Please refrain from casting these sorts of aspersions on the group. Everyone that I know of in the group is acting in good faith, engaging publicly and transparently, the debates use logic and sound rationale, decisions are made by consensus as defined here: https://www.w3.org/2020/Process-20200915/#Consensus . In other words, it's different in significant ways from pork barrel politics... and that you continue to repeatedly cast these aspersions on the group is most likely harming some of the good input that you do have.

Your comment IMO is another diversion.

The US Congress works in the same ways with people with the same good intentions. What I am specifically referring to is what the end work product looks like (a bill in the Senate, the VC 1.0 specification in the immediate context).

mwherman2000 commented 3 years ago

Going farming: https://www.youtube.com/watch?v=NfP0cOaYg0U

andrewhughes3000 commented 3 years ago

I'd like to know of specification development groups who are not in "cliquespeak" mode and that have produced exemplary standards documents. I would like to learn from them - because it's not easy to establish such an environment and I'd like to take those lessons into other fora.

On Sat, Aug 14, 2021 at 6:36 AM Manu Sporny @.***> wrote:

I (and I believe others) should not accept the current document as representing any form of standard.

What standards do you believe should be accepted? Can you provide concrete examples?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/480#issuecomment-898895514, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETAZ7BDNGNKN6QOHOEH6GTT4ZWNTANCNFSM4HBUKRXA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Andrew Hughes CISM CISSP In Turn Information Management Consulting o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave,, Victoria, BC V8Y 1W9 @.*** https://www.linkedin.com/in/andrew-hughes-682058a Digital Identity | International Standards | Information Security

dlongley commented 3 years ago

At certain point in the standardization process a spec must be considered "normatively complete" or else it will never finish (never become a standard). This is really just axiomatic. The standards process in that way is not unlike any other consensus algorithm; you have to accept that new input will eventually be refused in order to produce a stable output.

Understandably, this is a difficult period during the process as there's always something new or different that someone would like to tweak. This is one reason why the deadline by which this restriction gets triggered is largely independently set to some number of years/months from the start date of a WG. There is also always some other person who exists on the planet and who is not yet part of the WG who could potentially show up around this deadline with new input. That doesn't mean that their input is not valuable or that a clique has been formed specifically to exclude them on the basis that they are not part of the "in crowd".

A number of people that have gone through the standardization process before may try to apply their experience, through language, to help ensure that participant input is maximized in a way that will reach consensus by the deadline. The goal is not to exclude anyone, rather, it is to ensure that the deadline is met whilst maximizing input. That maximum implies a ceiling; it necessarily means some input will not make it. That's just how time works. This is an alternative explanation for the motives of people who have been described as engaging in "#cliquespeak".

Whether or not we accept the reality that the work must end at some point -- and that we get whatever the WG has been able to reach consensus on in that period of time -- doesn't change the fact that it is a reality of any terminating process.

What I think one should want from a WG is output that both instructs implementers on how to build interoperable solutions for the use cases the WG was chartered to solve -- and evidence that at least two independent implementers were able to follow those instructions to produce said solutions. Often, the easier it is to follow those instructions, the better, but we should keep in mind that ultimately the priority of constituencies is end users first, then implementers, then spec authors. And, with end users being the most important here, it is better to ship something that starts solving their use cases in an interoperable way (giving them choice), than to stall indefinitely. Specs also need to reflect reality, and by that I mean that if there are no implementers willing to implement a particular feature or unwilling to implement it in a particular way, then it doesn't matter how beautiful the spec is -- the use case doesn't get solved.

No spec built on consensus will ever look exactly the way any particular person wants it to look, because no one controls anyone else. Accepting other people's input and allowing it to color the output is the definition of consensus -- and the very opposite of creating a "clique" whereby everything goes exactly according to the group's shared desires. One should expect that a specification that was built by consensus (as opposed to being built by a clique) will show some of those signs.

Marshaling all of these concerns to produce a standard is hard. I'm very appreciative of the work that was done by the editors and chairs in the VCWG to make it happen.

RieksJ commented 3 years ago

@msporny I guess the TL;DR of what I am asking is that when a decision is being made about the resolution of an issue,

be unambiguously clear that this is the case and also what the final argument(s)/motivation are for that.
record both the decision and (a reference to) the argument/motivation in a single comment to that issue.

Apart from this, it would help if every comment in an issue would be relatable to the issue as stated in its first/original comment. I see lots of (good and other) discussions in issues that have drifted away from the original topic. It would be nice if there were a way to move such comments into separate issues with a more appropriate title.

TallTed commented 3 years ago

[@RieksJ] It would be nice if there were a way to move such comments into separate issues with a more appropriate title.

Click on the three-dots at upper-right of the comment you want to move.
Choose "Reference in new issue".
Follow your nose through the Github UI to start that new issue.
Presuming that none of its content is relevant to the issue on which it was originally posted, return to the comment you started with in (1) above.
Click on the three-dots at upper-right of the comment once more.
Choose "Hide".
Follow your nose through the Github UI to choose the appropriate reason for hiding it.
Repeat as necessary.

This doesn't solve the issue of sub-threads where multiple comments should be moved, but it's a good start. Also, it is entirely possible to manually construct a comment-of-quotations, and to then hide all those quoted/moved comments in the original Issue/PR for which they are off-topic.

w3c / vc-data-model

Avoiding confusion by renaming 'credentialSubject' #480