On 14 Jun 2024, at 02:48, Dmitry Telegin <dmitryt=40backbase....@dmarc.ietf.org> wrote: > > 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?
You may be interested in my blog post about exactly this topic: https://neilmadden.blog/2020/09/09/macaroon-access-tokens-for-oauth-part-2-transactional-auth/ <https://neilmadden.blog/2020/09/09/macaroon-access-tokens-for-oauth-part-2-transactional-auth/> However, I think the ship has pretty much sailed on this topic and the world (Open Banking etc) has gone with just using RAR for each transaction and glossing over the points you make. — Neil
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
