If the phone is compromised, it doesn’t matter if the client is public or
confidential. In the latter case, an attacker could exfiltrate or capture the
client’s own credentials and use them maliciously.
— Justin
On Sep 10, 2019, at 3:27 PM, Masakazu OHTSUKA
mailto:o.masak...@gmail.com>> wrote:
Okay,
Marius, Filip and Nat, thank you for your answers. :)
On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura wrote:
> As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if
> that is used within the dynamic client registration, it could be more
> secure.
>
> The security assumptio
As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if that
is used within the dynamic client registration, it could be more secure.
The security assumptions are
1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.
Nat Sakimura
Chairman, Open
I see.
Then is this understandable to think from the Authorization Server's point
of view ...
If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authentication, and
have som
A claimed HTTPS URI would tho, right?
Odesláno z iPhonu
10. 9. 2019 v 19:22, Marius Scurtescu
:
> If the phone is compromised, original app replaced by malicious app, then
> RFC8252 will not help. The assumption is that the phone is not compromised.
>
>> On Tue, Sep 10, 2019 at 9:58 AM Masaka
If the phone is compromised, original app replaced by malicious app, then
RFC8252 will not help. The assumption is that the phone is not compromised.
On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA
wrote:
> Hi,
>
> I've read rfc8252 and have questions about native apps, that I couldn't
> find a
