> On Aug 15, 2023, at 11:40 AM, Rodrigo Speller > <rspeller=40primosti.com...@dmarc.ietf.org> wrote: > > So, during the flight, I reflected on Matthias' insistence: "What could we be > missing?" Brilliantly, I think Matthias raised a very important and fixable > point: “That the user MUST allow the connection on both sides on the client > and on the provider.” > <snip> > > In this grant type, the AS would ask the user to sign evidence tokens to > authorize client application access in the authentication/consent phase. Of > course, this flow would require some restrictions to maintain a high degree > of security, such as: Generation and storage of user signature keys; Form of > registration of the signature verification key with the AS; Transport of > authorization evidence to the client application; Transporting the evidence > token signature verification key to the client application; etc;
I apologize, but I still do not get it. What is the deficiency? I am not sure but I might be asking - what do you imagine to be the connection from the AS to the client, given that the client is not expected to give access tokens, nor have protected resources? > > I believe that a Zero-Trust Grant Type with a model similar to the one above > would be very useful for Web 3, financial applications (FAPI / Open Banking), > etc. It would also encourage the use of private keys to authenticate users in > these environments, making room for the signing of operational tokens in the > future (out of scope). Private key authentication is very limited in these environments due to deployment challenges in general and in browsers in particular. These authorization tokens would be cryptographic messages to the client representing the user - e.g. authentication. The use of these as ‘proof’ of authorization would additionally mean the client would have to know how to correlate the ‘real’ user identity with the authorization proof - and not, say, a key that the AS generated as part of some manner of attack on the client. This implies a broadly shared user identity, possibly a global user identity. The sharing of a broadly correlatable user identity would be a significant privacy change. Presently, clients cannot correlate a user across implicit/code/device grants for opaque access tokens except by the business logic of the protected resource. However, from a delegated authorization standpoint even the working system seems to have dubious stakeholder value for a client. The client’s goal is (delegated) authorization to the protected resource. They usually don’t care if they got it via “super good” consent - getting consent is not their responsibility. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
