Hi Denis, I think I'd agree on most points. As far as I understand, your major concern is that the details of the operation to be confirmed will be exposed to the AS. And this is exactly what is addressed in 3DS, where neither merchant can spy on card/account number, nor AS on the transaction details.
I forgot to mention that I was describing the first-party AS scenario, where the AS, client and RS are provided by the same party, and the trust between the components is already established. I believe in the cases like that we can make exceptions, similar to Aaron's OAuth 2.0 for First-Party Applications, where it is considered safe to expose user's credentials to trusted clients. I wonder if we could abstract from payment confirmations and focus on the general-purpose semantics of auxiliary/secondary/complimentary one-time tokens? Dmitry On Fri, Jun 14, 2024 at 9:19 AM Denis <denis.i...@free.fr> wrote: > Hi Dmitry, > > You have described a scheme with built-in "spy by design" opportunities, > where the AS will be in a position to play the role of "Big Brother". > If you follow a "privacy by design" approach, you will end up with a > different architecture. > > “If the only tool you have is a hammer, you tend to see every problem as > a nail.” > OAuth should not be considered to be the only tool. > > 3D Secure is a way to address payment / money transfers in a > privacy-preserving fashion. > > FYI, the SPICE WG has been created yesterday. A privacy-preserving > architecture using digital credentials will be developed there. > > Denis > > > > 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 > > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
