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

[Warren Parad]

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

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

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.

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
Secure your user data with IAM authorization as a service. Implement
Authress .


On Mon, Mar 1, 2021 at 9:13 PM Phillip Hallam-Baker 
wrote:

> 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.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hallam-Baker]

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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

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
phil.h...@independentid.com




> On Mar 1, 2021, at 8:32 AM, Jim Manico  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
> 
> 
> 
> On 3/1/21 9:59 AM, Vittorio Bertola wrote:
>> 
>>> Il 01/03/2021 15:13 Jim Manico  
>>>  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
>> vittorio.bert...@open-xchange.com  
>> Office @ Via Treviso 12, 10144 Torino, Italy
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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


On 3/1/21 9:59 AM, Vittorio Bertola wrote:



Il 01/03/2021 15:13 Jim Manico  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
vittorio.bert...@open-xchange.com    
Office @ Via Treviso 12, 10144 Torino, Italy


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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertola]

> Il 01/03/2021 15:13 Jim Manico  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
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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  
> wrote:
> 
> 
> On 01/03/2021 10:44 Vittorio Bertola  
> wrote:
>  
> > Il 26/02/2021 17:32 Aaron Parecki  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
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth