client, the
issue is merely shifted from the client-OAuth server to the client-Remote
Assertion Server, which is the same scenario.
Best Regards.
From: Jaimandeep Singh
mailto:40nfsu.ac...@dmarc.ietf.org>>
Date: Sunday, 26 February 2023 at 17:05
To: "Oliva Fernandez, Jorge"
ot;Remote Assertion Server", this cause the attacker to generate as many
> assertions as they require, this is precisely a client impersonation
> attack…. therefore, with the "Remote Assertion Server," unless a magical
> solution is proposed to ensure the identity of a public cli
Best Regards.
From: Jaimandeep Singh
Date: Sunday, 26 February 2023 at 17:05
To: "Oliva Fernandez, Jorge"
Cc: oauth
Subject: [EXT]Re: [OAUTH-WG] Unified Singular Protocol Flow for OAuth (USPFO)
Ecosystem
CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly
with
the remote assertion
>server. When the client is of type 'confidential' and can keep a
>secret/private key using just the private_key_jwt method or the
>tls_client_auth, it solves the problem. However, for public clients, you
>will have exactly the same problem us
Dear Rifaat and esteemed community members,
I am pleased to share my research paper on 'Unified Singular Protocol Flow
for OAuth (USPFO) Ecosystem'. The highlights of the paper are:
1. Separation of Duties (SoD) - Delegates responsibility of authenticating
client applications to a third-party en
