Yes that is quite a common deployment scenario. I think that is the way most
of the Open Banking implementations have deployed it currently.
The intent is to support that. One problem is that how the certificate is
transmitted to the application tends to be load balancer/reverse proxy spe
Thanks, and understood.
The privacy concerns are mostly around correlating activity of *clients*, which
may or may not reveal activity patterns of users using those clients. I don’t
know how much of a concern that is in reality, but thought it should be
mentioned.
A colleague also made the fol
I’ve just realised that “crit” is for headers while the “scope” claim is in the
payload, so a different approach would be needed in that case (or the scope
would need to be duplicated into the headers).
Kind regards,
Neil
--
> On Wednesday, Mar 28, 2018 at 4:41 pm, Neil Madden (mailto:neil.m
Thanks for the feedback. We will review your comments and reply.
One data point is that this will not be the only POP spec. The spec using
token binding vs mtls has better privacy properties. It is UK Open banking
that has pressed us to come up with a standard to help with interoperability.
Hi,
I have reviewed this draft and have a number of comments, below. ForgeRock have
not yet implemented this draft, but there is interest in implementing it at
some point. (Disclaimer: We have no firm commitments on this at the moment, I
do not speak for ForgeRock, etc).
1. https://tools.ietf.
