Add privacy considerations about status message updates/alterations. #156
Conversation
msporny
requested review from
npdoty,
frankhinek,
dlongley,
jandrieu,
longpd,
iherman,
andresuribe87,
TallTed,
David-Chadwick,
simoneonofri,
brianorwhatever,
decentralgabe,
dezell,
brentzundel and
KDean-GS1
index.html
Outdated
| For example, an <a>issuer</a> could automatically re-issue a | ||
| <a>verifiable credential</a> every three months to break any sort of long-term | ||
| monitoring of a <a>verifiable credential</a> as it changes status and assign | ||
| a new status entry index when the re-issuance occurs. |
There was a problem hiding this comment.
| a new status entry index when the re-issuance occurs. | |
| a new status entry index when the reissuance occurs. |
|
|
||
| <p> | ||
| Once a <a>verifier</a> knows of a status list and entry index that is | ||
| associated with a specific <a>holder</a>, it becomes possible for that |
There was a problem hiding this comment.
| associated with a specific <a>holder</a>, it becomes possible for that | |
| associated with a specific <a>issuee</a>, it becomes possible for that |
There was a problem hiding this comment.
Note that the holder can change but the issuee never changes
There was a problem hiding this comment.
This change requires that the issuee term be accepted and defined by the WG. This has been tried and failed several times. It is not appropriate to insert it via every PR where it might be relevant.
It might be appropriate to create another "define issuee" issue and an associated PR in each repo which puts it into every relevant spot in the existing documents, such that the VCWG can evaluate it in place, instead of in theory or in one location or associated spec as was previously (and again here) tried. This would require substantial and ongoing effort, especially in keeping such PRs synced with the live documents in progress, but I don't see any alternative if issuee is to be successfully added to VCDMv2 and associated specs.
All that said — the issuee (whether or not that term is defined and adopted by the WG) is a special case of a holder, and the status list and entry index association here is with a specific holder which may be but is not necessarily the issuee of that VC.
There was a problem hiding this comment.
I'm rejecting the issuee language in this PR until we have consensus to add the term in the VC Data Model. If we have that, then all of the specs will have to be updated to use that base terminology and we'll revisit this change suggestion in a future PR.
There was a problem hiding this comment.
I think this might be more accurate, and pass muster.
| associated with a specific <a>holder</a>, it becomes possible for that | |
| associated with a specific <a>holder</a> or <a>subject</a> , it becomes possible for that |
There was a problem hiding this comment.
I think this small change needs a new PR to get into the document. I think the other change suggestions have all been applied.
There was a problem hiding this comment.
@msporny can you do this please?
index.html
Outdated
| status without asking the <a>issuer</a> directly for status information on | ||
| the specific <a>holder</a> or when interacting with the <a>holder</a> to get | ||
| the latest status information is not possible. The feature can also cause a | ||
| privacy violation if the <a>holder</a> is unaware of the ability for the |
There was a problem hiding this comment.
The privacy violation is about the subject isn't it? The sentence implies it's about the holder.
Furthermore the privacy violation may occur regardless of whether the holder is aware or not.
There was a problem hiding this comment.
I do not believe this issue has been resolved if the suggested changes have been ignored, because we currently have no documented mechanism for the VC to contain personal information about the holder, but only about the subject.
index.html
Outdated
|
|
||
| <p> | ||
| <a>Issuers</a> can provide a level of reprieve from this privacy concern to | ||
| <a>holders</a> by revoking and re-issuing effectively the same |
There was a problem hiding this comment.
| <a>holders</a> by revoking and re-issuing effectively the same | |
| by revoking and re-issuing effectively the same |
There was a problem hiding this comment.
The concern is not only to the holder, but could be to the subject and relatives of the subject (e.g. consider that I hold the VC passport of my child, then the privacy violation is of concern to me, my wife and my broader family)
There was a problem hiding this comment.
There was a problem hiding this comment.
The point still stands as the text gives the wrong impression if it only talks about the privacy of the holder.
index.html
Outdated
| </p> | ||
|
|
||
| <p> | ||
| This feature creates a potential privacy violation where <a>holder</a> of the |
There was a problem hiding this comment.
| This feature creates a potential privacy violation where <a>holder</a> of the | |
| This feature creates a potential privacy violation where the <a>subject</a> of the |
There was a problem hiding this comment.
Q. Is this status information about the subject or the issuee?
It cannot be about the holder since the holder can be anyone and is not a fixed entity.
| their level of information exposure when using <a>verifiable credentials</a> | ||
| that are associated with status messages and warn them when the level of | ||
| information exposure changes. | ||
| </p> |
There was a problem hiding this comment.
This paragraph is unclear, since it not clear who the status messages are about.
There was a problem hiding this comment.
@TallTed clarified the language in some of his change suggestions, which have now been applied. The status messages are about VCs, which express information about subjects/holders.
There was a problem hiding this comment.
In which way do VCs express information about holders? (when they are not subjects)
There was a problem hiding this comment.
Status messages are always about VCs/VPs; in other words, your question should be "what", not "who". In this sentence, the status messages are about <a>verifiable credentials</a> that are associated with status messages.
In which way do VCs express information about holders? (when they are not subjects)
If nowhere else, VCs express information about holders when issuees are identified, as issuees must be holders. VCs might also express information about authorized presenters who must also be holders, as they cannot present something they don't hold.
There was a problem hiding this comment.
Privacy issues can only be about living people. They are not about verifiable credentials, but about the subjects of them (or the issuee if this not-yet-accepted definition is accepted and the property is added to the VC, which no-one is currently proposing). Hence my original question.
There was a problem hiding this comment.
@David-Chadwick — I think your original question has been addressed by subsequent changes to the text, which now reads:
Holder software can provide features to <a>holders</a> that warn them about the
level of <a>holder</a> and/or <a>subject</a> information exposure when using
<a>verifiable credentials</a> that are associated with status messages, and warn
them when the level of information exposure changes.
To rephrase, <a>verifiable credentials</a> that are associated with status messages expose some level of <a>holder</a> and/or <a>subject</a> information, about which level, and changes to that level, holder software can warn <a>holders</a>. I think this rephrasing is more confusing than the current text, but perhaps it will clarify things for you?
There was a problem hiding this comment.
The text which now reads..... does address my issue. Thankyou. But I cannot understand your re-phrasing paragraph below it. Sorry. I agree with you that it is very confusing!!
|
|
||
| <p> | ||
| Once a <a>verifier</a> knows of a status list and entry index that is | ||
| associated with a specific <a>holder</a>, it becomes possible for that |
There was a problem hiding this comment.
This change requires that the issuee term be accepted and defined by the WG. This has been tried and failed several times. It is not appropriate to insert it via every PR where it might be relevant.
It might be appropriate to create another "define issuee" issue and an associated PR in each repo which puts it into every relevant spot in the existing documents, such that the VCWG can evaluate it in place, instead of in theory or in one location or associated spec as was previously (and again here) tried. This would require substantial and ongoing effort, especially in keeping such PRs synced with the live documents in progress, but I don't see any alternative if issuee is to be successfully added to VCDMv2 and associated specs.
All that said — the issuee (whether or not that term is defined and adopted by the WG) is a special case of a holder, and the status list and entry index association here is with a specific holder which may be but is not necessarily the issuee of that VC.
index.html
Outdated
|
|
||
| <p> | ||
| <a>Issuers</a> can provide a level of reprieve from this privacy concern to | ||
| <a>holders</a> by revoking and re-issuing effectively the same |
There was a problem hiding this comment.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> Co-authored-by: David Chadwick <d.w.chadwick@truetrust.co.uk> Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
|
Editorial, multiple reviews, changes requested and made (except for one that was deferred until later), no objections, merging. |
| their level of information exposure when using <a>verifiable credentials</a> | ||
| that are associated with status messages and warn them when the level of | ||
| information exposure changes. | ||
| </p> |
There was a problem hiding this comment.
In which way do VCs express information about holders? (when they are not subjects)
|
|
||
| <p> | ||
| Once a <a>verifier</a> knows of a status list and entry index that is | ||
| associated with a specific <a>holder</a>, it becomes possible for that |
There was a problem hiding this comment.
Then please change holder to subject.
index.html
Outdated
| status without asking the <a>issuer</a> directly for status information on | ||
| the specific <a>holder</a> or when interacting with the <a>holder</a> to get | ||
| the latest status information is not possible. The feature can also cause a | ||
| privacy violation if the <a>holder</a> is unaware of the ability for the |
There was a problem hiding this comment.
I do not believe this issue has been resolved if the suggested changes have been ignored, because we currently have no documented mechanism for the VC to contain personal information about the holder, but only about the subject.
index.html
Outdated
|
|
||
| <p> | ||
| <a>Issuers</a> can provide a level of reprieve from this privacy concern to | ||
| <a>holders</a> by revoking and re-issuing effectively the same |
There was a problem hiding this comment.
The point still stands as the text gives the wrong impression if it only talks about the privacy of the holder.
This PR is an attempt to address issue #146 by documenting how status messages could be used to accidentally expose more information about a holder than they originally thought and how holder software could be used to warn the holder of changes in status message information.
Preview | Diff