search

decentralized-identity / presentation-exchange

Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission)
https://identity.foundation/presentation-exchange
Apache License 2.0
83 stars 37 forks source link

Fundamental defect - the entity making the request is not strongly identified #177

Closed TomCJones closed 3 years ago

TomCJones commented 3 years ago

If the holder does not get a strong identifier from the verifier - meaning a binding to a real-world entity that can be trusted - there is no reason supplied for the holder to release any information. The following is all that is stated, this is insufficient.

Signature verification - A Holder may wish to have assurances as to the provenance, identity, or status of a Presentation Definition. In this case, a Presentation Request that uses digital signatures may be required.

No provision for the holder to present requirements is described. I would suggest that a did for a verifier without strong real-world identification is never going to be sufficient proof for release of anything, ever.

Note that the presentation request as written is a denial of service attack just waiting to be deployed.

decentralgabe commented 3 years ago

Out of scope of the spec. This is exactly why I proposed a Verifiable Request in the W3C, and we're having a call on the 27th to discuss it. https://lists.w3.org/Archives/Public/public-credentials/2020Dec/thread.html https://lists.w3.org/Archives/Public/public-credentials/2021Jan/thread.html

agropper commented 3 years ago

There are privacy interests on both the holder and verifier side. The holder is free to ignore the request if the verifier provides inadequate attributes. Does the spec prevent the verifier from presenting strong credentials? If not, then it's the best we can do. Becoming a holder does carry responsibility. That's the essence of self-sovereignty.

On Fri, Jan 15, 2021 at 6:42 PM Gabe notifications@github.com wrote:

Out of scope of the spec. This is exactly why I proposed a Verifiable Request in the W3C, and we're having a call on the 27th to discuss it. https://lists.w3.org/Archives/Public/public-credentials/2020Dec/thread.html https://lists.w3.org/Archives/Public/public-credentials/2021Jan/thread.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/presentation-exchange/issues/177#issuecomment-761257168, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YOKTW7GO6PLT2XBZJLS2DHH3ANCNFSM4WEWQQWQ .

csuwildcat commented 3 years ago

I agree with @agropper - we are simply providing an expressive, functional interface by which Verifiers can detail what data/claim inputs they need and the specific value criteria those claims must exhibit. It is up to the Verifier to determine what sources of those claims they will accept or reject.

I think we should mark this pending close, because it's just not the job of this spec to determine who trusts who, or how analog trust is synthesized to digital trust.

csuwildcat commented 3 years ago

@brentzundel will add text in the Presentation Request section and the Abstract to reflect the assurances around who the DIDs are owned by and how much you trust them is not in scope.