Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

From: Denis <[email-masked]>
Date: Tue, 5 May 2020 17:19:54 +0200

Comments on draft-ietf-oauth-security-topics-15

1) Historically, the acronym RO (Resource Owner) has been used but is 
still used in this document.
     Since a client is not necessarily any more a RO, it would be more 
adequate to use the word "Client"
     instead of "RO"  in this document.

2) The structure of the document is the following:

1.Introduction
2.Recommendations
3.The Updated OAuth 2.0 Attacker Model

It is rather odd to have recommendations placed before the Attacker 
Model. Before providing solutions to some problems,
it is important to understand what the problems are. The Updated OAuth 
2.0 Attacker model should be placed after the introduction.

The "most important recommendations of the OAuth working group for every 
OAuth implementor" should be placed after the "Attacks and Mitigations" 
section.

3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships involving 
multiple parties_".
However, it still misses to address the case of _dynamic relationships 
between clients_, which include scenarios of _collaborative clients_.

Such a collaboration between clients is possible and should be 
considered in the "updated model". Since the Auth 2.0 protocol may be 
used by clients
which are human beings, it cannot be assumed that all the human beings 
in the world will necessary be honest. Whether or not Auth 2.0 is able 
or not
to counter such an attack is another issue.

The collaborative attack should be added to this "updated" model. It was 
missing in the previous model.

In another section, it should be mentioned that OAuth 2.0 is unable to 
counter such an attack.
Stating that such an attack is "out of the scope" of OAuth 2.0 would not 
be an appropriate statement.

It should not be forgotten, that the purpose of this document is to 
inform the reader about _all_ the relevant security issues.

Denis

> 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 Security Best Current Practice
>          Authors         : Torsten Lodderstedt
>                            John Bradley
>                            Andrey Labunets
>                            Daniel Fett
> 	Filename        : draft-ietf-oauth-security-topics-15.txt
> 	Pages           : 46
> 	Date            : 2020-04-05
>
> Abstract:
>     This document describes best current security practice for OAuth 2.0.
>     It updates and extends the OAuth 2.0 Security Threat Model to
>     incorporate practical experiences gathered since OAuth 2.0 was
>     published and covers new threats relevant due to the broader
>     application of OAuth 2.0.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Daniel Fett <[email-masked]>
Date: Thu, 7 May 2020 10:23:50 +0200

Hi Denis,

>     instead of "RO"  in this document.
The terms Resource Owner and Client are clearly defined in RFC6749 and
refer to two different entities.
>    1.  Introduction
>    2.  Recommendations
>    3.  The Updated OAuth 2.0 Attacker Model
>
> The "most important recommendations of the OAuth working group for
> every OAuth implementor" should be placed after the "Attacks and
> Mitigations" section.
>
This structure was chosen specifically to have the recommendations -
arguably the most important section for everyday users of OAuth - in the
front.
> "updated to account for the potentially _dynamic relationships
> involving multiple parties_".
That is not correct. Web attackers (A1) can participate in the protocol
as one or more users (resource owners) or clients. Of course, these can
collaborate between each other.

> considered in the "updated model".
>
This is considered in the model.
> to counter such an attack is another issue.
This as well.
> In another section, it should be mentioned that OAuth 2.0 is unable to
The problem is not that this type of collusion attack is not possible
under the model. The problem is it is not commonly expected that OAuth
protects against this type of attack.

-Daniel

> Stating that such an attack is "out of the scope" of OAuth 2.0 would
> not be an appropriate statement.
>

---

From: Denis <[email-masked]>
Date: Thu, 7 May 2020 14:46:05 +0200

Hi Daniel,

> refer to two different entities.

RFC 6749 contains the two following definitions:

resource owner
       An entity capable of granting access to a protected resource.
       When the resource owner is a person, it is referred to as an
       end-user.

client
       An application making protected resource requests *on behalf of the**
**      resource owner and* with its authorization.  The term "client" does
       not imply any particular implementation characteristics (e.g.,
       whether the application executes on a server, a desktop, or other
       devices).

