Subject: [OAUTH-WG] Assessing the negative effects of proposed standards

From: Andrew Campling <[email-masked]>
Date: Mon, 1 Mar 2021 11:09:09 +0000

On 01/03/2021 10:44 Vittorio Bertola <[email-masked]<mailto:[email-masked]>> wrote:

> Il 26/02/2021 17:32 Aaron Parecki <[email-masked]<mailto:[email-masked]>> ha scritto:

>> Dynamic client registration does exist in OAuth: https://tools.ietf.org/html/rfc7591

>> The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.

> This is indeed a matter of product design. I am active in an OIDC-based open identity project where the specs say that providers MUST accept dynamic client registration, without a pre-determined client secret. This is the only way to create a federation that can work on an Internet scale, with relying parties accepting identities managed by providers unknown to them. Then, of course, this also creates lots of opportunities for abuse: you end up in an email-like scenario in which you need ways to ascertain trust in unknown parties and decide whether you want to accept interoperating with them and believe the information they provide, which in turn depends a lot on your specific use case. But we think that that is preferrable to the centralization that is inherent in the original registration model.

I wonder whether proposed standards should be assessed for their negative properties, eg whether they are likely to exacerbate centralisation, much like security aspects are reviewed.  It may be that a given proposal might still go forward as the trade-offs are deemed worthwhile, however, they would at least be understood and, ideally, documented.  At present there seems to be an exorable drift towards centralisation which, in my view, has a detrimental impact on both resilience and privacy.  Such developments may satisfy the needs of their proponents but are unlikely to be in the long-term interests of end-users (RFC 8890) and, therefore, it would be helpful if this trend wasn’t made worse by the introduction of new standards.

Andrew Campling

---

From: Jim Manico <[email-masked]>
Date: Mon, 1 Mar 2021 09:13:17 -0500

How does OAuth harm privacy? This critical delegation use case is user driven, protects leaking user passwords to third party services, limits access to user account features and allows the user to cancel this relationship at any time?

OAuth2 provides more security and privacy than the previous solutions pre-OAuth which was to hand your Twitter credentials (or similar) to a third party service (OAuth clients) exposing your entire account, permanently, to OAuth clients.

OAuth2 radically improves upon this needed web functionality. I don’t see how moving from handing your creds over to a third party to OAuth2 workflows, harms either privacy or security. It improves upon them both.

Also, OAuth2 is hard. It’s a complicated protocol. Delegation is tough. But luckily most developers just need a basic understanding and proper utilization of third party libraries for this need and the ecosystem is is getting much better. For example, PKCE is now integrated into most OAuth libraries.

I advise this working group to take a class or two (as a group, together) from the experts here such as Dr. De Ryck and others so we are all on the same page about what modern OAuth2 solutions really look like and what the OAuth2 framework/protocol actually is.

I am not being combative or trying to hurt anyone when I say that I feel many of the commenters here do not understand the details of OAuth2 and what it’s for.

--
Jim Manico
@Manicode

> On Mar 1, 2021, at 6:10 AM, Andrew Campling <[email-masked]> wrote:
> 
> 
> On 01/03/2021 10:44 Vittorio Bertola <[email-masked]> wrote:
>  
> > Il 26/02/2021 17:32 Aaron Parecki <[email-masked]> ha scritto:
>  
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 1 Mar 2021 15:59:45 +0100 (CET)

>     Il 01/03/2021 15:13 Jim Manico <[email-masked]> ha scritto:
> 
> 
>     How does OAuth harm privacy?
> 
I think you are analyzing the matter at a different level.

If you start from a situation in which everyone is managing their own online identity and credentials, and end up in a situation in which a set of very few big companies (essentially Google, Apple and Facebook) are supplying and managing everyone's online credentials and logins, then [the deployment of] OAuth[-based public identity systems] is harming privacy.

Centralization is an inherent privacy risk. If you securely and privately deliver your personal information to parties that can monetize, track and aggregate it at scale, then you are losing privacy.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Denis <[email-masked]>
Date: Mon, 1 Mar 2021 16:29:12 +0100

Hello Jim,

Since you dared to raise the question: "*How does OAuth harm privacy* 
?", I need to respond. I changed the tile of the thread accordingly.

With OAuth, the RS must have a prior relationship with the AS (which is 
not scalable). When the client calls the AS,
the AS is able to know which is the RS and then is in a position to know 
which end-user is likely to access which RS.

