RE: looking for a specific use-case

@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.
  *   Can you clarify what you mean with 'confused deputy vulnerability' – I have no clue what you mean but would really like to understand.
Rieks

From: Alan Karp <alanhkarp@gmail.com>
Sent: dinsdag 15 december 2020 18:08
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

oosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:
I'm looking for a use-case, which I think requires:

  *   that is realistic;
  *   that involves (at least) two people, as e.g. in a marriage, a guardianship or otherwise, and some service provider (SP);
  *   where SP has no earlier knowledge of any of these two people (he doesn't know who these people are);
  *   where SP can obtain credentials from only one of these persons (the other is somehow incapable of presenting credentials);
  *   where SP is requested to make a decision (e.g. to provide a service);
  *   where SP needs to authenticate *both* persons in order to make that decision.
That's a good set of requirements, except the last.  Authenticating the two identities, which I assume is what you meant, is less important for the SP than knowing what permissions they have.  Using authentication of identity, role, or attributes to make an access decision often leads to a confused deputy vulnerability.

--------------
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.