Hi Brian,

The text states:

   Also recall that OAuth 2.0 [RFC6749] assumes access tokens are
   treated as
   opaque by clients. So, during the course of any token caching
   strategy, a client *cannot* inspect the content of the access token to
   determine the associated authentication information or other details.
   The token format might be unreadable to the client or might change at
   any time to become unreadable.

A client *can *inspect the content of the access token.

A better wording  would be:

   ...  a client *should not *inspect the content of the access token ...

It would be worthwhile to add a Privacy Considerations section:

   10. Privacy Considerations

   Since access tokens are presumed to be opaque to clients, clients
   (and hence users) are not supposed to inspect the content of the
   access tokens.
   Authorizations Servers are able to disclose more information than
   strictly necessary about the authenticated user without the end user
   being
   able to know it. Such additional information may endanger the
   privacy of the user.

Denis


I've published an -04. It has that very minor change. There was also an off-list discussion during WGLC that resulted in thinking it'd be worthwhile *_to add a reminder that access tokens are opaque to clients_*. So I took that as LC feedback and -04 adds a brief note towards that end.

https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/



On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci <vittorio=40auth0....@dmarc.ietf.org> wrote:

    Thanks Dima for the comment. Some thoughts:

    > (editorial)...
    Good point. "statically" would characterize the simplest of the
    scenarios, but in fact any case where the AS is the only arbiter
    of the authn level works for the point we are trying to make.
    We'll drop "statically". Thanks!

    > Apart from...
    This spec focuses on empowering an RS to communicate its ACR and
    freshness requirements, regardless of the reasons leading the RS
    to make that determination: the logic by which that happens is
    explicitly out of scope, and in many real life cases it might
    simply be unknowable (eg anomaly detection engines based on ML are
    often back boxes). The mechanism described here can be used
    alongside other mechanisms that might require the client to get
    the user to interact with the AS, as it is the case for
    insufficient_scope, but those remain distinct cases (eg
    insufficient _scope might not require any step up but simply
    explicit user consent, and if it does require a stepup, that's
    entirely determined by the AS without any communication with
    client or RS required).

    On Fri, Oct 7, 2022 at 17:43 Dima Postnikov <d...@postnikov.net>
    wrote:

        *This message originated outside your organization.*


        ------------------------------------------------------------------------

        Couple of quick comments from me:

        1) (Editorial) >In simple API authorization scenarios, an
        authorization server will statically determine what
        authentication technique

        In many scenarios, authorization servers will use *dynamic*
        decisioning to determine authentication techniques; it's just
        not exposed to the client in a way to make it actionable
        (which is why this specification's intent makes perfect sense).

        2) Apart from authentication level, there might be other
        reasons why users might be forced to go through the
        authorization flow, for example, insufficient authorization /
        scopes / claims / etc.

        If there is a mechanism to let the client know, as a
        practitioner, i'd rather have the same approach for both
        authentication and authorization. There are a range of
        authorization policy engines in the market that could return
        "STEP UP is required" after looking at authentication,
        authorisation and many other real-time signals. It's just not
        standardized...


        On Sat, Oct 8, 2022 at 7:30 AM Pieter Kasselman
        <pieter.kasselman=40microsoft....@dmarc.ietf.org> wrote:

            I am very supportive of this work and have been working
            through different use cases to see whether it can satisfy
            the requirements that arise from them.

            One observation from working through these uses cases is
            that as customers move to Zero Trust architectures, we are
            seeing customers adopting finer grained policy
            segmentation. Consequently customers are planning to
            deploy segmented access control by data or action
            sensitivity, within a service. This approach to policy
            design makes it more common for a single service to depend
            on multiple authentication context values or combinations
            of authentication context values.

            An example of this is a policy that has multiple acr
            values (e.g. acr1=password, acr2=FIDO, acr3=selfie check,
            acr4=trusted network). A customer may define a policy that
            requires different combinations of these acr values, for
            example, a file server may requires password for general
            access (e.g. acr1), FIDO authentication (acr2) or password
            access and being on a trusted network to read sensitive
            data (acr 2 of (acr1 + acr 4), FIDO authentication and
            password (acr1 + acr2) for accessing editing sensitive
            documents and a real-time selfie check on top of FIDO and
            presence on a trusted network  (acr1 + acr2 + acr3 + acr4)
            to initiate a sensitive workflow (e.g. check-in code).
            Other variations of this includes database access with
            different types of access requirement for certain rows
            (row-level permissions) or columns (column level
            permissions) with different combinations of acr values.

            I was curious if this type of scenario where multiple
            authentication contexts and combinations of contexts are
            required is something others see (or are beginning to see)
            as well?

            Cheers

            Pieter

            *From:*OAuth <oauth-boun...@ietf.org> *On Behalf Of
            *Rifaat Shekh-Yusef
            *Sent:* Thursday, September 22, 2022 3:02 PM
            *To:* oauth <oauth@ietf.org>
            *Subject:* Re: [OAUTH-WG] WGLC for Step-up Authentication

            *Correction:*

            Please, review the document and provide your feedback on
            the mailing list by *Oct 7th, 2022*.

            On Thu, Sep 22, 2022 at 9:52 AM Rifaat Shekh-Yusef
            <rifaat.s.i...@gmail.com> wrote:

                All,

                This is to start a *WG Last Call *for the *Step-up
                Authentication *document:
                
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-03.html
                
<https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-oauth-step-up-authn-challenge-03.html&data=05*7C01*7Cpieter.kasselman*40microsoft.com*7C0078f809101147bc978308da9ca32020*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637994521713812011*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=18sfemyWqYb06PvUA9eTLaq0ccDY14*2F6ETo58JpE*2FJQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAomtRXj8$>


                Please, review the document and provide your feedback
                on the mailing list by *Sep 30th, 2022*.

                Regards,
                 Rifaat & Hannes

            _______________________________________________
            OAuth mailing list
            OAuth@ietf.org
            https://www.ietf.org/mailman/listinfo/oauth
            
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAbcE1GME$>

        _______________________________________________
        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


/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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to