When furthermore *token introspection* is being used, the AS is in a 
position to know exactly when an end-user
is performing an access to every RS. Some people would say that the AS 
is able to act as *Big Brother*.
While this might be acceptable within a single domain (i.e. all the 
users, ASs and RSs belong to the same organization
or company), this is a serious concern if/when used in general over the 
Internet in a multi-domain case.

Since the access tokens are considered to be opaque to the clients (and 
hence to the end-users), a client is not supposed
to verify which privileges have effectively been inserted into an access 
token, in particular whether a unique identifier
that would allow the RSs to correlate the accounts of their users has 
been maliciously added into every access token.

In your email you wrote:

    I don’t see how moving from handing your creds over to a third party
    to OAuth2 workflows, harms either privacy or security.

I hope that the facts mentioned above will allow you to see that OAuth 
does harm the user's privacy.

Denis

> If you start from a situation in which everyone is managing their own 
> online identity and credentials, and end up in a situation in which a 
> set of very few big companies (essentially Google, Apple and Facebook) 
> are supplying and managing everyone's online credentials and logins, 
> then [the deployment of] OAuth[-based public identity systems] is 
> harming privacy.
>
> Centralization is an inherent privacy risk. If you securely and 
> privately deliver your personal information to parties that can 
> monetize, track and aggregate it at scale, then you are losing privacy.
>
> -- 
>
> [email-masked]  <mailto:[email-masked]>

---

From: Jim Manico <[email-masked]>
Date: Mon, 1 Mar 2021 11:26:11 -0500

Denis,

 > With OAuth, the RS must have a prior relationship with the AS (which 
is not scalable).

I do not see this as a real problem since in almost every use case the 
RS and AS are the same provider. If they are not the same provider I 
would suggest federation (OIDC) as opposed to delegation (OAuth2) which 
are completely different standards even though they are built on top of 
the same framework.

 > When the client calls the AS, the AS is able to know which is the RS 
and then is in a position to know which end-user is likely to access 
which RS.

If you are using OAuth2 for delegation and the RS and AS are not the 
same provider then I feel you are using the wrong standard/framework.

 > When furthermore *token introspection* is being used

Token introspection in my opinion needs to go away. First of all it 
kills performance. It also leaks unnecessary information as you 
rightfully point out. I prefer to migrate to JWT's for this purpose and 
distribute public keys for services that need to verify tokens. Again, 
the  token introspection defeats the point of statelessness, a critical 
feature of modern services.

 > Since the access tokens are considered to be opaque to the clients 
(and hence to the end-users), a client is not supposed

In typical OAuth2 delegation flows, the user is agreeing to give a 
client a certain level of access to their account at the AS/RS provider. 
The user allows this. The user is saying I am giving ClientX access to 
features A, B and C in my account. Of course the client needs to see 
this in order to effectively communicate to the RS/AS provider. I do not 
see this as a problem. The user is specifically allowing it.

Denis, please keep going. I am not a top tier expert I am still 
learning. I would love to keep this conversation going.

Respectfully,

- Jim Manico

On 3/1/21 10:29 AM, Denis wrote:
> With OAuth, the RS must have a prior relationship with the AS (which 
> is not scalable). When the client calls the AS,
> the AS is able to know which is the RS and then is in a position to 
> know which end-user is likely to access which RS.
>
> or company), this is a serious concern if/when used in general over 
> the Internet in a multi-domain case.
>
> Since the access tokens are considered to be opaque to the clients 
> (and hence to the end-users), a client is not supposed
> to verify which privileges have effectively been inserted into an 
> access token, in particular whether a unique identifier
>     I don’t see how moving from handing your creds over to a third
>     party to OAuth2 workflows, harms either privacy or security.
>
>> set of very few big companies (essentially Google, Apple and 
>> Facebook) are supplying and managing everyone's online credentials 
>> and logins, then [the deployment of] OAuth[-based public identity 
>> systems] is harming privacy.
>>
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Jim Manico <[email-masked]>
Date: Mon, 1 Mar 2021 11:32:00 -0500

Vittorio,

I feel you are conflating OIDC with OAuth2. In delegation workflows, the 
AS/RS can be any company and the clients are approved registered 
clients. I use OAuth2 for many of my own consumer needs and there is an 
even distribution of use among many services. OAuth2 protects me. I no 
longer have to hand out my twitter credentials just because my 
conference website wants limited access to my twitter account. I can now 
give my conference website limited delagated access to my twitter 
account and cancel that relationship any time. For years I was forced to 
give up my banking credentials to services like Mint and that is no 
longer the case due to the OAuth2 financial extension (FAPI).

