[Openid-specs-fapi] Notice of WG Votes for Refresh Token Rotation (July 17)

[Nat Sakimura]

Dear FAPI WG:

In today's call, we will vote on the issue of refresh token rotation, as
shown below.

Best regards,

Nat Sakimura

On Thu, 4 Jul 2024 at 11:15, Nat Sakimura <nat at sakimura.org> wrote:

> Dear FAPI WG members:
>
> It is one of the rare occasions that we have to take a vote to come to a
> decision.
>
> Here is the summary of the discussion on July 3.
>
>    - Issue:
>    https://bitbucket.org/openid/fapi/issues/694/refresh-token-clause-readability
>    - Extensive discussion on whether to allow refresh token rotation and
>    under what circumstances.
>    - Lukasz presented 6 options, with the debate focusing on options 1
>    (forbid rotation) vs 5/6 (allow occasional rotation).
>    - Concerns were raised about interoperability and existing
>    implementations.
>    - No consensus was reached. The chair proposed to send out a vote on
>    the mailing list for options 1 and 5.
>
>
> *Option 1: *Ban refresh token cycling in FAPI2 SP
>
>    - Description: Keep shall not use refresh token cycling in the AS
>       requirements and that’s it.. The spec does not give an option to use RT
>       cycling.
>       - Pros: Interoperability.
>       - Cons: No real option to use RT rotation from time to time for
>       operational reasons and comply with the spec.
>       - Issues and concerns: It is not allowed for the target ecosystem
>       to overwrite it in its specification
>
>
> *Option 5: *ban RT rotation, but allow occasional use in *extraordinary* cases
> and set precise additional rules regarding the old RT invalidation
>
>    - Description: See PR505
>    <https://bitbucket.org/openid/fapi/pull-requests/505> as a baseline +
>    specify that AS must keep the old RT until the client uses the new RT for
>    the first time. If the new RT is used the AS shall invalidate the old RT.
>    - Pros: RT is not used on regular basis. If it is used occasionally
>    the ecosystem is interoperable as it is covered by the conformance tests.
>    Even if implementation violates the spec and uses it on regular basis it is
>    interoperable.
>    - Cons: ? Are there any?
>    - Issues and concerns: Additional implementation on AS side.
>
>
> See PR505 <https://bitbucket.org/openid/fapi/pull-requests/505>:
> https://bitbucket.org/openid/fapi/pull-requests/505
>
> While I have indicated that I will do the vote over email, after
> consulting the process document, it does not seem actionable. Therefore, I
> am calling the voting during the meeting. Per the OpenID Process, it will
> be a simple majority vote.
>
> The Vote will take place at the FAPI WG Meeting on July 17, considering
> the notice period. You are entitled to nominate a proxy if you have to. In
> that case, please notify the chairs of the nomination in writing.
>
> Best regards,
>
> Nat Sakimura
> FAPI WG Co-chair
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20240717/09bd91e8/attachment-0001.html>