Re: [OAUTH-WG] [UNVERIFIED SENDER] OAuth Topics for Vancouver

[Richard Backman, Annabelle]

To be honest I’m somewhat taken aback by this reaction. The request was for 
time to discuss an alternative PoP mechanism face-to-face. This is a topic 
which has come up in the context of other work (e.g., DPoP) at several recent 
IETF meetings, including the last one in Singapore. While I recognize that the 
working group has a lot on its plate and needs to allocate time judiciously, it 
seems clear to me that this is both timely and relevant.

Unless the chairs indicate that they require further justification for the time 
slot, I’m going to stop cluttering this thread with defenses of a draft that 
doesn’t exist yet.

–
Annabelle Richard Backman
AWS Identity


From: Rob Cordes 
Date: Monday, January 20, 2020 at 1:38 PM
To: "Richard Backman, Annabelle" 
Cc: Rifaat Shekh-Yusef , oauth 
Subject: Re: [UNVERIFIED SENDER] [OAUTH-WG] OAuth Topics for Vancouver

Hi Annabelle,


Sure TLS is not th one size fits all but if you swap out Client Y signs / 
authenticates message A to recipient X  by:  Client  Y uses TLS for 
authentication of the source (itself), integrity of data / communications and  
even confidentiality (not really needed in our HTTP signing use case)  where 
TLS is initiated and handled by the client Y  itself (native libs or proxy at 
the same host(s) then you have precisely that what HTTP Message signing should 
do. (authenticity,  integrity and as a bonus confidentiality).


That said, one can opt for HTTP signing if one wants to, except it is not 
secure for now and is at present for many developers a nuisance use  as it 
turns out. If you do not want  or cannot deal with TLS tunnels and yes indeed 
TLS connection re-use, by all means go ahead. I would advise my customers to 
try TLS first because it is proven and simple to implement and so easy (cheap 
;-) ) to support. It is always worthwhile to at least try to get Infra on board 
to see if one can go the TLS route first and if that fails… well then HTTP 
signing or accept the risk.

The issues we have at ING with 3rd parties cause us to back down from using it 
in general but still for those API’s wanting to have better assurance than 
otherwise. We do not want to provide our own libs to external parties for 
obvious (legal mostly) reasons. We did not go the TLS route at first, that 
turned out a mistake ;-).


Let me conclude that I always am quite happy to see alternatives popping up and 
existing protocols being continuously enhanced. For this I thank you and others 
to continue developing protocol implementations such as HTTP message signing.


Regards,

Rob



On 20 Jan 2020, at 21:50, Richard Backman, Annabelle 
mailto:richa...@amazon.com>> wrote:

introduction to the HTTP Message Signatures 
draft<https://tools.ietf.org/html/draft-richanna-http-message-signatures-00#section-1>

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] OAuth Topics for Vancouver

[Rob Cordes]

Hi Annabelle,


Sure TLS is not th one size fits all but if you swap out Client Y signs / 
authenticates message A to recipient X  by:  Client  Y uses TLS for 
authentication of the source (itself), integrity of data / communications and  
even confidentiality (not really needed in our HTTP signing use case)  where 
TLS is initiated and handled by the client Y  itself (native libs or proxy at 
the same host(s) then you have precisely that what HTTP Message signing should 
do. (authenticity,  integrity and as a bonus confidentiality). 


That said, one can opt for HTTP signing if one wants to, except it is not 
secure for now and is at present for many developers a nuisance use  as it 
turns out. If you do not want  or cannot deal with TLS tunnels and yes indeed 
TLS connection re-use, by all means go ahead. I would advise my customers to 
try TLS first because it is proven and simple to implement and so easy (cheap 
;-) ) to support. It is always worthwhile to at least try to get Infra on board 
to see if one can go the TLS route first and if that fails… well then HTTP 
signing or accept the risk.

The issues we have at ING with 3rd parties cause us to back down from using it 
in general but still for those API’s wanting to have better assurance than 
otherwise. We do not want to provide our own libs to external parties for 
obvious (legal mostly) reasons. We did not go the TLS route at first, that 
turned out a mistake ;-). 


Let me conclude that I always am quite happy to see alternatives popping up and 
existing protocols being continuously enhanced. For this I thank you and others 
to continue developing protocol implementations such as HTTP message signing.


Regards,

Rob


> On 20 Jan 2020, at 21:50, Richard Backman, Annabelle  
> wrote:
> 
> introduction to the HTTP Message Signatures draft 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth