[OAUTH-WG] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

[Amanda Baber via RT]

Hi Hannes,

Can you sign off on this revision? This on on Thursday's IESG telechat agenda.

thanks,
Amanda

On Thu Dec 08 21:53:58 2022, bcampb...@pingidentity.com wrote:
> Thanks for catching that Hannes. I believe you are correct that a
> copy-and-paste error went unnoticed. I have fixed the glitch with a
> draft
> -18 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-18
> 
> On Thu, Dec 8, 2022 at 4:16 AM Hannes Tschofenig
> 
> wrote:
> 
> > Hi all,
> >
> > Thanks for the email, Amanda.
> >
> > I review the IANA consideration request. Only the OAuth Extension
> > Error
> > registration in Section 15.6 of
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar#name-iana-
> > considerations
> > requires some changes.
> > The other, OAuth-related registry entries, are fine.
> >
> > Here is what the text says for Section 15.6:
> > --
> > 15.6. OAuth Extensions Error registry
> >
> > This specification requests registration of the following value in
> > the
> > IANA "OAuth Extensions Error registry" registry of
> > [IANA.OAuth.Parameters]
> > established by [RFC6749].
> >
> > Metadata Name:
> > invalid_authorization_details
> > Metadata Description:
> > indicates invalid authorization_details_parameter to the client.
> > Change Controller:
> > IETF
> > Specification Document(s):
> > Section 5 of [[ this document ]]
> > --
> >
> > The OAuth Extensions Error registry requires the following
> > information to
> > be provided, see
> >
> > https://www.iana.org/assignments/oauth-parameters/oauth-
> > parameters.xhtml#extensions-error
> >
> > Name:
> > Usage Location:
> > Protocol Extension:
> > Change Controller:
> > Reference:
> >
> > I assume that this is the result of a copy-and-paste error that got
> > unnoticed.
> > I suspect the authors can quickly fix this glitch.
> >
> > Ciao
> > Hannes
> >
> >
> >
> > -Original Message-
> > From: OAuth  On Behalf Of Amanda Baber via RT
> > Sent: Tuesday, December 6, 2022 3:18 AM
> > Cc: oauth@ietf.org; drafts-expert-review-comm...@iana.org;
> > oauth-ext-rev...@ietf.org
> > Subject: [OAUTH-WG] [IANA #1261154] expert review for draft-ietf-
> > oauth-rar
> > (OAuth Parameters - OAuth Extensions Error)
> >
> > Hi Hannes (cc: oauth wg),
> >
> > Have you had a chance to review the registrations for this document?
> > This
> > is listed on the IESG telechat agenda for the 15th.
> >
> > thanks,
> > Amanda
> >
> > On Thu Nov 17 18:09:19 2022, sabrina.tanamal wrote:
> > > Hi Hannes (cc: oauth wg),
> > >
> > > As the designated expert for the OAuth Parameters and OAuth
> > > Extensions
> > > Error registries, can you review the proposed registrations in
> > > draft-
> > > ietf-oauth-rar for us? Please see
> > >
> > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar
> > >
> > > The due date is December 1st.
> > >
> > > If this is OK, when the IESG approves the document for publication,
> > > we'll make the registrations at
> > >
> > > https://www.iana.org/assignments/oauth-parameters
> > >
> > > thanks,
> > >
> > > Sabrina Tanamal
> > > Lead IANA Services Specialist
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose
> > the
> > contents to any other person, use it for any purpose, or store or
> > copy the
> > information in any medium. Thank you.
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Justin Richer]

Apologies, sending from the correct email account this time. Please do not 
reply to the other address.

Thank you,
 — Justin

On Dec 12, 2022, at 1:45 PM, Justin Richer 
mailto:jus...@richer.org>> wrote:

Francesca,

Thanks for the pointer! I read through the referenced RFC as well and I agree 
with Brian’s take. I don’t think there’s enough similarity in the domain or the 
solution to warrant a meaningful comparison here. It seems that RFC9237 was not 
written in such a way as for it to be generally applicable, and that seems to 
be the intentional design. Section 2.2 of that document specifically states 
that it’s limited in a number of ways, such as the statement that it’s for 
"statically identifiable objects”. These limitations seem to put it in a 
squarely different camp from RAR, which is intended to allow expression of 
general-purpose security elements across many different styles of APIs. The 
various examples in the RAR draft should, hopefully, make that clear.

