Non Repudiation

[Dave Tonge]

Is there some intuition as to what "non-repudiation" means in the context of FAPI 2.0 Message Signing? There is of course the technical meaning of "somebody with the signing key has seen and signed this message", but if there is any intuition behind this, we could try to capture that intuition in our security properties (rather than just the technical meaning)

From Tim Würtele

‌

[Dave Tonge]

also from Tim Würtele:

In the same context as above: With PAR+JAR, the /actual/ authorization request remains as-is, i.e., without a signature. Depending on whether there is some intuition behind non-repudiation, the lack of a signature on the actual authorization request may have unintended consequences (e.g., what if a client sent a PAR, but claims to have never sent the actual authorization request?). Again, whether this is an interesting thing to look at depends on the above.

‌

[Dave Tonge]

We discussed this on the call today.

The main aim of non-repudiation in this spec is that the sender of a message cannot deny having created it.

A few examples:

1. When a client is starting a flow to make a payment, those payment parameters, either expressed in a scope or in a RAR object can be signed as part of a JAR/PAR request. If the client later turns around and says I never asked for a payment to X, the receiver (bank) has the signed message to show that the payment request originated from the client.
2. If a resource server responds with some account information including a balance and an account number, if this is signed (with HTTP signatures) then the receiver has some proof that the resource server responded with those values.

We discussed on the call that we can’t make any claims about their being non-repudiation across an entire flow - we are only able to provide functionality for an individual request or response to be signed.

You make a good point with the actual front-channel authorization request being unable to be signed - this is something that we will add to the security considerations.

We will also add a security consideration about the fact that it may be difficult to link a signed message to a real world user (e.g. the fact that a list of bank transactions is signed isn’t enough to say that these were transactions for user X and account Y)

I hope this helps, but please ask any further clarifying questions that you have.

‌

‌

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/443

[Dave Tonge]

PR merged