Re: [OAUTH-WG] WGLC for Step-up Authentication
I don't know offhand a better place or if your specific privacy consideration is already covered. Honestly, with that comment, I was just aiming to keep the scope of this document concise and relevant. On Tue, Oct 11, 2022 at 10:06 AM Denis wrote: > 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 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 > 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 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
[OAUTH-WG] I-D Action: draft-ietf-oauth-step-up-authn-challenge-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Step-up Authentication Challenge Protocol Authors : Vittorio Bertocci Brian Campbell Filename: draft-ietf-oauth-step-up-authn-challenge-05.txt Pages : 15 Date: 2022-10-11 Abstract: It is not uncommon for resource servers to require different authentication strengths or freshness according to the characteristics of a request. This document introduces a mechanism for a resource server to signal to a client that the authentication event associated with the access token of the current request doesn't meet its authentication requirements and specify how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or freshness when processing an authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-step-up-authn-challenge-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for Step-up Authentication
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 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 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 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.
Re: [OAUTH-WG] WGLC for Step-up Authentication
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 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 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 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 >> 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
Re: [OAUTH-WG] WGLC for Step-up Authentication
I forgot to add Dima to the acknowledgements yesterday when doing -04 (thanks Vittorio for catching that). I'll rectify that shortly. On Mon, Oct 10, 2022, 4:53 PM Brian Campbell wrote: > 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 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 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 >> 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
Re: [OAUTH-WG] WGLC for Step-up Authentication
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 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 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 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,
