Subject: [OAUTH-WG] OAuth Topics for Vancouver

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 20 Jan 2020 10:32:44 -0500

All,

Please, let us know if you have any topics that you would like to present
and discuss in Vancouver.

Regards,
 Rifaat & Hannes

---

From: Daniel Fett <[email-masked]>
Date: Mon, 20 Jan 2020 17:03:25 +0100

Hi!

I would like to discuss DPoP, the Security BCP, and give a brief update
about the activities at the FAPI working group.

-Daniel

Am 20.01.20 um 16:32 schrieb Rifaat Shekh-Yusef:
> All,
>
> Please, let us know if you have any topics that you would like to
> present and discuss in Vancouver.
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 20 Jan 2020 17:02:39 +0100

Hi Rifaat,

I would like to present draft-ietf-oauth-par, draft-lodderstedt-oauth-rar, and draft-ietf-oauth-jwt-introspection-response (if we did not manage to move it forward by then).

best regards,
Torsten. 

> On 20. Jan 2020, at 16:32, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> All,
> 
> Please, let us know if you have any topics that you would like to present and discuss in Vancouver.
> 
> Regards,
>  Rifaat & Hannes
>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 20 Jan 2020 08:11:49 -0800

I would like to discuss the Browser app BCP as well as the new draft which
got bumped from the agenda in Singapore:

https://tools.ietf.org/id/draft-parecki-oauth-client-intermediary-metadata

----
Aaron Parecki
aaronparecki.com

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 20 Jan 2020 17:33:26 +0000

I would like to discuss HTTP Message Signatures<https://tools.ietf.org/html/draft-richanna-http-message-signatures-00> as a proof-of-possession mechanism for OAuth. A draft will be available (either as an update to draft-ietf-oauth-signed-http-request or as a new individual submission).

–
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Monday, January 20, 2020 at 7:34 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] OAuth Topics for Vancouver

All,

Regards,
 Rifaat & Hannes

---

From: Rob Cordes <[email-masked]>
Date: Mon, 20 Jan 2020 19:18:12 +0100

Hi,

Sorry for me answering in this direct manner instead of via the OAUTH mailing list or so.

I would like to point a practical issue out wrt the HTTP signature spec. I have got practical experience with the spec through my work for ING in our PSD2 (European electronic banking scheme) platform. We have implemented this spec (cavage-10) in our platform as well. We experience lots of issues with 3rd party developers who have issues getting their code right. It is the canalisation that is troubling the adoption in practice. People are continuously making mistakes with setting up the payload for signatures / body digest.
This can only be solved by making available ready made libraries. That might be done through vendors and their solutions and one would encounter  probably less interoperability issues. 

However until then still troubles is what people have with this spec. Apart form that,  the spec is very much draft and as I understood from one of the draft members and still not security tested ands so perhaps still not secure.

Before one can adopt another spec into, in this case OAuth 2.0 it would be wise to tackle this first. While HTTP signing does help in better authenticating and safeguarding messages/token requests, this will make key management even more important.  

The risk that HTTP signing in OAUTH might mitigate, could very well be far easier solved by TLS 1.2 or 1.3. That is even better because the implementations are security tested (TLS 1.2 or depending on the supplier/implementer in the process of (TLS 1.3) due to their importance and can be implemented in a turn key manner. 

These are I believe important attention points that one might think over before extending the OAUTH 2.0 spec even further with perhaps too little gain?

Best regards,

Rob Cordes
Feature Engineer  / InfoSec specialist @ ING bank

> On 20 Jan 2020, at 18:33, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> I would like to discuss HTTP Message Signatures <https://tools.ietf.org/html/draft-richanna-http-message-signatures-00> as a proof-of-possession mechanism for OAuth. A draft will be available (either as an update to draft-ietf-oauth-signed-http-request or as a new individual submission).
>  
> –

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 20 Jan 2020 20:50:34 +0000

As editor of the message signatures draft being considered for adoption within the HTTP WG I can confirm it has significant flaws. 😃 As noted in that draft, the current text is intended to serve as a baselining of sorts to get work that has been floating around in the community into the working group, and it is expected that the working group will make significant breaking changes to it. I encourage anyone who wants to participate in those discussions (as well as the general “call for adoption” discussion to do so, on the HTTP WG mailing list. 😃

I believe it would be to both working groups’ benefit to have an OAuth PoP draft based on HTTP message signatures under discussion early. It would provide the HTTP WG with a test case for the layered approach that the HTTP message signatures draft takes towards this problem, and would allow the OAuth WG to ensure that our use cases are supported. Also, given the interest in DPoP, I think it will be helpful for the OAuth WG to see what message signature-based PoP might look like. It may be easier to target DPoP at a narrower set of use cases if people see a broader solution is coming.

The introduction to the HTTP Message Signatures draft<https://tools.ietf.org/html/draft-richanna-http-message-signatures-00#section-1> describes why TLS is not a universal solution to this problem.

–

From: Rob Cordes <[email-masked]>
Date: Monday, January 20, 2020 at 10:19 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Rifaat Shekh-Yusef <[email-masked]>, oauth <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] OAuth Topics for Vancouver

Hi,

Best regards,

Rob Cordes

On 20 Jan 2020, at 18:33, Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>> wrote:

–

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 20, 2020 at 7:34 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] OAuth Topics for Vancouver

All,

Regards,
 Rifaat & Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Rob Cordes <[email-masked]>
Date: Mon, 20 Jan 2020 22:37:16 +0100

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 <[email-masked]> wrote:
> 
> introduction to the HTTP Message Signatures draft <https://tools.ietf.org/html/draft-richanna-http-message-signatures-00#section-1>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 20 Jan 2020 22:08:56 +0000

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.

–

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

Hi Annabelle,

Regards,

Rob

On 20 Jan 2020, at 21:50, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 20 Jan 2020 16:36:53 -0800

I'd like 5 minutes to see what the interest in Reciprocal OAuth is, if any.

---

From: Daniel Fett <[email-masked]>
Date: Tue, 21 Jan 2020 09:40:54 +0100

One more thing: I'd like to present a very brief update/advertisement
for the OAuth Security Workshop. Immediately after the chairs update
might be a good fit.

-Daniel

Am 20.01.20 um 17:03 schrieb Daniel Fett:
> Hi!
>
> I would like to discuss DPoP, the Security BCP, and give a brief
> update about the activities at the FAPI working group.
>
> -Daniel
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 21 Jan 2020 14:08:41 -0500

I will be presenting the Nested JWT draft:
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

I appreciate it if people can review it before the meeting.

Regards,
 Rifaat

On Tue, Jan 21, 2020 at 3:44 AM Daniel Fett <[email-masked]> wrote:

> One more thing: I'd like to present a very brief update/advertisement for
> the OAuth Security Workshop. Immediately after the chairs update might be a
> good fit.
>
> -Daniel
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>