While OIDC is certainly centralizing identity to a few providers, a real 
problem, OAuth2 when used for delegation purposes does not have that 
same inherent risk.

Respectfully,

- Jim Manico

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Phil Hunt <[email-masked]>
Date: Mon, 1 Mar 2021 10:11:08 -0800

I think the IETF should look at three issues:

1.  HTTP Re-direct flows in support of workflows (eg MFA sign-on flows) - HTTP redirect is the single most complex part of OAuth2 and drove a lot of the OAuth2 Threat Model and the subsequent drafts such as PKCE.  Right now, OAuth takes the blame because of its extensive recommendations and corrections (e.g. PKCE) to handle requirements not unique to OAuth2.

2.  Authentication of client applications - enabling the ability to identify a returning client or provide an asserted identity still needs to be solved.  Token Binding seemed like the solution, but that’s stalled. Now what?  OAuth Dynamic registration is an example of how complex things can get without being able to identify a returning entity positively.  Can we make this as easy as TLS has been for authenticating servers?

3.  YETA - OAuth has spawned a number of parallel efforts (IoT, OIDC, ... and now GNAP).  Are these new profiles making generational improvements to replace OAuth2 or are they just adding more options and complexity to the mix? I point to ongoing developer confusion on the purpose and differences between OIDC and OAuth2. It is very clear to me, but why not to developers at large?  Could it be they don’t want to care?  Developers are still asking “why can’t I just use basic auth”?   There is a debate that specialization (by eliminating options) leads to simplicity and focus. But when specialization drives  YETA, it is really just more complexity.  Again, this suggests options 1 and 2 need to be looked at before OAuth2 and its flavors can improve.   Is it time to work on bringing all of these together on top of a new HTTP workflow framework?

Cheers,

Phil Hunt
@independentid
[email-masked]

> On Mar 1, 2021, at 8:32 AM, Jim Manico <[email-masked]> wrote:
> 
> Vittorio,
> 
> I feel you are conflating OIDC with OAuth2. In delegation workflows, the AS/RS can be any company and the clients are approved registered clients. I use OAuth2 for many of my own consumer needs and there is an even distribution of use among many services. OAuth2 protects me. I no longer have to hand out my twitter credentials just because my conference website wants limited access to my twitter account. I can now give my conference website limited delagated access to my twitter account and cancel that relationship any time. For years I was forced to give up my banking credentials to services like Mint and that is no longer the case due to the OAuth2 financial extension (FAPI).
> 
> While OIDC is certainly centralizing identity to a few providers, a real problem, OAuth2 when used for delegation purposes does not have that same inherent risk.
> 
> Respectfully,
> 
> - Jim Manico
> 
> 
> 
>>> Il 01/03/2021 15:13 Jim Manico <[email-masked]> <mailto:[email-masked]> ha scritto:
>>> 
>>> 
> https://www.manicode.com <https://www.manicode.com/>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Warren Parad <[email-masked]>
Date: Mon, 1 Mar 2021 19:20:35 +0100

👏

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Mon, Mar 1, 2021 at 5:27 PM Jim Manico <[email-masked]> wrote:

