shall vs shall only

[Dave Tonge]

From the discussion here: https://bitbucket.org/openid/fapi/pull-requests/442

Lukasz made a good point that we don’t appear to be consistent with our use of shall and shall only, for example:

shall support confidential clients as defined in [@!RFC6749];

shall only issue sender-constrained access tokens;

We discussed on the call today that while not recommended, it should be possible for a FAPI2 compliant AS to support non-FAPI2 flows - we should bear this in mind when considering this issue.

[Dave Tonge]

we had a discussion and discussed that it is good for profiles to be prescriptive. suggestion to review spec and ensure consistency, erring on the side of prescription.

[Dave Tonge]

so I think the only clause to change is:

1. shall only issue sender-constrained access tokens;

All other instances of shall only seem as if they have semantic meaning that would be lost if we removed the only:

shall only offer TLS protected endpoints and shall establish connections 
    to other servers using TLS;

 1. When using TLS 1.2, servers shall only permit the cipher suites listed in (#tls-12-ciphers).

  2. When using TLS 1.2, servers shall only use cipher suites allowed in
     [@!RFC7525].

 1. shall only use authorization server metadata (such as the authorization endpoint) retrieved from the metadata document as specified in [@!OIDD] and [@!RFC8414];

 1. shall only send `client_id` and `request_uri` request parameters to the authorization endpoint (all other authorization request parameters are sent in the pushed authorization request according to [@!RFC9126])'.

‌

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/453

[Nat Sakimura]

Merged in issue-631 (pull request #453). Fixed #631.

editorial: make shall only consistent

Approved-by: Daniel Fett Approved-by: Dima Postnikov Approved-by: Brian Campbell Approved-by: Nat Sakimura

→ <<cset 7682b4d9ccf1>>