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