I personally think that mentioning RFC9237 would only confuse readers of this 
specification.

 — Justin

On Dec 12, 2022, at 1:22 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks Francesca,

I must admit that I was not aware of RFC9237. After a quick look, however, it 
really is intended for Ace and IoT (as you point out) and I don't believe I 
could write anything sufficiently meaningful about any similarities to this 
document to warrant inclusion.

On Mon, Dec 12, 2022 at 9:10 AM Francesca Palombini via Datatracker 
mailto:nore...@ietf.org>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-rar-18: 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:
--

Thank you for the work on this document.

Many thanks to Thomas Fossati for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/EckO_3zF-gnI83Q_HmO5xREursI/ and
thanks to the authors for addressing Thomas' comments.

No other comments from me, just a note: I was wondering if it wouldn't have
made sense to informally reference and discuss in a short paragraph RFC9237 and
its applicability to OAuth given its content - I will accept that it might not
be the case since 9237 is really intended for Ace and IoT but the similarities
made me question it.

Francesca




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

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Brian Campbell]

-19 has those changes.

On Mon, Dec 12, 2022 at 10:23 AM Brian Campbell 
wrote:

> Thank you for the review and ballot Lars. I believe we can easily
> incorporate those suggestions.
>
>
>
>
> On Mon, Dec 12, 2022 at 7:14 AM Lars Eggert via Datatracker <
> nore...@ietf.org> wrote:
>
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-oauth-rar-18: 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:
>> --
>>
>> # GEN AD review of draft-ietf-oauth-rar-18
>>
>> CC @larseggert
>>
>> Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
>> (
>> https://mailarchive.ietf.org/arch/msg/gen-art/shFcI11Wajhydi8wJuFM3VaVfkI
>> ).
>>
>> ## Comments
>>
>> ### Inclusive language
>>
>> Found terminology that should be reviewed for inclusivity; see
>> https://www.rfc-editor.org/part2/#inclusive_language for background and
>> more
>> guidance:
>>
>>  * Terms `her` and `his`; alternatives might be `they`, `them`, `their`
>>
>> ## Nits
>>
>> All comments below are about very minor potential issues that you may
>> choose to
>> address in some way - or ignore - as you see fit. Some were flagged by
>> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
>> there
>> will likely be some false positives. There is no need to let me know what
>> you
>> did with these suggestions.
>>
>> ### URLs
>>
>> These URLs in the document did not return content:
>>
>>  * https://taxservice.govehub.no
>>  * http://hl7.org/fhir/organization-type
>>  * http://example.info/claims/groups
>>
>> I guess these are supposed to be example URLs. Please use the
>> designated example domain names for this.
>>
>> ### Grammar/style
>>
>>  Section 2.1, paragraph 1
>> ```
>> fication does not require the use of any of these common fields by an API
>> def
>>   ^
>> ```
>> Consider simply using "of" instead.
>>
>>  Section 3, paragraph 6
>> ```
>>  if any of the following are true of any of the objects in
>> authorization_deta
>>   ^
>> ```
>> Consider simply using "of" instead.
>>
>>  Section 3, paragraph 10
>> ```
>> ke security decisions based on whether or not the request is asking for
>> "mor
>>^^
>> ```
>> Consider shortening this phrase to just "whether". It is correct though
>> if you
>> mean "regardless of whether".
>>
>>  Section 7, paragraph 6
>> ```
>>  Token Error Response MUST conform the the rules given in Section 5. 9.
>> Reso
>>^^^
>> ```
>> Possible typo: you repeated a word.
>>
>>  Section 16, paragraph 7
>> ```
>> * tax_payer_id: identifier of the tax payer (if known to the client) A.4.
>> eH
>>   ^
>> ```
>> This word is normally spelled as one.
>>
>> ## Notes
>>
>> This review is in the ["IETF Comments" Markdown format][ICMF], You can
>> use the
>> [`ietf-comments` tool][ICT] to automatically convert this review into
>> individual GitHub issues. Review generated by the
>> [`ietf-reviewtool`][IRT].
>>
>> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>> [ICT]: https://github.com/mnot/ietf-comments
>> [IRT]: https://github.com/larseggert/ietf-reviewtool
>>
>>
>>
>> ___
>> 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

