Let's take the following (very common) scenario: * A user logs into the system; * They request an operation that might require additional confirmation from the user, at the system's discretion. The most common example would be payment / money transfer, but could also be generating a statement or showing card details or any other sensitive operation; * The user is then directed to the AS where they are displayed operation details, optionally pass additional authentication and confirm the operation; * The AS issues a one-time credential (let's call it "confirmation token") that can be used to perform that particular operation only; * Finally, the user performs the operation.
Is this case completely covered by the current standards? I believe it is not, and here are my points: 1. "Confirmation token" looks very different from access token with regards to its contents, purpose, scope, lifetime and lifecycle. I think it should complement the access token rather than replace it, even temporarily. This is why I believe this case is not covered by Step Up, where the access token is replaced; 1a. Step Up assumes upgrading the session's ACR; in the "confirmation" scenario, ACR could remain unchanged; 2. No standard way for the RS to signal to the client that the requested operation requires confirmation. That could optionally include server-supplied nonce (similar to DPoP) to help enforce "confirmation token"'s shorter lifetime and one-time use, but it is not clear how to communicate that to the client; 3. No standard way for the client to request one-time "confirmation token" from the AS; 4. No standard way for the AS to indicate that the returned token is actually "confirmation token" and not a Bearer token; 5. No standard way for the RS to tell that the incoming token is actually a "confirmation token" and requires special handling (one-time use, checking against operation parameters etc.) 6. On a plus side, RAR can be used to communicate operation details to the AS while initiating "confirmation". 3-5 could be probably done with a combination of scopes + RAR. What concerns me most is the lack of complementary token semantics (1) and inability for the RS to signal the confirmation requirement to the client (2), which could include operation details and nonce. Please correct me if I'm missing something and we have enough coverage by the standards. But if we don't, would the WG welcome such a document? Dmitry Telegin Backbase / Keycloak
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
