Hi Vittorio, thanks for the quick response. On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci < vittorio.berto...@okta.com> wrote:
> On the SHOULD on top of S4. There are pretty common situations in which > failing to get a response from an API is an acceptable outcome, and > presenting an interactive prompt isn't. A classic example is a background > update that the client can use to proactively fetch fresh data, that isn't > critical for the application function and wasn't initiated by the user. As > such, an interactive prompt could disrupt the user experience by requiring > an action without clear context and not in pursuit of a goal the user > expressed. A MUST would force a complying client to act on the challenge, > making those scenarios hard to handle. > > On the SHOULD on top of S5. There we are just describing what the OIDC > specification mandates for ID tokens, hence not providing any new normative > guidance.We echo what OIDC mandates for ID tokens there because we want to > apply the same logic for access tokens, as we later describe in the same > section. In that description we don't introduce a more restrictive MUST > because that would make it hard for the (many) existing authorization > server+OIDC implementations to comply, limiting adoption and for a > relatively small return. > I think it would be good to say something like what you just said for the first one, and maybe make it clear that you're relaying normative guidance from OIDC and not making a new assertion. Or you could just say implementers need to meet the constraints around ID tokens specified by OIDC. -MSK
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