[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-19.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
  Filename: draft-ietf-oauth-rar-19.txt
  Pages   : 45
  Date: 2022-12-12

Abstract:
   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-19.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-rar-19


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Brian Campbell]

Thanks Francesca,

I must admit that I was not aware of RFC9237. After a quick look, however,
it really is intended for Ace and IoT (as you point out) and I don't
believe I could write anything sufficiently meaningful about any
similarities to this document to warrant inclusion.

On Mon, Dec 12, 2022 at 9:10 AM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-oauth-rar-18: 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:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Thomas Fossati for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/EckO_3zF-gnI83Q_HmO5xREursI/ and
> thanks to the authors for addressing Thomas' comments.
>
> No other comments from me, just a note: I was wondering if it wouldn't have
> made sense to informally reference and discuss in a short paragraph
> RFC9237 and
> its applicability to OAuth given its content - I will accept that it might
> not
> be the case since 9237 is really intended for Ace and IoT but the
> similarities
> made me question it.
>
> Francesca
>
>
>
>

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

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Brian Campbell]

Thank you for the review and ballot Lars. I believe we can easily
incorporate those suggestions.




On Mon, Dec 12, 2022 at 7:14 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-oauth-rar-18: 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:
> --
>
> # GEN AD review of draft-ietf-oauth-rar-18
>
> CC @larseggert
>
> Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/shFcI11Wajhydi8wJuFM3VaVfkI
> ).
>
> ## Comments
>
> ### Inclusive language
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Terms `her` and `his`; alternatives might be `they`, `them`, `their`
>
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### URLs
>
> These URLs in the document did not return content:
>
>  * https://taxservice.govehub.no
>  * http://hl7.org/fhir/organization-type
>  * http://example.info/claims/groups
>
> I guess these are supposed to be example URLs. Please use the
> designated example domain names for this.
>
> ### Grammar/style
>
>  Section 2.1, paragraph 1
> ```
> fication does not require the use of any of these common fields by an API
> def
>   ^
> ```
> Consider simply using "of" instead.
>
>  Section 3, paragraph 6
> ```
>  if any of the following are true of any of the objects in
> authorization_deta
>   ^
> ```
> Consider simply using "of" instead.
>
>  Section 3, paragraph 10
> ```
> ke security decisions based on whether or not the request is asking for
> "mor
>^^
> ```
> Consider shortening this phrase to just "whether". It is correct though if
> you
> mean "regardless of whether".
>
>  Section 7, paragraph 6
> ```
>  Token Error Response MUST conform the the rules given in Section 5. 9.
> Reso
>^^^
> ```
> Possible typo: you repeated a word.
>
>  Section 16, paragraph 7
> ```
> * tax_payer_id: identifier of the tax payer (if known to the client) A.4.
> eH
>   ^
> ```
> This word is normally spelled as one.
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
>
>
> ___
> 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

[OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-rar-18: 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:
--

Thank you for the work on this document.

Many thanks to Thomas Fossati for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/EckO_3zF-gnI83Q_HmO5xREursI/ and
thanks to the authors for addressing Thomas' comments.

No other comments from me, just a note: I was wondering if it wouldn't have
made sense to informally reference and discuss in a short paragraph RFC9237 and
its applicability to OAuth given its content - I will accept that it might not
be the case since 9237 is really intended for Ace and IoT but the similarities
made me question it.

Francesca



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-oauth-rar-18: 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:
--

# GEN AD review of draft-ietf-oauth-rar-18

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/shFcI11Wajhydi8wJuFM3VaVfkI).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms `her` and `his`; alternatives might be `they`, `them`, `their`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### URLs

These URLs in the document did not return content:

 * https://taxservice.govehub.no
 * http://hl7.org/fhir/organization-type
 * http://example.info/claims/groups

I guess these are supposed to be example URLs. Please use the
designated example domain names for this.

### Grammar/style

 Section 2.1, paragraph 1
```
fication does not require the use of any of these common fields by an API def
  ^
```
Consider simply using "of" instead.

 Section 3, paragraph 6
```
 if any of the following are true of any of the objects in authorization_deta
  ^
```
Consider simply using "of" instead.

 Section 3, paragraph 10
```
ke security decisions based on whether or not the request is asking for "mor
   ^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

 Section 7, paragraph 6
```
 Token Error Response MUST conform the the rules given in Section 5. 9. Reso
   ^^^
