Add section on trust boundaries in privacy considerations. #1324
Conversation
msporny
requested review from
dlongley,
longpd,
iherman,
dmitrizagidulin,
TallTed,
David-Chadwick,
decentralgabe,
brentzundel and
Sakurann
index.html
Outdated
|
|
||
| <ul> | ||
| <li> | ||
| An <a>issuer</a> trusts the issuer software it uses to not issue <a>verifiable |
There was a problem hiding this comment.
| An <a>issuer</a> trusts the issuer software it uses to not issue <a>verifiable | |
| An <a>issuer</a> trusts the issuer software it uses not to issue <a>verifiable |
(Sounds better for my non-native English ears. If I am wrong, just ignore this.)
There was a problem hiding this comment.
Fixed in @TallTed's suggestion.
index.html
Outdated
| <a>verifiable presentations</a> that it is checking. | ||
| </li> | ||
| <li> | ||
| A <a>holder</a> trusts the digital wallet software it uses to not divulge |
There was a problem hiding this comment.
| A <a>holder</a> trusts the digital wallet software it uses to not divulge | |
| A <a>holder</a> trusts the digital wallet software it uses not to divulge |
(Same remark as above.)
There was a problem hiding this comment.
Fixed in @TallTed's suggestion.
index.html
Outdated
|
|
||
| <p> | ||
| The examples above are not exhaustive, and there can be a variety of other | ||
| expectations that roles have of the software that they use to achieve their |
There was a problem hiding this comment.
| expectations that roles have of the software that they use to achieve their | |
| expectations that roles have on the software they use to achieve their |
There was a problem hiding this comment.
See larger change suggestion that includes this line.
There was a problem hiding this comment.
Fixed in @TallTed's suggestion.
index.html
Outdated
| of the role and a violation of those expectations is a violation of trust that | ||
| will result in the software being replaced by something that does not violate | ||
| that trust. Implementers are strongly advised to write software that does not | ||
| violate the trust of the roles they are serving. |
There was a problem hiding this comment.
worth having something on holders/verifiers being able to/auditing the trust boundaries they encounter?
There was a problem hiding this comment.
++ That or a trusted third party (e.g. governance framework auditor). These specs have caught flack for not acknowledging these things within the spec so this seems like a good reference point here to acknowledge it.
index.html
Outdated
| <p> | ||
| There are a variety of trust boundaries that exist in the | ||
| <a href="#ecosystem-overview">ecosystem described by this specification</a>. | ||
| Just like an individual using a web browser trusts the web browser not to betray |
There was a problem hiding this comment.
| Just like an individual using a web browser trusts the web browser not to betray | |
| Just like an individual expects a web browser to behave as a <a href="https://www.w3.org/TR/UAAG20/#def-user-agent">User agent</a> and not to betray |
There was a problem hiding this comment.
Updated to use latest ref: https://www.w3.org/TR/UAAG20/#def-user-agent
index.html
Outdated
|
|
||
| <ul> | ||
| <li> | ||
| An <a>issuer</a> trusts the issuer software it uses to not issue <a>verifiable |
There was a problem hiding this comment.
| An <a>issuer</a> trusts the issuer software it uses to not issue <a>verifiable | |
| An <a>issuer's</a> <a href="https://www.w3.org/WAI/UA/2011/ED-UAAG20-20110525/#def-user-agent">User agent</a> is expected to not issue <a>verifiable |
There was a problem hiding this comment.
Updated to use latest ref: https://www.w3.org/TR/UAAG20/#def-user-agent
index.html
Outdated
| credentials</a> without its permission. | ||
| </li> | ||
| <li> | ||
| A <a>verifier</a> trusts the verifier software it uses to be truthful regarding |
There was a problem hiding this comment.
| A <a>verifier</a> trusts the verifier software it uses to be truthful regarding | |
| A <a>verifier's</a> <a href="https://www.w3.org/WAI/UA/2011/ED-UAAG20-20110525/#def-user-agent">User agent</a> is expected to be truthful regarding |
There was a problem hiding this comment.
See new thread covering lines 4286-4288, accidentally omitted when making suggestions for parallel blocks of lines 4282-4285 and 4291-4294.
There was a problem hiding this comment.
Updated to use latest ref: https://www.w3.org/TR/UAAG20/#def-user-agent
index.html
Outdated
| <a>verifiable presentations</a> that it is checking. | ||
| </li> | ||
| <li> | ||
| A <a>holder</a> trusts the digital wallet software it uses to not divulge |
There was a problem hiding this comment.
| A <a>holder</a> trusts the digital wallet software it uses to not divulge | |
| A <a>holder's</a> <a href="https://www.w3.org/WAI/UA/2011/ED-UAAG20-20110525/#def-user-agent">User agent</a> is expected to not divulge |
There was a problem hiding this comment.
Updated to use latest ref: https://www.w3.org/TR/UAAG20/#def-user-agent
index.html
Outdated
| goals. The common thread between each of these expectations is that each | ||
| role expects the software that it uses to not violate privacy expectations. | ||
| That is, it is expected that the software will operate in the best interests | ||
| of the role and a violation of those expectations is a violation of trust that |
There was a problem hiding this comment.
It would be useful to mention how conflicts of interest may be represented. In many cases, there's likely to be software that represents many different parties and it should be recognized that a software cannot act as a UA for multiple parties at the same time.
There was a problem hiding this comment.
it should be recognized that a software cannot act as a UA for multiple parties at the same time
Just as a lawyer can represent and/or have histories with multiple parties at the same time, even when those parties are on opposite sides of a legal proceeding, the key is informed consent, which sometimes requires judicial review in the case of such a lawyer. Basically, each party SHOULD be advised, with some confirmation required of receipt of that advice ("Click to confirm you've read the user agreement..."), that the software is serving as a UA for all identified parties.
But this rapidly gets into very tangled legal weeds, and I think those are far beyond the scope of this technical spec.
There was a problem hiding this comment.
Agreed - I'm not saying that we should forbid it but rather to recognize that the conflict of interests often times can lead to the collapse of the trust boundaries. This is part of the value in having these external reviews by judges in the legal system where as for us we don't really have any such authority to require that within the technical specification. Hence not really pushing for this to be normatively required, but rather to call out that a UA isn't necessarily always a UA if it's answering to two competing parties. Eventually one will have to take priority over the other.
There was a problem hiding this comment.
I made an attempt at some text in 7fce91e.
There was a problem hiding this comment.
++ that addresses my concerns
|
This is generally going in a good direction IMO. I think it's important that we reference the definition of a UA here so that it's recognized that the software maintains the same expectations as a browser does to it's user. With that said, the definition I used may not be correct (nor the formatting) so if there's a better definition to link to I'm all for it. |
|
Ok, I have made a pass at all of the changes requested in this PR. Requesting a re-review from @kdenhartog, @TallTed, and @iherman. |
index.html
Outdated
| might report such an anomaly to the <a>verifier</a>, which would not be in the | ||
| best interest of the <a>holder</a> committing the violation, but would be in the | ||
| best interest of the <a>verifier</a>. It is strongly advised that when software | ||
| operates in this manner, that it is made clear whose best interest in which the | ||
| software is operating though mechanisms such as a website usage policy. |
There was a problem hiding this comment.
| might report such an anomaly to the <a>verifier</a>, which would not be in the | |
| best interest of the <a>holder</a> committing the violation, but would be in the | |
| best interest of the <a>verifier</a>. It is strongly advised that when software | |
| operates in this manner, that it is made clear whose best interest in which the | |
| software is operating though mechanisms such as a website usage policy. | |
| might report such an anomaly to the <a>verifier</a>, which might be considered to | |
| not be in the best interest of the <a>holder</a> committing the violation, but | |
| would be in the best interest of the <a>verifier</a> as well as any <a>holders</a> | |
| <em>not</em> committing such a violation. It is strongly advised that mechanisms | |
| such as website usage policies be used to make clear the hierarchy of user classes | |
| being protected, when the software is being used to protect the interests of | |
| multiple classes of user. |
There was a problem hiding this comment.
@TallTed I took the following change "might report such an anomaly to the verifier, which might be considered to not be in the best interest of the holder committing the violation, but would be in the best interest of the verifier as well as any holders not committing such a violation." text
... but didn't take: "It is strongly advised that mechanisms such as website usage policies be used to make clear the hierarchy of user classes being protected, when the software is being used to protect the interests of multiple classes of user."
... because it wasn't clear what was meant by "the hierarchy of user classes being protected". I believe the exiting language, as corrected by @brentzundel, is more clear. Let me know if you disagree and/or feel strongly about a particular/other change (and I can apply it to main since it would be editorial).
There was a problem hiding this comment.
A nap between readings helps. That sentence could become this, which I think
When the software is being used to protect the interests of multiple classes of user, it is strongly advised that mechanisms such as website usage policies be used to make clear the classes of user whose interests are being protected.
There was a problem hiding this comment.
++ changes look to address the original concerns raised in the issue. I'm good with the current text and with the modified text suggested by @TallTed
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> Co-authored-by: Brent Zundel <brent.zundel@gmail.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
msporny
force-pushed
the
msporny-wallet-trust
branch
from
0e33336
to
2247213
Compare
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This PR attempts to address issue #1246 by adding a section on trust boundaries in the privacy considerations section.
/cc @kdenhartog
Preview | Diff