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
