- From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
- Date: Sat, 19 Dec 2020 07:50:03 +0000
- To: Alan Karp <alanhkarp@gmail.com>
- CC: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <c78eae26b576484dbf83d11833493419@tno.nl>
Thanks for sharing your thoughts. It helps me see more clearly what I'm not after, thus limiting my ball-park: * I know people can share private keys, but I consider that a different issue. * Other solutions, however flaky they may be, may also have their uses (e.g. if only to reduce a small part of a risk) * Thanks for pointing me to the confused deputy problem – while I was aware of some of the examples, I didn't know there was an entire class of them. My question lies before before thinking of solutions.I'm looking for use-cases that clearly illustrate the need for knowing (the identity of) two or more entities that are relevant for making the decision. It seems obvious that one of these entities is the requester. The other entity may be a person, e.g. if the requester wants to ask for a decision on that person's behalf. Many cases seem to exist where people and/or organizations represent one another. I wonder if we can find a use-case where the entity that is not the requester is something else, and the use-case illustrates the difficulty the verifier has to make sense of the identifier/identity that the requester presents for that entity. Rieks From: Alan Karp <alanhkarp@gmail.com> Sent: woensdag 16 december 2020 18:02 To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl> Cc: W3C Credentials CG (Public List) <public-credentials@w3.org> Subject: Re: looking for a specific use-case AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote: @Alan Karp: * I agree that the SP would need to know the permissions. However, I'm particularly interested to find out about cases where actual authentication of both people/identities is in play: where the SP would not only need to ensure that the one presenting the credential is one of the people mentioned in that credential, but also that the person that does not present the credential is actually present in the company of the first. It's important to remember that people can share private keys. That means you can never know who, only who to hold responsible. Physical presence is very hard to prove online. One trick is to use the speed of light. Send a nonce to Alice, have her hand it to Bob, and have Bob send the nonce back to you. Assuming you know the transmission time to Alice (a huge assumption), you can figure out if she is close to Bob. As flaky as this sounds, something like it has been used to protect data centers from remote attacks. * * Can you clarify what you mean with 'confused deputy vulnerability' – I have no clue what you mean but would really like to understand. The Wikipedia page, https://en.wikipedia.org/wiki/Confused_deputy_problem, has a good description, and Norm Hardy's paper cited there is a fun read. It turns out that there are many confused deputy vulnerabilities, things like cross-site request forgery. I also recommend http://waterken.sourceforge.net/aclsdont/current.pdf. -------------- Alan Karp This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Received on Saturday, 19 December 2020 07:50:20 UTC