Re: [OAUTH-WG] WGLC for Step-up Authentication

[Denis <[e-mail]>]

Hi Brian,

I agree with you that "must not" is more appropriate in that context.

I also agree with you that the "privacy implications of opaque tokens 
are inherent to OAuth in general".
However, I have not reviewed all the RFCs and I wonder whether such a 
privacy consideration has already been mentioned.

It would be nice to start to mention it, rather than to continue to omit 
it. Do you see a better place to mention it ?

Denis

> Thanks Denis, I agree the word "cannot" isn't quite right there. I 
> struggled with trying to find the right wording (more than I probably 
> should have) attempting to add a note/reminder without getting into 
> normative sounding language. But I also wanted to make a firm 
> statement. Words are hard sometimes. Oftentimes! But reading it again 
> today, "cannot" doesn't work very well. I think changing to "must not" 
> is appropriate. The privacy implications of opaque tokens are inherent 
> to OAuth in general and I don't believe this draft is an appropriate 
> place to attempt to give them treatment.
>
> On Tue, Oct 11, 2022 at 2:57 AM Denis <[e-mail]> wrote:
>
>     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=[e-mail]> 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
>>         <[e-mail]> 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=[e-mail]> 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 <[e-mail]> *On Behalf Of
>>                 *Rifaat Shekh-Yusef
>>                 *Sent:* Thursday, September 22, 2022 3:02 PM
>>                 *To:* oauth <[e-mail]>
>>                 *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
>>                 <[e-mail]> 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
>>                 [e-mail]
>>                 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
>>             [e-mail]
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail]
>>         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
>>     [e-mail]
>>     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./