Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add privacy considerations about status message updates/alterations. #156

Merged
merged 4 commits into from
Mar 30, 2024
Merged

Add privacy considerations about status message updates/alterations. #156

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
27f5628
Add privacy considerations section on status list monitoring.
msporny Mar 24, 2024
6b654f5
Add section on status message alterations.
msporny Mar 24, 2024
723ee57
Fixes to grammar about status message updates.
msporny Mar 30, 2024
83805bb
Clean up some subject/holder markup in status message section.
msporny Mar 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 60 additions & 1 deletion index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1171,7 +1171,36 @@ <h3>Malicious Issuers and Verifiers</h3>
</section>

<section class="informative">
<h3>Multistatus Correlation</h3>
<h3>Monitoring Status Lists</h3>

<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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
associated with a specific <a>holder</a>, it becomes possible for that
associated with a specific <a>issuee</a>, it becomes possible for that

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the holder can change but the issuee never changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@msporny msporny Mar 30, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be more accurate, and pass muster.

Suggested change
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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, Thankyou.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this small change needs a new PR to get into the document. I think the other change suggestions have all been applied.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny can you do this please?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See new PR #163

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then please change holder to subject.

<a>verifier</a> to see updates to that status entry as long as the
status list continues to be updated. This is useful to a <a>verifier</a> that
needs to understand when a particular <a>verifiable credential</a> has changed
status without asking the <a>issuer</a> directly for status information on
the specific <a>verifiable credential</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 for the <a>holder</a> and/or <a>subject(s)</a> if the
<a>verifier</a> is able to perform near-real-time checks on the status of the
<a>verifiable credential</a>.
</p>

<p>
<a>Issuers</a> can provide a level of reprieve from this privacy concern
<a>holders</a> by revoking and reissuing effectively the same
<a>verifiable credential</a> on a timeline that is relatively short in nature.
For example, an <a>issuer</a> could automatically reissue a
<a>verifiable credential</a> every three months and assign a new status entry
index when the reissuance occurs to break any sort of long-term monitoring
of a <a>verifiable credential</a> as it changes status.
</p>

</section>

<section class="informative">
<h3>Correlation of Status Messages</h3>
<p>
This specification provides a means by which multiple status messages can be
provided for a particular entry in a status list. While this mechanism can
Expand Down Expand Up @@ -1199,6 +1228,36 @@ <h3>Multistatus Correlation</h3>
</p>
</section>

<section class="informative">
<h3>Alteration of Status Messages</h3>

<p>
When a status list uses the status messages feature, it becomes possible for
the <a>issuer</a> to increase the types of messages that are associated with
the <a>verifiable credentials</a> it issues over time.
</p>

<p>
This feature creates a potential privacy violation where the
<a>subject</a> or <a>holder</a> of the <a>verifiable credential</a> might be
associated with additional status information that was not present when the
original <a>verifiable credential</a> was issued. For example, initial status
messages might convey "delayed" and "canceled", but additional status messages
might be added by the <a>issuer</a> to convey "delayed due to non-payment" and
"canceled due to illegal activity". This change would not be apparent to the
<a>subject</a> or <a>holder</a> unless there was monitoring software operating
on their behalf that would warn them that the <a>issuer</a> intends to expose
additional information about their activity.
</p>

<p>
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.
</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is unclear, since it not clear who the status messages are about.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which way do VCs express information about holders? (when they are not subjects)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@David-Chadwick —

it not clear who the status messages are about

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

</section>

</section>

<section class="informative">
Expand Down
Loading