Hi Brian,
Just wondering if there's still a chance for this to be addressed in 04? I
could try preparing a draft PR if that helps.
On a related note, are there any recommendations on the contents of the
"error_description" WWW-Authenticate attribute? For example, our prototype
DPoP implementation
On Thu, Aug 12, 2021 at 05:05:03PM -0600, Brian Campbell wrote:
> Indeed but this case would be only distinguishing between which of the two
> things (token & proof) the client sent was invalid. It seems like a
> reasonable amount of information to disclose that might be helpful in
> troubleshootin
Indeed but this case would be only distinguishing between which of the two
things (token & proof) the client sent was invalid. It seems like a
reasonable amount of information to disclose that might be helpful in
troubleshooting while not giving actionable info to would-be attackers.
On Thu, Aug 1
It's not immediately obvious to me that making the distinction is good (but
I'm also basically devoid of the context in which this exchange will
occur).
With security protocols there can be risks from overly descriptive errors,
which might (e.g.) leak information that "this is a valid token" vs "t
On Thu, Aug 12, 2021 at 02:17:24PM -0600, Brian Campbell wrote:
> It might be worth a mention but I'm always a little hesitant about
> potentially repeating content from other specs (and maybe even getting it
> wrong!). Maybe a very brief mention along with a pointer to that section in
> RFC 7235 w
It might be worth a mention but I'm always a little hesitant about
potentially repeating content from other specs (and maybe even getting it
wrong!). Maybe a very brief mention along with a pointer to that section in
RFC 7235 would be appropriate? I'm curious what other WG folk think about
this tho
Sorry, "Basic" should be "Bearer" obviously.
Dmitry
On Thu, Aug 12, 2021 at 12:02 AM Dmitry Telegin
wrote:
> Hi Brian, thanks for the response,
>
> On a related note, chapter 7.2 allows for protected resources supporting
> Bearer and DPoP schemes simultaneously. Is it implied that such resources
Hi Brian, thanks for the response,
On a related note, chapter 7.2 allows for protected resources supporting
Bearer and DPoP schemes simultaneously. Is it implied that such resources
should advertise both schemes when challenging user agents with
WWW-Authenticate?
The HTTP 1.1 Authentication spec,
Hi Dmitry,
I think you are right that it's probably worthwhile to allow for a
distinction in a protected resource error response. I'm inclined to say
that a new error code such as "invalid_dpop_proof" to use with the 401
response containing the DPoP WWW-Authenticate header is the most
straightforw
Hello,
When a protected resource is accessed using DPoP proof + DPoP-bound access
token, either of those could be invalid. Should we make distinction between
these two cases? I.e. should the response always be a 401 Unauthorized with
WWW-Authenticate: DPoP ... error="invalid_token"? or could we us
10 matches
Mail list logo
