+1 for adoption
On Wed, Nov 16, 2022 at 1:43 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> During the IETF meeting last week, there was a strong support for
> the adoption of the following document as a WG document:
> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/
>
> This is
to implement the "REQUIRED or RECOMMENDED" in the
> OAuth 2.1 spec for code_challenge.
>
> Another spec that deals with PKCE is the OAuth BCP, but to me that's not a
> optimal place to define a new parameter.
>
>
> Vladimir Dzhuvinov
>
>
> On 08/10/2022 04:
Hi Vladimir,
Similar issue exists in CDR (Australian Open Banking). PAR and PKCE was
added as mandatory to FAPI 1 Advanced profile.
There was a transition period when AS had to support both (potentially).
Also if the same AS is used outside of CDR, this dual support would
continue for some imple
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 ex
I agree, "limited access" makes sense. I am happy to create a PR, if required.
Current wording is:
The OAuth 2.1 authorization framework enables a*n* *third-party*
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval inter
tract needs any qualification on this and would only confuse people
>> further. Any clarifications of which situations are appropriate for using
>> OAuth could be explored in a different section in the spec.
>>
>> Aaron Parecki
>>
>> On Fri, Aug 28, 2020 at 3
situations are appropriate for using
> OAuth could be explored in a different section in the spec.
>
> Aaron Parecki
>
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 40lodderstedt@dmarc.ietf.org> wrote:
>
>> I agree. OAuth works for 3rd as well as 1st partie
Hi,
Can "third-party" term be removed from the specification?
The standard and associated best practices apply to other applications that
act on behalf of a resource owner, too (internal, "first-party" and etc).
Regards,
Dima
The OAuth 2.1 authorization framework enables a *third-party*
app
