On 02/04/2019 17:35, Brian Campbell wrote:
Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS. Which is
what it is.
A quick nit:
i
I think it's fair to call it out (either in the paragraph here or in the
security considerations). The issue is that the security aspect of the
access token ending up in the browser is probably true in many contexts
other than SPAs:)
What about something like...
In this scenario, the backend
Thanks, this is a good question. I was talking with someone about this
draft the other day and had the same question myself. Re-reading RFC6749,
"public client" does describe only the limitation of the client protecting
its own credentials, so I think you're right that this paragraph is
misleading.
Hi,
In section 6.2 the following statement is made...
In this scenario, the backend component may be a confidential client
which is issued its own client secret. Despite this, there are still
some ways in which this application is effectively a public client,
as the end result is th
Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS. Which is what
it is.
On Thu, Mar 28, 2019, 6:32 AM Mike Jones wrote:
> Good observation, Lud
