[Openid-specs-fapi] Ensuring one-time use of request JWTs registered at the request JWT endpoint

[Nat Sakimura]

Good points. 

1. One-time use of `request_uri`

By this, I meant that `request_uri` could be used only once against the authorization endpoint. I did not mean that the GET to `request_uri` value should fail for the second access. I understand that the text is ambiguous and needs to be clarified. 

2. Attacker re-registering the request object

Now, as to the problem of the replay against the request object endpoint, the client needs to include a nonce. 
I thought that `nonce` was required in Hybrid Flow, but is apparently not. 
So, it needs to be stated. 
Once `nonce` is there, iss (client_id) + redirect_uri + nonce become globally unique. 
It will act as the unique identifier for the request object. 
The AS needs to check it to find if it has been used before. 

Unless the request object has `exp`, the AS has to maintain the state indefinitely, which is not practical. 
So, we also need to state that `exp` needs to be included and it should expire in a short period of time. 

With it, the request object endpoint can reasonably reject the replay. 

What do you think? 

Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.


> -----Original Message-----
> From: Openid-specs-fapi
> [mailto:openid-specs-fapi-bounces at lists.openid.net] On Behalf Of Vladimir
> Dzhuvinov via Openid-specs-fapi
> Sent: Wednesday, August 2, 2017 4:22 PM
> To: openid-specs-fapi at lists.openid.net
> Subject: [Openid-specs-fapi] Ensuring one-time use of request JWTs registered
> at the request JWT endpoint
> 
> It appears to me that one-time use of request objects registered by URI cannot
> be guaranteed, unless read access to the request_uri is strictly limited to
> the AS only.
> 
> Consider the following scenario:
> 
> 1. Client registers request object at request_uri, one-time GET policy is
> enforced, but the URL is world readable.
> 2. Malicious JS code in the browser GETs the request_uri 3. The authorization
> request will fail due to invalid request_uri 4. The malicious JS code can still
> re-register the request object as many times as it wants
> 
> 
> The statement in 7.2 may also need to be revised then:
> 
> http://openid.net/specs/openid-financial-api-part-2.html#request
> 
> > The request object needs to be signed for the client authentication
> > and as the evidence of the client submitting the request object, which
> > sometimes is called 'non-repudiation'.
> 
> If the request_uri is world readable, even if the AS takes measure to make
> it hard to guess, the end-user / user agent will always be able to get it and
> re-register it, which means the signature doesn't really hold as evidence of
> the client submitting the request JWT.
> 
> 
> Vladimir