Value of JARM for non-repudiation

[Joseph Heenan]

I’m not really clear on what non-repudiation (as per https://openid.net/specs/fapi-2_0-message-signing-01.html#section-5.2 ) benefits JARM provides.

I think it meets the broad goal from section 5.2 that the AS can’t deny having sent the message. However given the message contains little of meaning (it’s basically just authorization code + state + JWS things like aud/iss/exp) it’s unclear to me what use it is to have proof that an AS sent an authorization code. In particular, the message contains nothing that would prove:

1. that the user approved a particular request from the client (because ‘state’ is created by the client and the client could use the same state for more than one request), nor
2. what was originally requested by the client, nor
3. what the user approved (as if the user denied part of the requests, that will only be discovered at the token endpoint when, e.g., the returned scopes are fewer than the client originally requested), nor
4. who the user is

‌

[Daniel Fett]

Even though there is nothing of particular interest in the request, the fact that the AS signed some message might already tell something (the request was considered valid and the AS must have some record of it that may contain further information).

I don’t know though if there are (legal) requirements for which that would be important and useful.

[Dave Tonge]

we discussed on the call that perhaps we should expand the aim to show that the message signing benefit also provides message integrity. Nat made the point that this is useful for JARM.

JARM can also allow some attacks to be detected earlier.

[Dave Tonge]

We had some further discussion and Daniel rightly pointed out that we don’t want to confuse people into thinking they need JARM to be more secure. So while there is a benefit, it's not strictly needed to achieve our security goals.

I volunteered to try out a PR that can communicate this nuance

[Dave Tonge]

I’ve added this clause: https://bitbucket.org/openid/fapi/pull-requests/444 however not sure about it and not sure whether we want something specific in the JARM section

[Brian Campbell]

Alternatively consider adding some text around the limitations of JARM with respect to non-repudiation to this PR https://bitbucket.org/openid/fapi/pull-requests/443 that is about non-repudiation limitations?

[Dave Tonge]

PR merged