Subject: [OAUTH-WG] Francesca Palombini's Discuss on draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Mon, 29 Nov 2021 13:21:28 -0800

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-iss-auth-resp-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document.

Many thanks to Julian Reschke for the ART ART review:
https://mailarchive.ietf.org/arch/msg/art/XfLbtK1eLb7s0Z6e_AqGgkoWny0/.

I have one DISCUSS point that has to do with IANA considerations, and is
hopefully easy to resolve.

Francesca

1. -----

FP: I am sure the Designated Expert will bring this up, but "iss" is already
defined as a OAuth Parameter, for authorization requests. I don't think it's a
good idea to use the same parameter name, although in a different message of
the exchange, for something different, as the registration defined in Section
5.2 seems to imply. I strongly recommend to change the name in this document.
Or, if we can agree that the meaning is similar enough to the original "iss",
merge the two IANA registrations (this would not be my preferred choice).

---

From: Warren Parad <[email-masked]>
Date: Tue, 30 Nov 2021 11:33:15 +0100

The use of *iss* is correct here, and while it could be changed it isn't
clear why it should be. Given the current parameter registry format, it
should be merged.

I think the source of the issue is that the format of the registry is
confusing (at least for me), I would prefer to see it organized by usage
location, not by parameter name and then this wouldn't be an issue. But
that's not up for discussion, right?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Mon, Nov 29, 2021 at 10:21 PM Francesca Palombini via Datatracker <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 30 Nov 2021 11:31:43 -0700

I strongly believe the use of 'iss' as the parameter name here is correct
and appropriate. This draft isn't using it for something different - the
parameter carries an identifier for the sender of the message, which is
consistent in the context of use with the existing registry entry.

Codifying the parameter name is central to the value of this draft and
there are existing implementations/deployments using it. Changing the name
now would be a breaking change with significant ramifications on
interoperability.

The organization of the registry is arguably less than ideal, yes. But that
shouldn't force an unnecessary and costly change onto this simple draft
that's addressing a real need. This draft should update the existing entry
for 'iss' rather than replace it.

-- 
_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._

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 30 Nov 2021 18:42:56 +0000

Hi Warren, Brian,

Thanks for your feedback, and for confirming that the semantics of the existing “iss” match those of the draft. In that case, I agree with you that the best resolution is to merge the two (so – update the existing registration so that it also points to this document, and indicates it can also appear in the authorization response).

I’ll remove my DISCUSS when the IANA update is done.

Thanks,
Francesca

From: Brian Campbell <[email-masked]>
Date: Tuesday, 30 November 2021 at 19:32
To: Francesca Palombini <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [OAUTH-WG] Francesca Palombini's Discuss on draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)
I strongly believe the use of 'iss' as the parameter name here is correct and appropriate. This draft isn't using it for something different - the parameter carries an identifier for the sender of the message, which is consistent in the context of use with the existing registry entry.

Codifying the parameter name is central to the value of this draft and there are existing implementations/deployments using it. Changing the name now would be a breaking change with significant ramifications on interoperability.

The organization of the registry is arguably less than ideal, yes. But that shouldn't force an unnecessary and costly change onto this simple draft that's addressing a real need. This draft should update the existing entry for 'iss' rather than replace it.

On Mon, Nov 29, 2021 at 2:21 PM Francesca Palombini via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-iss-auth-resp-03: Discuss

Francesca

1. -----

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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.