The original definition of a client does not appear to be adequate any more.
It is questionable whether the definition of a client from RFC 6749 
should be reused word-to-word.

The original definition of a client mentions the resource owner and 
misses to mention the authorisation server.
I wonder whether the use of the wording "on behalf of the resource 
owner" is really adequate. A client is not
impersonating the resource owner.

A client is an application *using an authorisation server *for 
performing protected resource requests
that will be granted or not by a resource owner.

A new definition for the term client should be adopted for this 
document.  However, you are right, the two wordings shall remain.

>> it is important to understand what the problems are. The Updated 
>> OAuth 2.0 Attacker model should be placed after the introduction.
>>
> arguably the most important section for everyday users of OAuth - in 
> the front.

This means that most readers will only read the recommendations section 
placed upfront and are likely to ignore the other sections,
in particular the Updated OAuth 2.0 Attacker Model. They will thus kept 
ignorant of attacks that cannot be countered using the "Best Practices".
They may then believe that their implementations are secure whereas it 
will not be the case.

>> However, it still misses to address the case of _dynamic 
>> relationships between clients_, which include scenarios of 
>> _collaborative clients_.
>>
> That is not correct. Web attackers (A1) can participate in the 
> protocol as one or more users (resource owners) or clients. Of course, 
> these can collaborate between each other.
>
Section 3 states:

*OAuth MUST ensure that* the authorization of the resource owner (RO)  
(with a user agent) at the authorization server (AS) and
    the subsequent usage of the access token at the resource server (RS) 
*is protected _at least_ against the following attackers*:

   *  (A1) *Web Attackers *(...)

If a collaboration / collusion between clients were covered under this 
case, then it would mean that *OAUTH MUST provide a protection for it*,
whereas this is technically impossible.

Since AOuth is unable to protect against a collusion attack between 
clients, the collusion attack cannot belong to this section, in 
particular under (A1).

Section 3 is confusing the threat model with the resistance of OAuth to 
these threats.

At this time, an RFC reader may not catch the fact that a collusion 
attack between clients may ever exist and thus may not
grasp the fact that this kind of attack cannot be countered by OAuth, 
even when following the Best Practices.

The "Updated OAuth 2.0 Attacker Model" does not take into "account for 
the potentially _dynamic relationships involving multiple parties_".
as it is advertised, in particular the case of _dynamic relationships 
between clients_ which include the case of _collaborative clients_.

The text currently does not  incorporate words like "collusion", 
"colluding", whereas it should. The text should clearly indicate that
a protection against a collusion between clients is currently not 
possible using OAuth.

> This is considered in the model.

See my comments above. While promised by the text, the case of 
collaborative clients is not considered in the model.

>> which are human beings, it cannot be assumed that all the human 
>> beings in the world will necessary be honest. Whether or not Auth 2.0 
>> is able or not

As said above, the model should only express the threats (or the 
possible attacks) and another section should indicate which threats 
cannot countered.

>> In another section, it should be mentioned that OAuth 2.0 is unable 
>> to counter such an attack.
>>
RFC readers who have not followed or participated to this thread will 
not necessarily know that OAuth does not protect against this type of 
attack.

The purpose of this document is to inform the reader about _all_ known 
types of attacks, whether they can be defeated or not by OAuth 2.0.

Denis

---

From: Daniel Fett <[email-masked]>
Date: Thu, 7 May 2020 18:22:52 +0200

Hi Denis,

Am 07.05.20 um 14:46 schrieb Denis:
> (...)
I cannot follow any of this, sorry.

>> protocol as one or more users (resource owners) or clients. Of
>> course, these can collaborate between each other.
>>
> Section 3 states:
>
>    *OAuth MUST ensure that* the authorization of the resource owner
> (RO)  (with a user agent) at the authorization server (AS) and
>    the subsequent usage of the access token at the resource server
> (RS) *is protected _at least_ against the following attackers*:
>
You are confusing the attacker model with the security goals (aka
security properties).

