Resolve '?' in FAPI1 vs FAPI2 differences table

[Joseph Heenan]

‌

We should probably do something about the '?' in this table:

I’d suggest we can say something like “PAR request uris have a limited lifetime” (and adding a ‘shall’ clause with a limit on lifetime as I think the PAR RFC doesn’t have any normative language on this point?).

[Nat Sakimura]

Daniel agreed.

[Mark Verstege]

Australia has chosen a Request URI expiry requirement of between 10 seconds and 90 seconds.

RFC9126 does provide indicative guidance, but not explicit restrictions:

The request URI lifetime is at the
discretion of the authorization server but will typically be
relatively short (e.g., between 5 and 600 seconds)

‌

[Joseph Heenan]

Suggested text: “shall issue pushed authorization responses with expires_in values between 5 and 600 seconds.”

and for the table:

”prevents pre-generation of requests”

[Joseph Heenan]

Add explicit clause about lifetime of request_uri

This resolves a '?' in the FAPI1 vs FAPI2 table.

The upstream spec doesn't have any required lifetimes, only recommended ones. We turn the recommendation into a 'shall'.

closes #471

→ <<cset d156a751679a>>

[Joseph Heenan]

pull request here: https://bitbucket.org/openid/fapi/pull-requests/314/add-explicit-clause-about-lifetime-of

[Nat Sakimura]

Maybe a good idea but not directly can be derived from the attacker model.

Also, it may limit the applicability to some use-cases.

[Dave Tonge]

Add explicit clause about lifetime of request_uri

This resolves a '?' in the FAPI1 vs FAPI2 table.

The upstream spec doesn't have any required lifetimes, only recommended ones. We turn the recommendation into a 'shall'.

closes #471

→ <<cset ed02693a0de7>>