[OAUTH-WG] Re: One-time confirmation tokens

[Denis <[e-mail]>]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]