Security Considerations

[quartzjer]

I did some searching and haven't seen any past discussion on having an official Security Considerations section of this spec, so I thought I might suggest it.

One topic that would be good to include in such a section would be guidance around the processing of a presentation submission. Regardless of the transport, the Holder should never generate an automated response to a submission. This is obvious in the positive case where all the presentation requirements are met and there should be subject consent. It's a very important consideration in the negative case as well in order to prevent a "Presentation Profiling" attack.

If a Verifier has the ability to selectively interrogate and profile the Holder by initiating multiple presentation exchanges with specific requirements, it will defeat the purpose of privacy protection and leave the Holder vulnerable to correlation and tracking.

[agropper]

I disagree with the framing that "the Holder should never generate an automated response to a" request. I have no idea what a submission is but I can understand that a request can result in a response such as a presentation.

Our goal should not be to burden the human that controls the holder with the cost of manually processing requests, filtering spam, and dealing with DoS attacks. Our goal should be to drive the cost of requests to match the cost of processing them. A refundable deposit would be one such strategy. Trustees and other semi-autonomous agents would be another.

[dwaite]

I have no idea what a submission is but I can understand that a request can result in a response such as a presentation.

FYI https://identity.foundation/presentation-exchange/#presentation-submission

[dwaite]

Our goal should not be to burden the human that controls the holder with the cost of manually processing requests, filtering spam, and dealing with DoS attacks.

I don't believe that was Jeremie's point. My understanding of his point was that any automated processing for requests should not leak information. Automated errors (especially rich automated errors) can be used to build user profiles. FWIW, this is a problem that FIDO and the Web Authentication group at the W3C have spent years on.

Our goal should be to drive the cost of requests to match the cost of processing them

This tends toward the creation of exclusionary systems - fine in some contexts, but not in many others.

[agropper]

I agree @dwaite and apologies if I did not acknowledge the problem as leaking information, which I did. I understand the difficulty of the situation and I try to take the role of privacy advocate in these conversations.

The problem with SSI is that it introduces a holder in the name of privacy but neglects to consider how the subject can delegate that role to experts, self-sovereign agents, and fiduciaries. As a result, we oversimplify difficult problems like this one.

I don’t have a perfect crypto answer. I just reacted to the categorical “never”.

[csuwildcat]

Add this into the Implementation Guide, given considerations were added inline.