Clarify step-up authentication semantics for token exchange

[mcguinness]

No description provided.

[aaronpk]

see comments inline

[sdesen]

Should it specify is the acr_values response from idp is exhaustive, or specific to what was missing from the request that cause it to be rejected?

[sdesen]

Also, can / should ACR values be advertised in https://github.com/mcguinness/draft-mcguinness-token-xchg-target-svc-disco

[bc-pi]

I must confess to some reservations with this. Despite some familiarity with RFCs 9470 and 8693, this wasn't a combination I'd necessarily envisioned. I realize there's already some text about Step-Up in the document but I'm not sure the existence of some text is necessarily convincing for doing more. And some awkwardness here, to me anyway, points to fundamental things not readily resolvable with comments on a PR.

[aaronpk]

Since the ID-JAG carries the login state from SSO into the client, that may not be sufficient to access a particular resource. For example:

• App 1 (Client) requires any 2 factors for SSO
• App 2 (Resource) requires a phishing-resistant factor for SSO

So when the user first logs in to the Client, they may authenticate at the IdP with password + OTP. When the client requests an ID-JAG for the Resource, the password + OTP factors don't meet the requirement of phishing-resistant that is required for the Resource.

This lets the IdP return an error that will trigger the client to start a new SSO flow with the appropriate factors needed for the Resource.