unseen
>>>>>>>>>>>>vulnerabilities.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Item No 3: Forcing AS to implement
ot 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 “
t;>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Dear Brian,
>>>>>>>>>>>>
>>>>>>>>>>>> I strongly support this work. I have recently written a
>>>>>>>>>&g
t;>>>> 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 en
;>>>>>>>>
>>>>>>>>>>>> I also agree with you that the "privacy implications of opaque
>>>>>>>>>>>> tokens are inherent to OAuth in general".
>>>>>>>>>>>> Howev
>>>>>>>>>> appropriate. The
>>>>>>>>>>> privacy implications of opaque tokens are inherent to OAuth in
>>>>>>>>>>> general and
>>>>>>>>>>> I don't believe this draft is an appropriate
;>>>>>> The token format might be unreadable to the client or might
>>>>>>>>>>> change at
>>>>>>>>>>> any time to become unreadable.
>>>>>>>>>>>
>>>>>>
ng
>>>>>>>>>> able to know it. Such additional information may endanger the
>>>>>>>>>> privacy of the user.
>>>>>>>>>>
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>>
>>
22 PM Vittorio Bertocci >>>>>>>> 40auth0....@dmarc.ietf.org> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Dima for the comment. Some thoughts:
>>>>>>>>>>
>>>>>>>>>> > (editorial
>>>>>>> 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
>>>>>>>>>
;>>>>> 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
t; On Fri, Oct 7, 2022 at 17:43 Dima Postnikov
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> *This message originated outside your organization.*
>>>>>>>>>
>>>>>>>>> ---
Sent from my iPhone
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ion'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
>>>>>>>> e
>>>>>>> authentication, authorisation and many other real-time signals. It's
>>>>>>> just
>>>>>>> not standardized...
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Oct 8, 2022 at 7:30 AM Pieter Kasselman >&g
gt;>>>>>>
>>>>>>> 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 cus
rs 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 s
;>
>>>>>>>
>>>>>>> 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.
>>>>>> for a
>>>>>> single service to depend on multiple authentication context values or
>>>>>> combinations of authentication context values.
>>>>>>
>>>>>>
>>>>>>
>>>>>> A
es (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
>>>>
are required is something others see (or are
beginning to see) as well?
Cheers
Pieter
*From:*OAuth *On Behalf Of
*Rifaat Shekh-Yusef
*Sent:* Thursday, September 22, 2022 3:02 PM
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)
> 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
*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 feedback on
the mailing list by *O
t 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 authenticati
binations 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
&
> *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
>
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 them
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:
>
>
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
