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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