> not scalable).
> I do not see this as a real problem since in almost every use case the RS
> and AS are the same provider. If they are not the same provider I would
> suggest federation (OIDC) as opposed to delegation (OAuth2) which are
> completely different standards even though they are built on top of the
> same framework.
>
> > When the client calls the AS, the AS is able to know which is the RS and
> then is in a position to know which end-user is likely to access which RS.
>
> If you are using OAuth2 for delegation and the RS and AS are not the same
> provider then I feel you are using the wrong standard/framework.
>
> Token introspection in my opinion needs to go away. First of all it kills
> performance. It also leaks unnecessary information as you rightfully point
> out. I prefer to migrate to JWT's for this purpose and distribute public
> keys for services that need to verify tokens. Again, the  token
> introspection defeats the point of statelessness, a critical feature of
> modern services.
>
> that would allow the RSs to correlate the accounts of their users has been
> maliciously added into every access token.
>
> In typical OAuth2 delegation flows, the user is agreeing to give a client
> a certain level of access to their account at the AS/RS provider. The user
> allows this. The user is saying I am giving ClientX access to features A, B
> and C in my account. Of course the client needs to see this in order to
> effectively communicate to the RS/AS provider. I do not see this as a
> problem. The user is specifically allowing it.
>
> Denis, please keep going. I am not a top tier expert I am still learning.
> I would love to keep this conversation going.
>
> Respectfully,
>
> - Jim Manico
>
>
> Since you dared to raise the question: "*How does OAuth harm privacy* ?",
> I need to respond. I changed the tile of the thread accordingly.
>
> is performing an access to every RS. Some people would say that the AS is
> able to act as *Big Brother*.
> While this might be acceptable within a single domain (i.e. all the users,
> ASs and RSs belong to the same organization
> that would allow the RSs to correlate the accounts of their users has been
> maliciously added into every access token.
>
> In your email you wrote:
>
> I don’t see how moving from handing your creds over to a third party to
> OAuth2 workflows, harms either privacy or security.
>
> Il 01/03/2021 15:13 Jim Manico <[email-masked]> <[email-masked]> ha
> scritto:
>
>
> online identity and credentials, and end up in a situation in which a set
> of very few big companies (essentially Google, Apple and Facebook) are
> supplying and managing everyone's online credentials and logins, then [the
> deployment of] OAuth[-based public identity systems] is harming privacy.
>
> Centralization is an inherent privacy risk. If you securely and privately
> deliver your personal information to parties that can monetize, track and
> aggregate it at scale, then you are losing privacy.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, [email-masked]
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Mar 2021 15:11:46 -0500

Lets take a step back. There are two separate sets of concerns related to
'privacy'

1) Disclosure of an identifier allows a service attack using that
identifier.

2) Linking separate uses of an identifier allows a profile to be
constructed of the individual that can be used against the interest of the
individual.

The reason I insist on this distinction is that privacy issues of the first
type are a consequence of crappy protocol design. There is absolutely no
reason why giving someone my bank details so they can send a payment TO me
should give them the ability to withdraw money from my account. But it does
and the banks will smugly gaslight that it just isn't possible to fix this
elementary flaw in their information architectures. And you can guess where
it came from if you hear the question being asked in the relevant Senate
hearing of the form, 'Mr CEO, you say that it would be impossible to make
this change, what size of penalty per loss are we going to have to impose
on your bank to make it cheaper for you to fix it than to claim it can't be
done?'

It should be possible for Madonna or Lewis Hamilton to put their personal
contact info on their Web sites without ending up being spammed to
oblivion. It is just a question of access control.

The second is a really difficult problem but authentication is only one
small part of it. I can turn out a public key authentication scheme that
allows Alice to surf the web at Bob and Carol's site without them being
able to tell its the same person from the identifier easily enough. But all
bets are off if Bob and Alice collude.

---

From: Warren Parad <[email-masked]>
Date: Mon, 1 Mar 2021 21:43:23 +0100

> 1) Disclosure of an identifier allows a service attack using that

Sure, would you be able to say more about this though, I'm not sure I'm
fully grasping the consequence here.

> constructed of the individual that can be used against the interest of the

But isn't the user aware that the AS is sharing with the client the same
identifier and therefore will be tracked. Isn't it their prerogative if
they want to be and then decide whether to do that or not? There are lots
of cases I want the different clients to know how to track me and other
cases where I don't want that. It would just seem to be of poor design that
this decision is not provided as a fundamental property of the AS being
used rather than an aspect of OAuth, OIDC, or anything else, right?

Two parties that collude may always be able to figure out if an entity is
the same identity in those clients, it sounds like we are saying there is
something that could have been done to actively prevent that. But I'm not
following what that is.

I also find the US banking system of routing number + account
Id deplorable, but I don't see what that has to do with our discussion.

Warren Parad

Founder, CTO

On Mon, Mar 1, 2021 at 9:13 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> The reason I insist on this distinction is that privacy issues of the
> first type are a consequence of crappy protocol design. There is absolutely
> no reason why giving someone my bank details so they can send a payment TO
> me should give them the ability to withdraw money from my account. But it
> does and the banks will smugly gaslight that it just isn't possible to fix
> this elementary flaw in their information architectures. And you can guess
> where it came from if you hear the question being asked in the relevant
> Senate hearing of the form, 'Mr CEO, you say that it would be impossible to
> make this change, what size of penalty per loss are we going to have to
> impose on your bank to make it cheaper for you to fix it than to claim it
> can't be done?'
>