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

[Brian Campbell <[e-mail]>]

Jaimandeep,

As Warren pointed out, requirements in this draft are only in the context
of the draft itself. They are only applicable to
implementations/deployments aiming to conform to the draft, which is
completely optional in itself.

When making access control decisions, it is not uncommon to factor in
details of the authentication event associated with the access token. This
happens in practice today and certainly isn't challenging the very premises
of OAuth 2.0. This draft aims to provide interopatblue pieces to improve
those scenarios by allowing 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 requirements (however the RS determines that) and
convey that to the AS in the authorization request (via the user's browser)
to remediate.

RFC 6749 does have confidential clients and client authentication but, as
Vittorio pointed out, it doesn't apply to the authorization endpoint. So
that's kind of non sequitur. JAR/RFC9101 or PAR/RFC9126 are available
options to better secure the authorization request but it's not in the
scope of this draft to mandate either of them.

This draft isn't forcing any AS to implement OIDC. Nor will it render
existing implementations non-compliant. The draft reuses/references two
authorization request parameters from OIDC because they were existing
constructs that fit nicely with the functionally needed. I don't see how
this as being biased. I see it as a pragmatic decision aimed at
simplification and interoperability.

The use of the term "freshness" seems perfectly appropriate in the few
places it's used in the draft. The protected resource receiving an access
token makes the determination about how recent of an end user
authentication event associated with the access token is needed, if any,
for its policy and can convey its requirement with max_age if necessary.
Freshness doesn't need to be quantified in the document - the required
recency is at the discretion of the protected resource based on its access
control policy.







On Fri, Oct 21, 2022 at 6:03 AM Jaimandeep Singh <
[e-mail]> wrote:

> Dear Vittorio,
>
> Thankyou for the detailed reply. My follow-on suggestions and
> recommendations are given below for kind consideration please [The original
> suggestions can be found here
> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/>
> ]:
>
> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end user
> authentication with authorization.
> *Follow-on Comment*: Thx for bringing out that RFC 9068 already has
> "acr'' as a claim. However, it is an OPTIONAL claim, whereas section 5 of
> the draft RFC recommends it to be a required parameter. Notwithstanding, in
> my view, the proposed draft is challenging the very premises of OAuth 2.0
> by strongly coupling the authorization layer with the end user
> authentication. The OAuth 2.0 is supposed to be agnostic to the end user
> authentication. Are we comfortable with this coupling?
> *Recommendation*: The draft RFC should be made informational. If that is
> out of scope then all the proposed claims, parameters and headers should be
> made OPTIONAL.
>
> *Item No 2*: Punching a security hole by requiring AS to act on
> information provided by the client applications (Reverse Flow).
> *Follow-on Comment*: I would like to differ on this view. The client
> applications do require authentication in case of confidential clients
> (Refer Section 2.3 of RFC 6749). I would also like to point towards the
> Google OAuth 2.0 page which talks about 'creation of authorization
> credentials' by the client applications and can be accessed here
> <https://developers.google.com/identity/protocols/oauth2/web-server>.
>    The point I am making is that the client application needs to
> authenticate itself with the OAuth 2.0 endpoint before starting the
> communication. Also, making AS act on information provided by
> client applications may lead to future vulnerabilities as client
> applications are not considered 'trusted' especially when we follow zero
> trust architecture.
> *Recommendation*.
>
> a. The example given in section 4 of draft RFC be updated to reflect the
> need of complete authentication of the client application before the
> "acr_values" or "max_age" values are accepted or acted upon by the OAuth
> 2.0 endpoint.
> b. Need for signing these values by the RS which can be verified by the
> AS. Therefore, we need to look at ways by which the RS returns a signed JWT
> token containing "acr_values" or other such claims which should also be
> opaque to the client applications.
>
>
> *Item No 3*: Forcing AS to implement OIDC specifications will render
> existing implementations non-compliant.
> *Follow-on Comment*: I fully agree to your statement that 'existing
> implementations aren't expected to comply with the new specification'.
> However, the point I am making is that we cannot be biased towards OIDC
> specifications and leave others non-compliant. We have to make future
> specifications such that it doesn't favour one over other.
> *Recommendations*: All the proposed claims, parameters and headers should
> be made OPTIONAL.
>
> *Item No 4*: How much “Freshness” is fresh?
> *Follow-on Comment*: The *term* "freshness" may have earlier precedent
> but the context is different.
> *Recommendation*. Let's not use a term which cannot be quantified and is
> open to different interpretations by readers/implementers.
>
> Kind Regards
> Jaimandeep Singh
>
> On Fri, Oct 21, 2022 at 2:53 AM Vittorio Bertocci <vittorio=
> [e-mail]> wrote:
>
>> Hi Jaimandeep,
>> I have a bit of cognitive whiplash - your first message professed strong
>> support for this work, further reinforced by a LinkedIn post where you
>> mentioned that your own paper supports the ideas expressed in this spec
>> (not linking it because it's gone, but I have a screenshot)- whereas in
>> your latest message you raise objections that question the very
>> existence of this document... anyway, to your comments:
>>
>> 1 - I don't understand what "striking at the very core of OAuth" really
>> means in concrete terms, however passing ACR in an access token is already
>> standard behavior as described in
>> https://datatracker.ietf.org/doc/html/rfc9068, as referenced by the
>> draft.
>> For what concerns the clientID considerations - the draft is pretty clear
>> on aiming to solve scenarios where the RS is the entity deciding to reject
>> incoming tokens for its own reasons, such as risk assessment performed
>> locally, that by definition cannot be determined solely on the basis of the
>> client identity.
>>
>> 2 - I have a hard time parsing this objection as well. A client does NOT
>> authenticate itself when hitting the authorization endpoint, regardless of
>> the client flavor;  whether the oauth spec accepts a parameter or not isn't
>> really relevant in an spec whose intent is to _extend_ oauth; and saying
>> that the client is untrusted doesn't mean that the AS wouldn't comply with
>> request parameters, because once again the authorization endpoint doesn't
>> require ANy client authentication.
>>
>> 3- New RFCs don't override existing specs: they build on existing specs
>> by extending and/or constraining existing behaviors. Forward compatibility
>> would require the ability to predict the future, hence existing
>> implementations aren't expected to comply with the new specification until
>> they decide to add support for it. Now for this particular specification,
>> we might get lucky and have forward compatibility in many implementations
>> as products often implement both OAuth and OIDC in the same codebase, but
>> once again - that is definitely not required.
>>
>> 4- Also in this case, I am not sure how to read this objection. The use
>> of the *term* "freshness" has precedent in IETF specs (see rfc8747) and is
>> commonly used in discussions on the list; and the concept is very well
>> known and understood, as the existence of the max_age parameter attests;
>> the fact that it is defined in OIDC doesn't really matter in this context,
>> it is common practice for RS to impose the same constraint- one of the
>> reasons that prompted us to draft this extension.
>>
>> I hope this helps!
>> Best,
>> V.
>>
>> On Thu, Oct 20, 2022 at 10:10 AM Jaimandeep Singh <jaimandeep.phdcs21=
>> [e-mail]> wrote:
>>
>>> *This message originated outside your organization.*
>>>
>>> ------------------------------
>>>
>>> Dear Vittorio Bertocci, Brian Campbell and Rifaat,
>>>
>>>
>>> My sincere compliments to Vittorio and Brian for their persistent
>>> efforts in making and improving the draft RFC and also for taking out
>>> valuable time and efforts to reply to any queries. However, I strongly feel
>>> that the following points should be addressed before closing the last call.
>>>
>>> Item No 1: Striking at the core of OAuth 2.0 idea by coupling end user
>>> authentication with authorization.
>>>
>>> Explanation: OAuth 2.0 is an authorization protocol. Its strength lies
>>> in the decoupling of the end user authentication with the authorization
>>> layer. The proposed draft proposes means of coupling the two by passage of
>>> authentication information down the complete OAuth 2.0 chain and then
>>> RECOMMENDS actions by AS based on this information, thereby striking at the
>>> core idea of OAuth 2.0.
>>>
>>>
>>>
>>> The idea of end user authentication information being transferred to the
>>> AS is borrowed from OIDC, which sends this information through token ID in
>>> the form of JWT (Refer Section 2 of OIDC specs). This parameter is designed
>>> to be OPTIONAL in OIDC and is not further passed in the access tokens. In
>>> the draft RFC we are not only passing the authentication information down
>>> the chain through access tokens but also acting on the information received
>>> from client applications upstream.
>>>
>>>
>>>
>>> The idea of fiddling with end user authentication is completely foreign
>>> to the OAuth 2.0 specs. Following questions then arise:
>>>
>>>    1.
>>>
>>>    Do we intend to extend the scope of OAuth 2.0 specs by coupling it
>>>    with the end-user authentication and striking at the very core idea of
>>>    OAuth 2.0?
>>>    2.
>>>
>>>    OAuth 2.0 does require means of identification for the client
>>>    application either through client ID only in case of public clients or
>>>    through basic authentication in case of confidential clients. Is it not
>>>    better to look at step-up identification/authentication requirements of the
>>>    client application i.e. the way the client application
>>>    identifies/authenticates itself with the AS instead of getting involved
>>>    with the mechanics of end user authentication. The idea of client
>>>    application authentication is intrinsic to the OAuth 2.0 specs.
>>>
>>>
>>> Item No 2: Punching a security hole by requiring AS to act on
>>> information provided by the client applications (Reverse Flow).
>>>
>>> Explanation. Refer Section 4 of draft RFC
>>>
>>> The example request below, which might occur after receiving the
>>>> challenge in Figure 2, indicates to the authorization server that the
>>>> client would like the authentication to occur according to the
>>>> authentication context class reference identified by myACR.
>>>
>>>
>>>> GET https://as.example.net/authorize?client_id=s6BhdRkqt3
>>>> <https://urldefense.com/v3/__https://as.example.net/authorize?client_id=s6BhdRkqt3__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3seHNQRw$>
>>>> &response_type=code&scope=purchase&acr_values=myACR
>>>> Figure 4: Authorization Request indicating acr_values
>>>
>>>
>>> In OAuth 2.0 specs, the client application authenticates itself with the
>>> AS before starting the flow. Here, in the example above there are two
>>> prominent flaws:
>>>
>>>    1.
>>>
>>>    The unauthenticated rogue client makes a GET request to the AS
>>>    forcing the complete authentication breakdown at the end user forcing him
>>>    to authenticate time over and again.
>>>    2.
>>>
>>>    Even if we take a scenario that the request is made by an
>>>    authenticated client, the original specs of OAuth 2.0 does not mandate any
>>>    action based on the commands received from the client application. In a
>>>    zero trust model we assume that the client is compromised. AS acting on
>>>    commands of client applications and propagating them across the ecosystem
>>>    to force the end user authentication may result in future unseen
>>>    vulnerabilities.
>>>
>>>
>>> Item No 3: Forcing AS to implement OIDC specifications will render
>>> existing implementations non-compliant.
>>>
>>> Explanation. Refer Section 5 of the draft specs.
>>>
>>> Although [OIDC] leaves the authorization server free to decide how to
>>>> handle the inclusion of acr in ID Token when requested via acr_values, when
>>>> it comes to access tokens in this specification it is RECOMMENDED that the
>>>> requested acr value is treated as required for successfully fulfilling the
>>>> request.
>>>
>>>
>>> The *RECOMMENDED *and *required* “acr_values” in the access tokens will
>>> render existing deployments of AS, which currently do not support OIDC, as
>>> non-compliant.
>>>
>>> Item No 4: How much “Freshness” is fresh?
>>>
>>> Explanation. The use of the word “Freshness” is not quantified and does
>>> not convey any meaning. It is recommended to be removed altogether. On the
>>> contrary it complicates the draft, making the reader assume that
>>> “freshness” of authentication is very important and might impact on the
>>> whole idea of access tokens and the OAuth 2.0 in the first place.
>>>
>>>
>>> On Tue, Oct 18, 2022 at 1:25 AM Brian Campbell <bcampbell=
>>> [e-mail]> wrote:
>>>
>>>> Thanks Jaimandeep,
>>>>
>>>> There are certainly some complementary aspects of the step-up work and
>>>> adaptive risk based approaches. Both in conveying information in/with an
>>>> access token that might be input into a risk score calculation and in
>>>> signaling that a more recent and/or stronger user authentication
>>>> is required when the calculated risk exceeds the allowed risk.
>>>>
>>>> On Sat, Oct 15, 2022 at 10:58 PM Jaimandeep Singh <jaimandeep.phdcs21=
>>>> [e-mail]> wrote:
>>>>
>>>>> Dear Brian,
>>>>>
>>>>> I strongly support this work. I have recently written a conference
>>>>> paper on supporting similar ideas titled '*Resilient Risk based
>>>>> Adaptive Authentication and Authorization (RAD-AA) Framework*'. The
>>>>> paper is still in the pre-print stage and can be accessed here
>>>>> <https://urldefense.com/v3/__https://arxiv.org/abs/2208.02592__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3zA283j8$>.
>>>>>
>>>>>
>>>>> 1. The core idea is similar. Firstly, ability to revoke or step-up the
>>>>> authentication requirements based on the risk score. Secondly, to limit the
>>>>> scope based on the risk score.
>>>>>
>>>>> 2. One of the factors determining the risk score is the way the client
>>>>> application has authenticated with the Authorization server. If it has used
>>>>> basic auth the risk score is high as compared to mTLS.
>>>>>
>>>>> 3. Additionally the idea is to downgrade the scope of the token in
>>>>> case the risk score is high. This could be achieved at the protected
>>>>> resource server end through introspection and at authorization server end
>>>>> while issuing new access when the older ones expire. This can avoid forcing
>>>>> the complete authentication cycle at client end.
>>>>>
>>>>> Regards
>>>>> Jaimandeep Singh
>>>>>
>>>>>
>>>>> On Wed, Oct 12, 2022 at 3:25 AM Brian Campbell <bcampbell=
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> 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 <[e-mail]> 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 <[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/
>>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3CV1UVi4$>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>>>>>>
>>>>>>>>
>>>>>>>> *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 [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> *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.*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> *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
>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards and Best Wishes
>>>>> Jaimandeep Singh
>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>
>>>>
>>>> *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
>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>
>>>
>>>
>>> --
>>> Regards and Best Wishes
>>> Jaimandeep Singh
>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>

-- 
_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._