Remove delegation

[David-Chadwick]

---

Preview | Diff

[brentzundel]

I do like this paragraph.

[brentzundel]

With selective disclosure, there is no way to ensure that a verifier ever sees the Subject Only Terms of Use.

[dlongley]

Please see the question here about this issue: #282 (comment)

[dlongley]

Post ZKP discussion: The selective disclosure schemes being implemented do indicate that a ToU is present in a credential definition, allowing for a verifier to request it (and thereby require it). The presenter can also prove if their particular credential happens to not possess a ToU should it be requested but not present.

[David-Chadwick]

Great. So I will update the PR to remove conflicts with the latest version of the spec

[msporny]

Merge conflicts are preventing the merge of this PR.

[David-Chadwick]

I believe I have now resolved the conflicts, and I have also replaced the subjectOnly ToU with subjecOnly property.

@msporny. I already posses two physical plastic cards that are marked subjectOnly by the issuer. So I am quite sure that this property will be a common use case for VCs.

[msporny]

A file called index.text has been added to this PR. Please remove it so I can pull the PR in. All the other changes seem good to me.

@msporny I dont know how this happended or what it contains. I also dont know how to remove it. Can you advise me please

[msporny]

@msporny. I already posses two physical plastic cards that are marked subjectOnly by the issuer. So I am quite sure that this property will be a common use case for VCs.

It's not the use case that I'm concerned about. It's the data modeling aspect of it, which I haven't been able to think about deeply. At present, almost all VCs our company is issuing are "subjectOnly" credentials, which are implicit and which the verifier determines whether or not to allow anyone except for the subject to use them... the rules are often complex and we are concerned about issuers placing "subjectOnly" on every credential and hobbling the ecosytem by doing so. Like, for example, due to regulatory pressures, prescription issuing software may mark those VCs as "subjectOnly" when quite often people pick up prescriptions for other people. Marking those things as "subjectOnly" may force implementations to break conformance to make complex determinations... subjectOnly feels like a hammer for an ill-defined problem.

[David-Chadwick]

@msporny. I think you are introducing red herrings in your discussion above.
First you do not hobble any system with our conformance clauses because we have already agreed that any verifier can accept anything at its own liability. So in this case the verifier would switch off any software checking that might be in the validation code (and be non-conformant to whichever protocol spec it was using). So breaking conformance as you suggest is not a data model issue, it is a usage and protocol issue which is out of the scope of our standard.

In one of my plastic cards, the local council is the issuer of my free bus pass, and it has EXPLICITLY stipulated Subject Only on it, to all the verifiers (buses) in the country. i.e. only I am entitled to free travel on buses with this VC. So
a) it does not matter who the verifier is
b) it does not matter what the usage is
b) it is not implicit it is explicit
A standard way of indicating this in the data model will be a common requirement.

[David-Chadwick]

@msporny I don't know how the index.text file got there and I don't know how to delete it. Could you help please

[msporny]

A standard way of indicating this in the data model will be a common requirement.

Yes, agreed. I don't think the current way it's being expressed in the data model is the right way to do it... but don't have an alternate suggestion at this point (I will in time, but haven't been able to think about it deeply). In other words, not suggesting how to do it is better than suggesting the wrong way to do it.

I think the right way to do it is probably by putting it in termsOfUse that the issuer provides.

[msporny]

@msporny I don't know how the index.text file got there and I don't know how to delete it. Could you help please

Fixed.

[David-Chadwick]

@msporny Thanks for fixing the index.text file problem.
However, your argument is a non sequitur. "I have not thought about it deeply" but "the current way ... is the wrong way" ?*?
Have a Happy Christmas and maybe when you are digesting your turkey dinner you might come up with a better way :-)
In which case I will only be too happy to support it in 2019.