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 though?
FWIW, https://datatracker.ietf.org/doc/html/rfc7235#section-4.1 does say "the [WWW-Authenticate] header field itself can occur multiple times." On Wed, Aug 11, 2021 at 3:03 PM Dmitry Telegin <dmitryt= 40backbase....@dmarc.ietf.org> 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 > should advertise both schemes when challenging user agents with > WWW-Authenticate? > > The HTTP 1.1 Authentication spec, section 4.1 > <https://datatracker.ietf.org/doc/html/rfc7235#section-4.1> does allow > for multiple challenges sent as a single WWW-Authenticate header, for > example: > > WWW-Authenticate: Newauth realm="apps", type=1, > title="Login to \"apps\"", Basic realm="simple" > > which in our case would look like this: > > WWW-Authenticate: DPoP realm="WallyWorld", algs="ES256 PS256", > Basic realm="WallyWorld" > > or, in the case of error, > > WWW-Authenticate: DPoP realm="WallyWorld", error="invalid_token", > error_description="Invalid DPoP key binding", algs="ES256", > Basic realm="WallyWorld" > > > The HTTP 1.1 spec, section 4.2 > <https://www.rfc-editor.org/rfc/rfc2616.html#section-4.2> also allows for > multiple headers with the same name, but only under very strict conditions; > I'm not yet sure if those apply to WWW-Authenticate. > > Is this worth mentioning in the DPoP spec? > > Regards, > Dmitry > > On Tue, Aug 10, 2021 at 12:58 AM Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org> wrote: > >> 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 >> straightforward way to accommodate it in the document. I'll look to add >> that, probably somewhere in section 7 >> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html#name-protected-resource-access>, >> in the next draft revision. >> >> >> On Thu, Aug 5, 2021 at 8:50 AM Dmitry Telegin <dmitryt= >> 40backbase....@dmarc.ietf.org> wrote: >> >>> 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 use error="invalid_dpop_proof", similar to token request? or maybe >>> even 400 Bad Request? >>> >>> Regards, >>> Dmitry >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
