On Wed, Mar 1, 2023 at 5:04 AM Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> wrote:
Hi,
>>>> QMa1: General
>>>>
>>>> As the document defines a new error code, and define new
>>>> WWW-Authenticate parameters, should the document not be an Update to
>>>> RFC 6750?
>>>>
>>> It's a good point to consider. Our rationale is that this document
>>> leverages
>>> many different extension points baked in a number of existing specs, hence
>>> it doesn't seem a slam dunk to determine which one we should "inherit"
>>> from.
>>
>> Since the draft refers to RFC 6750 I would assume that is the spec at least
>>being updated.
>>
>>But, if the draft also updates procedures etc of other specs I guess those
>>may
>>also be updated. I don't have the expertise to have an opinion on whether
>>that
>>is the case.
>
> The thrust there wasn't to suggest that this draft needs to update other
> specs. Rather to say that this draft utilizes defined extension points
> provided by a number of RFCs (like RFC6749, RFC6750, RFC7662, RFC7519) and
> the associated registries where appropriate/needed. Those extension points
> have been used by other specs already without the spec doing the extension
> formally updating the RFC that it's using the extension points of.
>
> More generally, our rationale and attempt to follow precedent here was that
> the utilization of defined extension points didn't warrant "Updates" to the
> specs providing those extension points.
Fair enough.
I do agree that, in other protocols, defining new error codes etc do now
always mean updating of specs.
---
>>>> QMa2: Section 4
>>>>
>>>> The text defines the procedures for the client.
>>>>
>>>> But, what if the client does not support the new error code and the
>>>> new
>>>> WWW-A parameters? I think there should be some backward compatibility
>>>> text (or reference, if defined elsewhere).
>>>>
>>>> Especially it should be clear that the server will not receive the
>>>> WWW-A
>>>> parameters in the new request if the client does not support them.
>>>
>>> This is a tricky one. Technically, every extension starts its existence
>>> with
>>> zero support from existing clients.
>>>
>> Yes, and I have been in many situations where people argue on what is the
>> correct behavior when one endpoint supports an extension, the other
>> doesn't,
>> and there are no defined backward compatibility procedures to refer to :)
>>
>>> Implementers should be familiar with this, and specs stipulate that any
>>> entity receiving a parameter it doesn't understand to ignore that
>>> parameter,
>>> from which it follows that whatever semantic or directive that parameter
>>> carries will remain not executed.
>>> Saying in the document that clients not supporting the parameters we are
>>> defining here will not achieve the goals of the spec seem somewhat
>>> redundant. What do you think?
>>
>>I think it is more than just "not achieving the goals". Clients that do not
>>support the extension may end up not getting any service at all, as they
>>don't
>>understand that the reason for rejection is not meeting the authentication
>>requirements.
>
> Yes, clients that do not support the extension will not understand the new
> error code and auth-params and won't know to act accordingly. That is the
> nature of these
> kinds of extension points. This draft can't change how the underlying specs
> expose extensions (and I honestly wouldn't know how to do it differently
> even if it could).
> Of course, existing software that is unaware of this draft can't have any
> behavior dictated by this draft. For the case where an entity doesn't
> support the extension,
> I don't see how this document could say anything meaningful about
> compatibility. Other than to remark or reiterate that an entity that doesn't
> understand the extension
> will not understand it, which seems neither actionable nor useful in the
> document. Honestly, what language would we even use here?
I was thinking of e.g., a note that highlights the issue.
But, I do agree it should be obvious to people familiar with the specs, so if
you don't think it is needed I will not argue against you :)
I assume there will be no indicator in the initial request informing the
server whether the client supports the feature or not?
Correct, there's no such indicator. I don't think it would help the situation either - the resource server would still deny the request just with a 'traditional' error code and less information about why it was denied. And using such an indicator as input to access control decisions would be introducing security issues, which we definitely don't want.
----
Minor issues:
>>>> QMi1: Section 3
>>>>
>>>> Can the new WWW-Authenticate parameters only be used with the new
>>>> error
>>>> code? If so, please indicate it.
>>> There doesn't seem to be any obvious reasons to ban future extensions from
>>> using those parameters, nor there appear to be obvious scenarios where we
>>> would proactively
>>> suggest doing so: that's our rationale for not having commented on this
>>> aspect in the document.
>>
>> One alternative would be to not ban, but to say that THIS spec only defines
>> usage of the parameters with the new error code, but that future specs may
>> define usage with other error codes.
>
> That seems like a worthwhile clarification to make. Thanks. We will
> add/adjust some text accordingly.
Thanks!
Regards,
Christer
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
