Thanks Justin & Annabelle!
On Mon, Oct 28, 2019 at 2:35 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:
> Justin had requested that I present on some non-authorization use cases
> for something like XYZ. This shouldn’t take more than 15 minutes.
>
>
>
> –
>
> Annabelle Richard Backman
I would like to discuss XYZ, to give a quick background and update to the
project. I project that to take about 20 min if we dive right into the gritty
details. I can also do a level-set for the BoF, like 10min.
— Justin
> On Oct 28, 2019, at 11:39 AM, Dick Hardt wrote:
>
> Hey OAuthers
>
>
Unclear what I was smoking when I said when the BoF was. It is at
13:30-15:30 per https://datatracker.ietf.org/meeting/106/agenda
Sorry for any confusion.
On Mon, Oct 28, 2019 at 8:39 AM Dick Hardt wrote:
> Hey OAuthers
>
> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM M
Got it. Thanks. I'll shop around for another venue.
On Mon, Oct 28, 2019, 4:57 PM Justin Richer wrote:
> The intended scope is to provide a transactional model for doing
> authorization delegation, not for authenticating a transaction itself. I
> can understand the confusion! Naming things is ha
The intended scope is to provide a transactional model for doing authorization
delegation, not for authenticating a transaction itself. I can understand the
confusion! Naming things is hard.
— Justin
> On Oct 28, 2019, at 1:55 PM, Kyle Rose wrote:
>
> On Mon, Oct 28, 2019 at 11:39 AM Dick H
When working on the Token Binding TTRP draft I guess I saw the advantage as
being the simplicity or setting, sanitizing, and reading an independent
header that's only conveying the token binding info about the TLS
connection between the "outside" client/browser and the proxy, (which is
the applicat
* To avoid the misconfiguration issue Neil raised, you probably need both:
a client-cert and a signature over the certificate being forwarded,
I am not so sure. One can argue that transport-level identity should be
secured by transport-level. But installing a client certificate on a revers
On Mon, Oct 28, 2019 at 12:48 PM Salz, Rich wrote:
> Sorry for jumping into this late.
>
>
>
> Client <--> proxy <--> backend
>
>
>
> The C/P side is protected by TLS. There must be similar protection on the
> P/B side, such as client-cert, or a signature over the certificate being
> forwarded,
My understanding was it was transaction authorization.
(it is unfortunate that authorization and authentication both start with
'auth' in english - 'authN' and 'authZ' are preferred to 'auth' IMHO)
On Mon, Oct 28, 2019 at 10:55 AM Kyle Rose wrote:
> On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt
On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt wrote:
> Hey OAuthers
>
> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday
> Afternoon, I'm gathering who would be interested in making presentations,
> and how much time you would like.
>
Is this BoF limited to authorizatio
Got it. Thanks Torsten!
On Mon, Oct 28, 2019 at 10:44 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Dick,
>
> Justin asked me to shed some light on the rationale and current status of
> the work on OAuth Rich & Pushed Authorization Requests. I think I will need
> 20 min.
>
> best
Hi Dick,
Justin asked me to shed some light on the rationale and current status of the
work on OAuth Rich & Pushed Authorization Requests. I think I will need 20 min.
best regards,
Torsten.
> On 28. Oct 2019, at 16:39, Dick Hardt wrote:
>
> Hey OAuthers
>
> As chair of the Tx BOF coming up
Sorry for jumping into this late.
Client <--> proxy <--> backend
The C/P side is protected by TLS. There must be similar protection on the P/B
side, such as client-cert, or a signature over the certificate being forwarded,
right?
___
OAuth mailing li
While there are some benefits to standardizing headers for this kind of
communication, there are some significant downsides - particularly when using
headers to communicate critical security information like certs. It is *very*
easy to misconfigure a reverse proxy to not strip Forwarded (or what
Ok, then we are on the same page.
The reason I am asking is that I have a use case where I need such a
mechanism.
What is the advantage you see for defining a new HTTP header over extending
RFC7239?
Regards,
Rifaat
On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell
wrote:
> I don't think there
Hey OAuthers
As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday
Afternoon, I'm gathering who would be interested in making presentations,
and how much time you would like.
/Dick
___
OAuth mailing list
OAuth@ietf.org
https://www
I don't think there's anything beyond defining something to carry the
client certificate information (including the format and encoding). And it
could well be a new RFC7239 parameter. Or it might just be a new HTTP
header on its own.
On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef
wrote:
> Th
Thanks Brian,
I guess my question is: given RFC7239 and the fact that it is
straightforward to secure the channel between the terminating reverse proxy
and the backend service in a cluster, is there anything, from a standard
perspective, that we need to do beyond defining a new parameter to carry
On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef
wrote:
>
> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell
> wrote:
>
>>
>> I did look at RFC7239 when doing that and it could have been made to work
>> but felt the fit wasn't quite right and would have been more cumbersome to
>> use than not.
>
19 matches
Mail list logo