A commonly accepted security property for OAuth would be:

"An attacker should not be able to obtain access to or use a protected
resource protected by an uncompromised AS if that resource is only used
by an honest user with an uncompromised client and user agent."

(roughly equivalent to the one in
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

Being resistant to collusion attacks is not a commonly accepted/expected
security property.

So: Yes, attackers are free to collude, and that is part of the model.
No, that is not a problem, as they are not breaking anything anyone
would expect.

-Daniel

> Section 3 is confusing the threat model with the resistance of OAuth
> to these threats.
>
>>> beings in the world will necessary be honest. Whether or not Auth
>>> 2.0 is able or not
>> under the model. The problem is it is not commonly expected that
>> OAuth protects against this type of attack.
>>

---

From: Denis <[email-masked]>
Date: Fri, 8 May 2020 11:22:58 +0200

Hi Daniel,

Thank you for pointing to your dissertation which has the following 
title : An Expressive Formal Model of the Web Infrastructure.

Since it is 240 pages long (or thick), I have not read everything but 
some sentences brought my attention.

I have experienced formal models in the past and everything depends upon 
the hypothesis that are made upfront.

On page 28:

    1.1.1. The Web Infrastructure Model

    (...)
    Altogether, the model is the *most comprehensive and detailed model
    for the web infrastructure to date* [i.e. in year 2018].
    (...)

On page 40, there is the following sentence:

    *A browser is thought to be used by one honest user*, who is modeled
    as part of the browser.

With such an hypothesis, it is impossible to consider a collusion attack 
between clients, hence the Model omits to consider such a case.
When using a formal approach, it is generally not possible to make sure 
that all attacks have been considered, but when considering
specific attacks, it is possible to demonstrate that they can be 
countered (or not).

Many models are considering "adversaries". This originates from the 
"Alice, Bob and Carol model" where both Alice and Bob
were honest and where Carol was the attacker. In the case of the "Alice 
and Bob Collusion attack", Alice and Bob are good friends.
The target of the attack is a RS. The RS is not an adversary : it does 
nothing bad. Alice and Bob are adversaries towards Carol (the RS).
This can bee seen as the revenge of "Alice and Bob" against Carol.  :-)

On page 29, the text states:

    Model of OAuth 2.0

    Using our generic web model, we build a formal model of OAuth,
    closely following the OAuth 2.0 standard [RFC6749].

On page 72, Figure 3.1 there is a diagram flow that is rather different 
from the diagram flow that is present in RFC 6749 Figure 1.
In Figure 3.1,  an entity combines the roles of the AS and the RS 
whereas in Figure 1 : Abstract Protocol Flow (Page 7), these two
roles are under the control of two separate entities. This means that 
the formal Model of OAuth is NOT closely following the OAuth 2.0
standard [RFC 6749].

On page 29, the text continues with:

    Our model includes clients and AS/RS that (simultaneously) support
    all four modes of operation available in OAuth and
    *can be dynamically corrupted by the adversary*.

With the ABC attack, clients are not /dynamically corrupted by an 
adversary/, since Alice and Bob voluntarily cooperate to achieve
a common goal: to cheat a RS. As a consequence, the dissertation does 
not consider collaborative clients or collusion between clients.

The same problem appeared with the ABC4Trust EU project (Attribute-based 
Credentials for Trust) which has now ended.
*U-Prove* from Microsoft and *Identity Mixer* from IBM were used as a 
demonstrating technology of the principles.
However during the project, no one ever considered the case of the Alice 
and Bob collusion attack. So all experts involved
in this project believed that these two technologies were secure, 
whereas they were not, even when smart cards were being used.

You wrote :

    " A commonly accepted security property for OAuth would be:

       An attacker should not be able to obtain access to or use a
    protected resource protected by an uncompromised AS
       if that resource is only used by an honest user with an
    uncompromised client and user agent."

This sentence has nothing to do with a "security property". This term is 
defined in ISO/IEC TS 19249:2017, 3.1:

    *security property*
    *property* of a system or application *that is crucial to achieve
    the security objectives defined for the system or application*

