Write initial privacy considerations for unnecessary use#262
Conversation
RByers
left a comment
There was a problem hiding this comment.
I wasn't sure of how much of this we wanted in our spec vs. other docs like credential-considerations. But if the WG agreed we should go into this level of details here (even though DC API is just one small piece of the larger picture) then I think this is a great start and I'm supportive of adding it to the spec.
TallTed
left a comment
There was a problem hiding this comment.
Small changes in quest for better clarity
Thanks for proofreading! |
To be clear there was no explicit discussion which could signal consensus but #243 has been unchallenged for some time and I believe that it is an important question for the DC API, even though many of these things would have to be addressed at a larger societal level. |
| </li> | ||
| <li>User agents are responsible for protecting their users against | ||
| dangerous content and permission requests on the Web and could | ||
| intervene on their behalf, proactively rejecting requests. |
There was a problem hiding this comment.
Yes, which is why we required the requests not be encrypted by design/from the start. We should say that we do this on purpose (i.e., the browser is not a "dumb pipe" here).
There was a problem hiding this comment.
I do mention this in other places. I feel like this is more of a high-level overview of the different actors and maybe not the place to get into design decisions?
There was a problem hiding this comment.
I don't agree. It's a design consideration that some are willing to violate.
There was a problem hiding this comment.
Ok, I don't feel strongly about this - I'm happy to note that it's supported by the API design.
| with purpose attestations. Wallets might be expected to enforce these | ||
| restrictions. | ||
| </li> | ||
| <li>The ultimate decision of whether or not to share their personal |
There was a problem hiding this comment.
We should again say, "by design" ... the spec requires a UI to be presented (or it will... that will be a MUST).
There was a problem hiding this comment.
I can mention that.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
Co-authored-by: Kyle Den Hartog <kdenhartog@users.noreply.github.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
f553c3e to
57870a9
Compare
|
@marcoscaceres PR is rebased and (hopefully) ready for another review |
| </li> | ||
| <li>The ultimate decision of whether or not to share their personal | ||
| information lies with the user, which is why the API requires the | ||
| user agent to present a credential picker to the user, and other |
There was a problem hiding this comment.
In most cases, the client device (another reason why having that term in the spec as a logical construct is really important) presents the credential selector, not the user agent.
There was a problem hiding this comment.
I guess my initial phrasing here was that the user agents shows a permission prompt, which @marcoscaceres changed to "credential picker". I would prefer not to bikeshed on this too much personally, this is important to get right in normative text but here I think we all know what's being expressed.
There was a problem hiding this comment.
Let's follow up on the wording (client vs user agent, permission prompt vs. credential picker) in a new PR once the terminology discussion concludes.
Co-authored-by: Tim Cappalli <tim@cappalli.me>
Co-authored-by: Tim Cappalli <tim@cappalli.me>
|
I believe we resolved all the issues - leaving the ones unresolved where I feel like there could be a chance someone might want a follow-up, but overall I don't think any of them block us from merging this. Thank you all for the constructive review! |
@npdoty there are some things here that strongly touch on ethical considerations which I think you'd probably be able to say much more detailed and eloquently than I can, so I'm happy to get your thoughts and potential contributions (maybe as a follow-up). But I hope this is a solid start that captures the main issues and, where possible, mitigations.
Preview | Diff