Bring fapi1-adv request object signing requirements into fapi2-adv

[Joseph Heenan]

fapi1-adv has a few clauses around request object nbf/exp that should be pulled across to fapi2-adv in order to provide “non-repudiation” (or at least to narrow the time a request was signed down to a narrower window and prevent the creation of request objects with unreasonably long lifetimes).

[Joseph Heenan]

Pull request: https://bitbucket.org/openid/fapi/pull-requests/320

[Filip Skokan]

Non-repudiation is already given through the use of private key utilizing digital signatures. IIRC Nbf/Exp in Fapi1-adv was required to limit replayability since the request object was sent in the front channel.

In FAPI 2.0 Adv. the signed request object is only sent to the PAR endpoint in a client-authenticated request which seems to not require such treatment.

I guess it wouldn’t hurt but is there justification for it? Let’s not lose track of why these measures were added in the first place.

[Joseph Heenan]

Non-repudiation is already given through the use of private key utilizing digital signatures.

I may have got entirely the wrong end of the stick, but I thought the non-repudiation needed to include some element of when the message was signed, and a bog standard JAR request object doesn’t have that.

[Filip Skokan]

FYI I am likewise outside of my comfort zone here. The signer cannot refute they are the ones who signed the request object, or rather that their private key was used to do so. A claim present in the signed assertion does not guarantee it reflects an honest value anyway and so IMHO adds nothing to non-repudiation itself?

[Joseph Heenan]

I agree that it does not guarantee that, but as/if the server rejects objects where nbf/exp are not close to the current time, it gives you some sort of proof of at least when the sender intended to sign the message. It’s not cast iron, but it’s something. Whether it’s useful enough I don’t know, but e.g. I’m presuming there’s similar logic behind why the signed introspection responses draft requires iat.

‌

[Joseph Heenan]

Discussed on today's call.

There is some question mark over the exact meaning of non-repudiation. The general feeling on the call was probably that we do need some element of time in the message for non-repudiation purposes.

Dave suggested we should write a bit of text to explain what use cases we intend the 'non-repudiation' to cover.

[Filip Skokan]

Furthermore we’ve agreed to move ahead with PR #320 while we still clear out this issue to avoid us having to question this topic in the future.

[Dave Tonge]

PR merged - I've added a link to this issue in the non-repudiation issue