Hi Murray, thanks for you review.
I updated the draft based on it and submitted -20 Here is the diff https://author-tools.ietf.org/iddiff?difftype=--hwdiff&url2=draft-ietf-oauth-rar-20.txt > Am 15.12.2022 um 09:34 schrieb Murray Kucherawy via Datatracker > <nore...@ietf.org>: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-oauth-rar-19: No Objection > > 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/about/groups/iesg/statements/handling-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-rar/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work put into this. Seems like it's in good shape. > > Thank you to Thomas Fossati for the ARTART review. > > "MUST consider" in Section 3.1 is curious. How does an implementation comply > with something like "consider"? Good point, what we want to get across is that the AS must not ignore any of the requirements defined in a scope or authorization details parameter if both are present in the authorisation request. Changed it to „process". > > Why is the "RECOMMENDED" in Section 9.1 not a MUST? The text in Section 9 > just > above it suggest something stronger. The AS is free to choose the format and representation of the data. It is not required to use the authorization details structure, it can transform and filter it. > > In Section 7.1, I can't understand what's meant by "This mechanic ...". Changed it to „This example“. best regards, Torsten. > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