On the contrary, it is *c**rucial to prevent collaborative users to 
cheat a RS using an uncompromised AS*.

You also wrote:

    Being resistant to collusion attacks is not a commonly
    accepted/expected security property.

Being resistant to collusion attacks is indeed a security property.

Considering only honest users is an hypothesis that does not correspond 
to the real world. Currently, when reading the current document
even through the lines, it is impossible to guess that the ABC attack 
may ever exist.

Now, the question is : Is OAuth 2.0 able to meet such a property ? I 
read again my previous emails and the answer is ... *YES*.

I considered two cases:

    a) When the JWT contains one or more attributes that uniquely allow
    to identify the collaborative user, then the other client
    will be in a position to impersonate the collaborative user. There
    is no advantage for Alice because she will simply be able to
    impersonate Bob and she will not take any advantage of the
    attributes from Bob for herself.

    b) When the JWT does not contain a sufficient number of attributes
    that would allow to identify the user,
    the collaborative user can transmit it to anybody else, without the
    risk to be detected by the RS.  E.g. it
    only contains the age of the user and a membership to a large group
    of people. This case can only be countered
    using secure elements with specific properties.

When the token contains one or more attributes that uniquely allow to 
identify the collaborative user (e.g. a "sub" claim),
then Alice can only impersonate the collaborative user and such a case 
can easily be obtained using TeamViewer.

      * Unfortunately using the "sub" claim is not "privacy friendly",
        since collaborative RSs will be able to link the accounts
        of their respective users.  Nevertheless, this a good news for
        Vittorio, since the "sub" claim is REQUIRED in the
        "Profile for OAuth 2.0 Access Tokens". This means that, *when
        this profile is being used, OAuth 2.0 is resistant **to
        the ABC attack*.

      * Using a different claim that would only contain an identifier
        that is unique to the RS (such as a pseudo) would be
        more appropriate (as FIDO does), but I am not aware of a claim
        that has been defined which would have such a semantics.

The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships
involving multiple parties_. As explained above, this is not the case 
for clients since multiple clients have not been considered.
This is also not the case for RSs since multiple RSs have not been 
considered.

Anyway, in order to correctly explain the cases, there needs to be a 
discussion in this document both about the ABC attack
_and_ the content of the token. There should also be a discussion about 
multiple RSs where an RS attempts to forward a received token
to another RS. Even if the countermeasure is obvious, it should be 
mentioned in this document.

To summarize my findings about the dissertation, it is not able to 
address these cases since it only consider attackers that can either be :

  * "Web attackers (who can listen to and send messages from their own
    addresses only)" or
  * "Network attackers (who may listen to and spoof all addresses and
    therefore are the most powerful attackers)".

Denis

>>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have 
>>>> been "updated to account for the potentially _dynamic relationships 
>> If a collaboration / collusion between clients were covered under 
>> this case, then it would mean that *OAUTH MUST provide a protection 
>> for it*,
> resource protected by an uncompromised AS if that resource is only 
> used by an honest user with an uncompromised client and user agent."
>
> Being resistant to collusion attacks is not a commonly 
> accepted/expected security property.
>
>> The "Updated OAuth 2.0 Attacker Model" does not take into "account 
>> for the potentially _dynamic relationships involving multiple parties_".
>>> The problem is not that this type of collusion attack is not 
>>> possible under the model. The problem is it is not commonly expected 
>>> that OAuth protects against this type of attack.
>>>
>> The purpose of this document is to inform the reader about _all_ 
>> known types of attacks, whether they can be defeated or not by OAuth 2.0.
>>
>> Denis
>>
>>> -Daniel
>>>
>>>> Stating that such an attack is "out of the scope" of OAuth 2.0 
>>>> would not be an appropriate statement.
>>>>

---

From: Janak Amarasena <[email-masked]>
Date: Wed, 13 May 2020 11:20:56 +0530

Hi All,

