>>>>>>>>>commands of client applications and propagating them across the
>>>>>>>>>>>> ecosystem
>>>>>>>>>>>>to force the end user authentication may result in fu
gt;>>>>>>>>
>>>>>>>>>>> Item No 4: How much “Freshness” is fresh?
>>>>>>>>>>>
>>>>>>>>>>> Explanation. The use of the word “Freshness” is not quantified
>>>>>>>>>>> and does not convey any
>>>>>> is required when the calculated risk exceeds the allowed risk.
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Oct 15, 2022 at 10:58 PM Jaimandeep Singh
>>>>>>>>>>> wrote:
>>>>>>>>>
ith the Authorization server.
>>>>>>>>>>> If it
>>>>>>>>>>> has used basic auth the risk score is high as compared to mTLS.
>>>>>>>>>>>
>>>>>>>>>>> 3. Additionally the idea is
n,
>>>>>>>>>>>>
>>>>>>>>>>>> I agree with you that "must not" is more appropriate in that
>>>>>>>>>>>> context.
>>>>&
Oftentimes! But reading it again today,
>>>>>>>>>>> "cannot"
>>>>>>>>>>> doesn't work very well. I think changing to "must not" is
>>>>>&g
t;>>>>>>>>> token to
>>>>>>>>>>> determine the associated authentication information or other
>>>>>>>>>>> details.
>>>>>>>>>>> The token format might be unread
Authorizations Servers are able to disclose more information than
>>>>>>>>>> strictly necessary about the authenticated user without the end user
>>>>>>>>>> being
>>>>>>>>>> able to kno
oQflkoFpwtN5sadjP3CV1UVi4$>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci >>>>>>>> 40auth0@dmarc.ietf.org> wrote:
ading 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 simpl
empowering an RS to communicate its ACR and
>>>>>>>>> freshness requirements, regardless of the reasons leading the RS to
>>>>>>>>> make
>>>>>>>>> that determinatio
entirely determined by the AS without any
>>>>>>>> communication with client or RS required).
>>>>>>>>
>>>>>>>> On Fri, Oct 7, 2022 at 17:43 Dima Postnikov
>>>>>>>&
Sent from my iPhone
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>> 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
>&
gt; market that could return "STEP UP is required" after looking at
>>>>>>> authentication, authorisation and many other real-time signals. It's
>>>>>>> just
>>>>>>> not standardized...
>>>>>>>
>>>>
from them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> One observation from working through these uses cases is that as
>>>>>>> customers move to Zero Trust architectures, we are seeing customers
>>>>>
t; 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 co
gt;>>> arise from them.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> One observation from working through these uses cases is that as
>>>>>>> customers move to Zero Trust architectures, we are seei
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 f
ion contexts and combinations of contexts
are required is something others see (or are
beginning to see) as well?
Cheers
Pieter
*From:*OAuth *On Behalf Of
*Rifaat Shekh-Yusef
*Se
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
>&g
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 i
*From:*OAuth *On Behalf Of
*Rifaat Shekh-Yusef
*Sent:* Thursday, September 22, 2022 3:02 PM
*To:* oauth
*Subject:* Re: [OAUTH-WG] WGLC for Step-up Authentication
*Correction:*
Please, review the document and provide your feedba
tabase
>>> 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
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?
>>
>&
> *From:* OAuth *On Behalf Of *Pieter Kasselman
> *Sent:* Friday, October 7, 2022 9:29 PM
> *To:* Rifaat Shekh-Yusef ; oauth
> *Subject:* Re: [OAUTH-WG] WGLC for Step-up Authentication
>
>
>
> I am very supportive of this work and have been working through different
>
ehalf Of Pieter Kasselman
Sent: Friday, October 7, 2022 9:29 PM
To: Rifaat Shekh-Yusef ; oauth
Subject: Re: [OAUTH-WG] WGLC for Step-up Authentication
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
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
&
: Thursday, September 22, 2022 3:02 PM
To: oauth
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
mailto:rifaat.s.i...@gmail.com
*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
wrote:
> All,
>
> This is to start a *WG Last Call *for the *Step-up Authentication *
> document:
>
> https://www.ietf.org/archive/id/dr
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
Please, review the document and provide your feedback on the mailing list
by *Sep 30th, 2022*.
Regards,
Rifaat & Hannes
32 matches
Mail list logo
