Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

[Vittorio Bertocci <[e-mail]>]

Hi Murray,
Thank you for your comments! Answers inline

>   My co-AD pretty much nailed it.   I would go further and say that her comment
>    about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here. 
>    SHOULD presents a choice; why might an implementer reasonably not do any of the
>    SHOULD things in here?
In line of principle, I agree- but that's where the consensus brought us. Many of the SHOULD you see in the current draft actually started as MUST, and the discussion drove toward them being relaxed. The technology we are trying to standardize here has been in production use for many years, hence there's a wealth of real world scenarios that influenced the debate.
For a more precise discussion, we should select specific instances: but for an example of typical circumstances that led toward SHOULD, the case discussed with Francesca is pretty typical.

>For readability, I suggest that the three registrations packed into Section
 >   7.2.1 be separated somehow, as right now they appear to be one continuous
 >   bullet list.  Separate subsections would work, or even just a line of prose
 >   before each would suffice.
Great suggestion, thank you! I added sections for improved readability.

>    The first half of the second paragraph of Section 6 seems much more like an
>    interoperability issue than a privacy issue to me.
I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. I would argue it is not about interop either, given that noncompliance with the guidance given there doesn’t impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have for that guidance, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy concern; the decision to use a JWT ATs, which ultimately makes spelling out the guidance necessary, is influenced by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, I am inclined to leave that part as is.   


On 4/7/21, 23:22, "Murray Kucherawy via Datatracker" <[e-mail]> wrote:

    Murray Kucherawy has entered the following ballot position for
    draft-ietf-oauth-access-token-jwt-12: 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/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    My co-AD pretty much nailed it.   I would go further and say that her comment
    about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here. 
    SHOULD presents a choice; why might an implementer reasonably not do any of the
    SHOULD things in here?
    
    For readability, I suggest that the three registrations packed into Section
    7.2.1 be separated somehow, as right now they appear to be one continuous
    bullet list.  Separate subsections would work, or even just a line of prose
    before each would suffice.
    
    The first half of the second paragraph of Section 6 seems much more like an
    interoperability issue than a privacy issue to me.