In section *4.1.3. Countermeasures
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.1.3>*
related to *4.1.  Insufficient Redirect URI Validation* it states

   The complexity of implementing and managing pattern matching
   correctly obviously causes security issues.  This document therefore
   advises to simplify the required logic and configuration by using
   exact redirect URI matching only.  This means the authorization
   server MUST compare the two URIs using simple string comparison as
   defined in [RFC3986], Section 6.2.1
<https://tools.ietf.org/html/rfc3986#section-6.2.1>.

Does this mean that the authorisation server MUST NOT use pattern matching
at all and MUST do simple string comparison for redirect URI?
If that is the case can we change the wording a bit in this section as
having "...therefore *advises* to simplify the required logic..." gives the
impression that the AS has the choice to decide whether or not to use
pattern matching. And then when we have "...authorization server *MUST*
compare the two URIs using simple string..." give the impression that the
AS should absolutely not(MUST NOT) use pattern matching.

Best Regards,
Janak Amarasena

On Fri, May 8, 2020 at 2:53 PM Denis <[email-masked]> wrote:

> Hi Daniel,
>
> Thank you for pointing to your dissertation which has the following title
> : An Expressive Formal Model of the Web Infrastructure.
>
> Since it is 240 pages long (or thick), I have not read everything but some
> sentences brought my attention.
>
> Altogether, the model is the *most comprehensive and detailed model for
> the web infrastructure to date* [i.e. in year 2018].
> (...)
>
> *A browser is thought to be used by one honest user*, who is modeled as
> part of the browser.
>
>
> specific attacks, it is possible to demonstrate that they can be countered
> (or not).
>
> Using our generic web model, we build a formal model of OAuth, closely
> following the OAuth 2.0 standard [RFC6749].
>
> In Figure 3.1,  an entity combines the roles of the AS and the RS whereas
> in Figure 1 : Abstract Protocol Flow (Page 7), these two
> roles are under the control of two separate entities. This means that the
> formal Model of OAuth is NOT closely following the OAuth 2.0
> standard [RFC 6749].
>
> Our model includes clients and AS/RS that (simultaneously) support all
> four modes of operation available in OAuth and
> With the ABC attack, clients are not *dynamically corrupted by an
> adversary*, since Alice and Bob voluntarily cooperate to achieve
> a common goal: to cheat a RS. As a consequence, the dissertation does not
> consider collaborative clients or collusion between clients.
>
> in this project believed that these two technologies were secure, whereas
> they were not, even when smart cards were being used.
>
> You wrote :
>
>   An attacker should not be able to obtain access to or use a protected
> resource protected by an uncompromised AS
>   if that resource is only used by an honest user with an uncompromised
> client and user agent."
>
> *property* of a system or application *that is crucial to achieve the
> security objectives defined for the system or application*
>
> On the contrary, it is *c**rucial to prevent collaborative users to cheat
> a RS using an uncompromised AS*.
>
> You also wrote:
>
> Considering only honest users is an hypothesis that does not correspond to
> the real world. Currently, when reading the current document
> even through the lines, it is impossible to guess that the ABC attack may
> ever exist.
>
> Now, the question is : Is OAuth 2.0 able to meet such a property ? I read
> again my previous emails and the answer is ... *YES*.
>
> I considered two cases:
>
> a) When the JWT contains one or more attributes that uniquely allow to
> identify the collaborative user, then the other client
> will be in a position to impersonate the collaborative user. There is no
> advantage for Alice because she will simply be able to
> impersonate Bob and she will not take any advantage of the attributes from
> Bob for herself.
>
> b) When the JWT does not contain a sufficient number of attributes that
> would allow to identify the user,
> the collaborative user can transmit it to anybody else, without the risk
> to be detected by the RS.  E.g. it
> only contains the age of the user and a membership to a large group of
> people. This case can only be countered
> then Alice can only impersonate the collaborative user and such a case can
> easily be obtained using TeamViewer.
>
>
>    - Unfortunately using the "sub" claim is not "privacy friendly", since
>    collaborative RSs will be able to link the accounts
>    "Profile for OAuth 2.0 Access Tokens". This means that, *when this
>    profile is being used, OAuth 2.0 is resistant *
> *to the ABC attack*.
>
>    - Using a different claim that would only contain an identifier that
>    is unique to the RS (such as a pseudo) would be
>    more appropriate (as FIDO does), but I am not aware of a claim that
>    has been defined which would have such a semantics.
>
> The "*Updated *OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially
> *dynamic relationships involving multiple parties*. As explained above,
> this is not the case for clients since multiple clients have not been
> considered.
> *and* the content of the token. There should also be a discussion about
> To summarize my findings about the dissertation, it is not able to address
> these cases since it only consider attackers that can either be :
>
>    - "Web attackers (who can listen to and send messages from their own
>    addresses only)" or
>    - "Network attackers (who may listen to and spoof all addresses and
> A new definition for the term client should be adopted for this document.
> However, you are right, the two wordings shall remain.
>
> 3) The "*Updated *OAuth 2.0 Attacker Model" is supposed to have been
> "updated to account for the potentially *dynamic relationships involving
> multiple parties*".
> However, it still misses to address the case of *dynamic relationships
> between clients*, which include scenarios of *collaborative clients*.
>
> That is not correct. Web attackers (A1) can participate in the protocol as
> one or more users (resource owners) or clients. Of course, these can
>    the subsequent usage of the access token at the resource server (RS) *is
> protected at least against the following attackers*:
>
> You are confusing the attacker model with the security goals (aka security
> properties).
>
> resource protected by an uncompromised AS if that resource is only used by
> an honest user with an uncompromised client and user agent."
>
> So: Yes, attackers are free to collude, and that is part of the model. No,
> that is not a problem, as they are not breaking anything anyone would
> expect.
>
> -Daniel
>
>
> clients, the collusion attack cannot belong to this section, in particular
> under (A1).
>
> At this time, an RFC reader may not catch the fact that a collusion attack
> between clients may ever exist and thus may not
> grasp the fact that this kind of attack cannot be countered by OAuth, even
> when following the Best Practices.
>
> the potentially *dynamic relationships involving multiple parties*".
> as it is advertised, in particular the case of *dynamic relationships
> between clients* which include the case of *collaborative clients*.
>
> a protection against a collusion between clients is currently not possible
> using OAuth.
>
> Such a collaboration between clients is possible and should be considered
> in the "updated model".
>
> which are human beings, it cannot be assumed that all the human beings in
> the world will necessary be honest. Whether or not Auth 2.0 is able or not
> As said above, the model should only express the threats (or the possible
> attacks) and another section should indicate which threats cannot
> countered.
>
> RFC readers who have not followed or participated to this thread will not
> necessarily know that OAuth does not protect against this type of attack.
>
> The purpose of this document is to inform the reader about *all* known
> It should not be forgotten, that the purpose of this document is to inform
> the reader about *all* the relevant security issues.
>
> Denis
>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>
> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>
> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Jared L Jennings <[email-masked]>
Date: Fri, 15 May 2020 22:48:05 -0500

To add to that, should it include the words "case sensitive" (if that is 
what is meant by exact), Although, URL's are not case sensitive in all 
cases, (IIS vs. Tomcat) which makes me think that specifying the case 
sensitivity is wise.

On 5/13/20 00:50, Janak Amarasena wrote:
>     defined in[RFC3986], Section 6.2.1  <https://tools.ietf.org/html/rfc3986#section-6.2.1>.
> Does this mean that the authorisation server MUST NOT use pattern 
> matching at all and MUST do simple string comparison for redirect URI?
> having "...therefore *advises* to simplify the required logic..." 
> gives the impression that the AS has the choice to decide whether or 
> not to use pattern matching. And then when we have "...authorization 
> server *MUST* compare the two URIs using simple string..." give the 
> impression that the AS should absolutely not(MUST NOT) use pattern 
> matching.

-- 
-----
Jared L Jennings