```
Possible typo: you repeated a word.

 Section 16, paragraph 7
```
* tax_payer_id: identifier of the tax payer (if known to the client) A.4. eH
  ^
```
This word is normally spelled as one.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Last-Call] [Gen-art] Genart last call review of draft-ietf-oauth-rar-15

[Lars Eggert]

Robert, thank you for your review and thank you all for the following 
discussion. I have entered a No Objection ballot for this document.

Lars


> On Nov 18, 2022, at 00:45, Robert Sparks  wrote:
> 
> 
> On 11/17/22 4:44 PM, Robert Sparks wrote:
>> Apologies - an upload fumble left -00 empty. I've revised it to have content 
>> at -01.
> 
> Which I'll also paste here for convenience:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-oauth-rar-14 (<- that was a typo - I really did review 
> 15)
> Reviewer: Robert Sparks
> Review Date: 2022-11-17
> IETF LC End Date: 2022-11-17
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues: Essentially ready for publication as a Proposed Standard RFC, 
> but with issues to discuss before publication
> 
> I have two major issues that I think need discussion:
> 
> Major Issue 1) The document seems to be specifying a new way of comparing 
> json names, claiming it is what RFC8259 requires, but I disagree that RFC8259 
> says what this document is claiming. If I'm correct, the document is trying 
> to rely on the text in section 7 of RFC8259 to support the idea that 
> implementation MUST NOT alter the json names (such as applying Unicode 
> normalization) before comparison and that the comparison MUST be performed 
> octet-by-octet. Rather, section 7 says something more like "you better escape 
> and unescape stuff correctly if you’re going to do unicode codepoint by 
> codepoint comparison" which is a completely different statement.
> 
> If I'm right, and this is a new comparison rule that goes beyond what JSON 
> itself defines, I think the group should seek extra guidance from Unicode 
> experts. If I'm wrong and this behavior is defined somewhere else, please 
> provide a better pointer to the definition.
> 
> In many environments, its unusual for an implementation relying on a stack 
> below it to have any say at all on whether normalization is going to be 
> applied to the unicode before the application gets to look. Rather than 
> trying to work around the problem you've identified with normalization by 
> specifying the comparison algorithm, consider just making stronger statements 
> about the strings used in the json names the document defines. Why _can't_ 
> you restrict the authorization_details values to ascii? If it's because you 
> want to present the string to a user, consider putting a presentation string 
> elsewhere in the json that is not used for comparison.
> 
> Major Issue 2) The suggested pattern demonstrated starting in figure 16 
> (using [] to mean "let the user choose") seems underspecified. If the point 
> is that different APIs may invent different mechanics _like_ this, and that 
> this is only an example. Make it much clearer that this is an example. If 
> this is a pattern you expect all APIs to follow, then more description is 
> warranted. Is it intended that a user could add and remove things arbitrarily 
> to such lists? For instance is it intended that this support an interaction 
> where the client is asking for permission to operate on account A, and the 
> user can say "no, but you can operate on account B"?
> 
> Minor issues:
> 
> Section 2: What does "The AS MUST ensure that there is no collision between 
> different authorization details types that it supports." mean? How is this a 
> 2119 requirement? I _think_ you're trying to point out that the 
> authorization_details string is a unique-key at any AS and that that has 
> consequences on the API _designer_, but I don't know what is expected of an 
> AS coder here. Some clearer words are needed.
> 
> Section 7: Please expand on, or rephrase, "if these are deemed of no intended 
> use for the client." Could you just delete the phrase? If you are only 
> explaining why an AS might do this, make it clear that it's an example (and 
> split the example into a separate sentence). If this is the _only_ reason an 
> AS might omit values in the token Response, then more detail is needed.
> 
> 
> Nits/editorial comments:
> 
> Throughout the document, there is a mix of "authorization_details" and 
> "authorization details". It is not completely consistent using one when 
> talking about the parameter and the other when talking about the general 
> concept of details about authorization. Please inspect each occurrence and 
> verify that it is using the correct form.
> 
> Introduction: suggest changing 'defines the parameter scope' to 'defines the 
> parameter "scope"'
> 
> Introduction just after figure 1 - expand AS (first use).
> 
> Section 2.2: Please rework the sentence where you mention "the cartesian 
> product" and remove the