Hi Hannes,

First of all, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section.

Let us look at the following proposed sentence:

While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token     to the client. The access token is therefore, by design, considered to be opaque to the client".
/
In the context of this document/, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile (and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT. So, /in the context of this document/, the access token cannot be considered to be opaque to the client.

About the second paragraph, /in the context of this document (/besides the case where the JWT is encrypted), it is neither difficult,
nor impossible to parse the token/.
/
About the second paragraph, let us look at the following proposed sentence/in the context of this document/ :

" Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change
      the token format at any time ".

The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid /in the context of this document/. This JWT profile will be stable over time. This means that this quoted sentence is inappropriate /in the context of this document/.

The third proposed paragraph is stating :

"In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection       may provide a useful tool to enable such functionality (proper authorization assumed) ".

RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients. As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed
to be stable over time.

The last proposed paragraph is the following:

   " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement       to have access to any content received in form of claims, /for example through user consent in some form, policies and agreements with the organization running / /      the authorization servers, and so on/. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore
      outside the scope of this document ".

The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on" should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers.

The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence:

Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment
and therefore outside the scope of this document.

Finally, there are still two questions that have been raised but which have not yet been answered at this time:

 * how can a client request a JWT compliant to /this/ profile, and
 * how can a client be confident that it got a JWT compliant to /this/
   profile ?


Denis


Let me try to jump in here in order to make a proposal for the text in the privacy consideration section:

FROM:

*6*<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>*.  Privacy Considerations*

   As JWT access tokens carry information by value, it now becomes

   possible for requestors and receivers to directly peek inside the

   token claims collection.  The client MUST NOT inspect the content of

   the access token: the authorization server and the resource server

   might decide to change token format at any time (for example by

   switching from this profile to opaque tokens) hence any logic in the

   client relying on the ability to read the access token content would

   break without recourse. Nonetheless, authorization servers should

   not assume that clients will comply with the above.  Whenever client

   access to the access token content presents privacy issues for a

   given scenario, the authorization server should take explicit steps

   to prevent it as described below.

   In scenarios in which JWT access tokens are accessible to the end

   user, it should be evaluated whether the information can be accessed

   without privacy violations (for example, if an end user would simply

   access his or her own personal information) or if steps must be taken

   to enforce cofidentiality. Possible measures include: encrypting the

   access token, encrypting the sensitive claims, omitting the sensitive

   claims or not using this profile, falling back on opaque access

   tokens.

   In every scenario, the content of the JWT access token will

   eventually be accessible to the resource server.  It's important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on.

TO:

*6 <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>. Privacy Considerations*

   The design of OAuth 2.0 envisions that access tokens are created by

   authorization servers and consumed by resource servers.

   As JWT access tokens, as described in this document, carry information by value, it is

   possible for OAuth clients to peek inside the access token.

   While this is technical possible, it is important to note that the

   OAuth 2.0 protocol does not aim to expose the content of the

   access token to the client. The access token is therefore, by design, considered to be

   opaque to the client.

   A number of cases may make it difficult or impossible for clients to

   inspect the token, for example, the access token may be encrypted,

   the access token may contain vendor-specific claims that have not been

   standardized or have been standardized in other consortia making parsing

   of the token difficult. Additionally, there is no guarantee that the

   access token is conveyed by value and the authorization server implementation

   may change the token format at any time.

   In scenarios where it is desirable for the clients to obtain information

   transmitted in the access token, OAuth 2.0 token introspection may provide

   a useful tool to enable such functionality (proper authorization assumed).

   In scenarios where the content of the access token must not be readable

   by clients, encrypting the content of the access token is RECOMMENDED.

   Since the content of the access token is accessible to the resource server

   it is important to

   evaluate whether the resource server gained the proper entitlement to

   have access to any content received in form of claims, for example

   through user consent in some form, policies and agreements with the

   organization running the authorization servers, and so on. The policies

   and the user interfaces to enable this user consent are, however, part

   of a specific deployment and therefore outside the scope of this document.

How does this sound?

Ciao

Hannes

*From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Rifaat Shekh-Yusef
*Sent:* Thursday, May 14, 2020 8:03 PM
*To:* Denis <denis.i...@free.fr>
*Cc:* Vittorio Bertocci <vittorio.berto...@auth0.com>; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Denis,

You are rehashing the same issues that you have already discussed on the mailing list multiple times,

You could not get the WG to agree with your points, because the WG believe that this issue is outside the scope of this document.

The best the chairs can do at this stage is to capture your point in the shepherd write-up to the IESG.

We think this document has the support of the WG and is ready to move forward.

Regards,

 Rifaat

On Thu, May 14, 2020 at 12:29 PM Denis <denis.i...@free.fr <mailto:denis.i...@free.fr>> wrote:

    Hi Vittorio,

    I am referring to the email you sent on April the 29 th which is
    copied below.

    1) You wrote:

        /> targeting of access tokens/

        Let me think about that a bit longer.

        I acknowledge that the decision of including an audience has
        the effect of letting the AS track when the client accesses a
        particular resource,
        but at the same time that’s completely mainstream and very
        much by design in a very large number of cases. As such, I
        find the language
        you are suggesting to be potentially confusing, as it
        positions this as an exception vs a privacy protecting
        mainstream that is in fact not common,
        and ascribes to the client more latitude than I believe is
        legitimate to expect or grant.

        *I’ll try to come up with concise language that clarifies to
        the reader that the current mechanism does allow AS tracking*.

    Since the last draft has been published on the 27 th, you have not
    proposed any "concise language that clarifies to the reader
    that the current mechanism does allow AS tracking".

    2) You also wrote about the "sub" uniqueness:

        As long as an identifier identifies one resource only, it
        satisfies uniqueness. It doesn’t have to be a singleton.

    RFC 7519 defines in section 4.1.2 the semantics of the "sub" claim
    using the following sentence:

        The subject value MUST either be scoped to be locally unique
        in the context of the issuer or be globally unique.

    The text does NOT say that the subject value "MUST be scoped to be
    locally unique in the context of the *resource server*".

    Changing the semantics of an already defined claim is not
    permitted. If you would like to have such a semantics available,
    a new claim should be defined (and it would be very nice to have
    it !).

    3) The text is the privacy considerations section states:

       Although the ability to correlate requests might be required by
    design in many scenarios, there are scenarios where the authorization
       server might want to prevent correlation to preserve the
    desired level of privacy.

    In the real world, it is also clients or end-users which would
    like to prevent correlation to preserve their desired level of
    privacy.

    A better sentence would be:

       Although the ability to correlate requests might be required by
    design in many scenarios, there are scenarios where the authorization
       server *or the client* might want to prevent correlation to
    preserve the desired level of privacy.

    4) The text continues with:

       Authorization servers should choose how to assign "sub" values
    according to the level of privacy required by each
       situation.  For instance: if a solution requires preventing
    tracking  principal activities across multiple resource servers,
       the  authorization server should ensure that JWT access tokens
    meant for different resource servers have distinct "sub"
       values that cannot be correlated in the event of resource
    servers collusion.

    Authorization servers are not necessarily able to choose the level
    of privacy required by each situation. When there are different
    situations for the same resource server, the scope is
    (unfortunately at the moment) the only way to select the "level of
    privacy that is required".

    The example ("For instance:") is only an example that provides a
    vague recommendation for the ASs which is NOT conformant
    with the semantics of the "sub" claim as defined in RFC 7519.

    What should be discussed here are not "examples" or what an
    authorization server should do, but explanations about the
    implications
    for the end-user or for the client for the various values that can
    be placed into the "sub" claim by an AS. The problem is wider that
    simply
    a collusion between resource servers, but also with other servers
    that DO NOT participate in any OAuth exchange.

    RFC 6973 (Privacy Considerations) states in section 7 : Guidelines

        This section provides guidance for document authors in the
        form of a questionnaire about a protocol being designed.
        The questionnaire may be useful at any point in the design
        process, particularly after document authors have developed
        a high-level protocol model as described in [RFC4101].

    One of the questions is:

        f. *Correlation*.  Does the protocol allow for correlation of
        identifiers ? Are there expected ways that information exposed
        by the protocol will be combined or *correlated with
        information obtained outside the protocol* ?

    It is important to provide an answer to these two questions.

    Hereafter is some text that is fully conformant with RFC 7519
    which should be incorporated into the privacy considerations section
    which explains the implications of the two (and only two) flavours
    of the "sub" claim.

        When the sub claim contains a locally unique identifier in the
        context of the issuer, this allows the tracking of principal
        activities
        across multiple resource servers.

        When the sub claim contains a globally unique identifier, this
        allows to correlate principal activities across multiple resource
        servers, while in addition, this globally unique identifier
        may also allow to correlate the principal activities on
        servers where
        no access has been performed by the principals to these
        servers but where the same globally unique identifiers are
        being used
        by these servers.

    Denis

        Thanks Denis for the thorough commentary.

        /> The title of this spec./

        Fixed, thanks!

        /> The client MUST NOT inspect the content of the access token/

        This is really a sticky point. I really want to acknowledge
        your PoV on this, but at the same time I found this to be one
        of the biggest sources of issues in the use of JWT for access
        tokens hence I feel we really need to give solid guidance
        here. Let me expand further on the reasoning behind it, and
        perhaps we can get to language that satisfies both PoVs.

        To me the key point is that clients should not write /code/
        that inspects access tokens. Taking a dependency on the
        ability to do so is ignoring fundamental information about the
        architecture and relationships between OAuth roles, and
        suggests an ability of the client to understand the semantic
        of the content that cannot be assumed in the general case. I
        expanded on the details in my former reply to you on this
        topic, I would recommend referring to it. Clients violating
        this simple principle has been one of the most common sources
        of production issues I had to deal with in the past few years,
        and one of the hardest to remediate given that clients are
        hard to update and sometimes the things they relied on were
        irremediably lost. This is why I am inclined to put in here
        strong language.

        That said: I have nothing against client developers examining
        a network trace and drawing conclusions based on the content
        of what they see. That doesn’t create any hard dependencies
        and has no implications in respect to changes in the solution
        behavior. However I am not sure how to phrase that in the
        specification, given that referring to the client inevitably
        refers to its code. I am open to suggestions.

        >  3)…

        I have a pretty hard time following the chain of reasoning in
        this section. Let me attempt to tackle it to the best of my
        understanding.

        I think the key might be

        /> a client should be able to choose whether it wishes the sub
        claim to contain [..]/

        I don’t think that should be a choice left to the client. In
        business systems, my experience is that the type of
        identifiers to be used (when the IdP gives any choice at all)
         is established at resource provisioning time. I am not aware
        of mechanisms thru which a client signals the nature of the
        identifier to be used, nor that would be fully feasible (the
        resource knows what it needs to perform its function).

        Furthermore:

        /> which has nothing to do with uniqueness since the value
        changes for every generated token./

        Again, this is something that was touched on in my former
        reply to your message. As long as an identifier identifies one
        resource only, it satisfies uniqueness. It doesn’t have to be
        a singleton.

        Finally, the scope is optional (for good reasons: 1^st party
        and non delegation scenarios don’t require it) hence it cannot
        be relied upon for properties that should hold in every scenario.

        In summary: per the preceding thread on this topic, the
        consensus was that varying the sub content was a satisfactory
        way of protecting against correlation. I don’t a gree that
        clients should have a mechanism to request different sub
        flavors, as that decision should be done out of band by the AS
        and RS; and the scope isn’t always available anyway.

        /> targeting of access tokens/

        Let me think about that a bit longer.

        I acknowledge that the decision of including an audience has
        the effect of letting the AS track when the client accesses a
        particular resource, but at the same time that’s completely
        mainstream and very much by design in a very large number of
        cases. As such, I find the language you are suggesting to be
        potentially confusing, as it positions this as an exception vs
        a privacy protecting mainstream that is in fact not common,
        and ascribes to the client more latitude than I believe is
        legitimate to expect or grant.

        I’ll try to come up with concise language that clarifies to
        the reader that the current mechanism does allow AS tracking.

        *From: *OAuth <oauth-boun...@ietf.org>
        <mailto:oauth-boun...@ietf.org> on behalf of Denis
        <denis.i...@free.fr> <mailto:denis.i...@free.fr>
        *Date: *Wednesday, April 29, 2020 at 09:12
        *To: *"oauth@ietf.org" <mailto:oauth@ietf.org>
        <oauth@ietf.org> <mailto:oauth@ietf.org>
        *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT)
        Profile for OAuth 2.0 Access Tokens"

        You will find four comments numbered 1) to 4).

        *1) *The title of this spec. is:

        JSON Web Token (JWT) Profile for OAuth *2.0* Access Tokens

        So, this spec. is supposed to be targeted to OAuth *2.0.
        * However, the header at the top of the page omits to mention it.

        Currently, it is :

        Internet-Draft OAuth Access Token JWT Profile           April 2020

        It should rather be:

        Internet-Draft OAuth *2.0* Access Token JWT Profile April 2020

        *2)* The following text is within section 6.

        The client MUST NOT inspect the content of
        the access token: the authorization server and the resource server
        might decide to change token format at any time (for example by
        switching from this profile to opaque tokens) hence any logic
        in the
        client relying on the ability to read the access token content
        would
        break without recourse.
        Nonetheless, authorization servers should
        not assume that clients will comply with the above.

        It is of a primary importance that clients MAY be able to
        inspect tokens before transmitting them.
        The "MUST NOT" is not acceptable.

        The above text should be replaced with:

        Reading the access token content may be useful for the user to
        verify that
        the access token content matches with its expectations.  However,
        the authorization server and the resource server might decide
        to change the
        token format at any time.  Thus, the client should not expect
        to always be
        in a position to read the access token content.

        The remaining of the text about this topic is fine.


        *3) *The next topic is about the sub claim.

        The text states:

        Although the ability to correlate requests might be required by
        design in many scenarios, there are scenarios where the
        authorization
        server might want to prevent correlation to preserve the desired
        level of privacy. Authorization servers should choose how to
        assign
        sub values according to the level of privacy required by each
        situation.

        I have a set of questions:

         1. How can authorization servers choose how to assign sub
            values according to the level of privacy required "by each
            situation" ?
         2. How can authorization servers know the level of privacy
            required "by each situation" ?
         3. How can the users be informed of the level of privacy
            required "by each situation" ?
         4. How can the users *consent* with the level of privacy
            required "by each situation" ?

        Currently, the request MUST include either a resource
        parameter or an aud claim parameter, while it MAY include a
        scope parameter.

        The syntax of the scope parameter is a list of
        space-delimited, case-sensitive strings (RFC 6749). It is thus
        subject to private agreements
        between clients and Authorization Servers. Since the scope is
        being returned, it is a primary importance that the returned
        scope matches
        with its expectations before transmitting the token to a
        Resource Server.

        In theory, a client should be able to choose whether it wishes
        the sub claim to contain :

          * a global unique identifier for all ASs ("globally unique"),
          * a unique identifier for each AS ("locally unique in the
            context of the issuer"),
          * a different pseudonym for each RS, or
          * a different pseudonym for each authorization token request.

        The only variable parameter that it can use for this purpose
        in the token request is the scope parameter.

        RFC 7519 states is section 4.1.2:

        The subject value MUST either be scoped to be locally unique
        in the context of the issuer
        or be globally unique.

        It is quite hard to recognize that the sub claim is able to
        carry a different pseudonym for each RS, i.e. for case (c), or
        a different pseudonym for each authorization token request,
        i.e. for case (d), which has nothing to do with uniqueness
        since the value changes for every generated token.

        This has implications about the following text:

        For instance: if a solution requires preventing tracking
        principal activities across multiple resource servers, the
        authorization server should ensure that JWT access tokens
        meant for
        different resource servers have distinct sub values that cannot be
        correlated in the event of resource servers collusion.

        Since it addresses case (c).

        and also about the following text:

        4.b) Similarly: if a solution requires preventing a resource
        server from
        correlating the principal’s activity within the resource
        itself, the
        authorization server should assign different sub values for
        every JWT
        access token issued.

        Since it addresses case (d).

        This means that the current text placed in the privacy
        considerations section was a good attempt to address the case,
        but that the text needs to be revised.

        Proposed text replacement for all the previously quoted sentences:

        According to RFC 7519 (4.1.2): The subject value MUST either
        be scoped to be locally unique in the context of the issuer or
        be globally unique.

        When the sub claim contains a globally unique identifier, this
        allows to correlate principal activities across multiple
        resource servers, while in addition,
        this globally unique identifier may also allow to correlate
        the principal activities on servers where no access has been
        performed by the principals
        to these servers but where the same globally unique
        identifiers are being used by these servers.

        When the sub claim contains a locally unique identifier in the
        context of the issuer, this also allows the tracking of
        principal activities across multiple resource servers.

        The scope request parameter is the only way to influence on
        the content of the sub claim parameter. Its meaning is subject
        to a private agreement
        between the client and the AS, which means that the use of the
        scope parameter is the only way to choose between a locally
        unique identifier
        in the context of the issuer or a globally unique identifier.

        Since the scope parameter is being returned, it is a primary
        importance that the returned scope matches with the
        expectations of the client before transmitting
        the token to a Resource Server.

        However, there are other cases where the client would like to
        be able to choose whether it wishes the sub claim to contain :
            - a different pseudonym for each RS so that different
        resource servers will be unable to correlate its activities, or
            - a different pseudonym for each authorization token
        request, so that the same resource server cannot correlate its
        activities performed at different instant of time.

        Considering the semantics of the sub claim, these two cases
        cannot be currently supported.


        *4) *The next topic is about the targeting of access tokens

        Text had been proposed before the last conference call. Then,
        the topic has been presented at the very end of the last
        conference call, but no text has been included
        in the next draft.

        Here is a revised text be included in the privacy
        considerations section:

        For security reasons, some clients may be willing to target
        their access tokens but, for privacy reasons, may be unwilling
        to disclose to Authorization Servers
        an identification of the Resource Servers they are going to
        access, so that Authorization Servers will be unable to know
        which resources servers are being accessed.
        The disclosure of the Resource Servers names allows the
        Authorization Servers to list all the Resource Servers being
        access by all its users and in addition to list pairs
        of (Principal, Resource Servers) which allow to trace all the
        users accesses to Resource Servers performed through a given
        Authorization Server. When a token is targeted,
        this profile does not contain provisions to address these two
        threats.

        Denis

            Hi all,

            This is a second working group last call for "JSON Web
            Token (JWT) Profile for OAuth 2.0 Access Tokens".

            Here is the document:

            https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

            Please send your comments to the OAuth mailing list by
            April 29, 2020.

            Regards,

             Rifaat & Hannes

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org  <mailto:OAuth@ietf.org>

            https://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org <mailto: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

Reply via email to