[Openid-specs-mobile-profile] Token Binding

Mike Jones Michael.Jones at microsoft.com
Tue May 15 16:47:11 UTC 2018


Hi Michael,

Sorry for the troubles connecting with the EAP working group.  There's been a lot of travel for many of us lately (I'm in Europe for EIC right now!) and it's conflicted with some of the calls.  (We did send cancellation messages when we didn't have them, I believe.)

Anyway, it would be great to hear about your experiences with TLS termination.  The call schedule at http://openid.net/wg/eap/ is right - 8am Pacific Time every other Thursday.  Please plan to join us on a call soon.  I'm pretty sure we'll have the June 7th call.  May 24th is questionable because of a FIDO plenary meeting that week.

                                                       Best wishes,
                                                       -- Mike

From: Engan, Michael <Michael.Engan1 at T-Mobile.com>
Sent: Tuesday, May 15, 2018 5:38 PM
To: openid-specs-eap at lists.openid.net; openid-specs-mobile-profile at lists.openid.net
Cc: Hjelm, Bjorn <Bjorn.Hjelm at VerizonWireless.com> (Bjorn.Hjelm at VerizonWireless.com) <Bjorn.Hjelm at VerizonWireless.com>; Latham, James <James.Latham5 at T-Mobile.com>; McDorman, Doug <Douglas.McDorman at T-Mobile.com>
Subject: Token Binding

Good morning,

I have tried joining the last two EAP working group calls, but the first I was five minutes late to (ended early?) and the second I joined a minute early but it never opened. Perhaps I Have the wrong invitation links from the OIDC calendar.

Note: I do have the IPR signed for all OIDC working groups.

I have wanted to bring up a discussion around Token binding and specifically an option away from TLS.  My experience has consistently shown that our Microservice cloud almost never sees the correct TLS tunnel, as TLS gets terminated on a variety of different layers these days. Including Web Application Firewalls (waf), Load balancers (ecb/f5/others), API gateways, or even many corporate environments which use company loaded certs to do https proxies. In addition those same TLS termination layers have a limited history of supporting the use of JWT tokens for analyzing authorizations.

Therefore T-Mobile is recommending a Client(rp/sp) defined key pair for use in Token binding. The same key the RP uses for oidc assertion type=jwt.  Would then be the included CNF in the issued id_token.   Furthermore to support the collection of RP clients, the RP could use the Referred-binding to allow a Client to use its generated key pair to be the binding.

I have attached a simple deck that I was using to explain a couple of the concepts. The deck is very tuned to a mobile audience, (hence I included MODERNA above).  I have not yet had the time to do a more formal write up of the three different elements to this suggestion.


  1.  Enabling an RP defined key for binding instead of TLS.
  2.  Enabling an RP to extend the Binding to an RP client instance.   (ie... one RP web site... thousands of RP apps each with their own keys).
  3.  Chaining Token Binding.

The last concept (not really covered in the deck)  is a method to tackle the microservice cloud that many of us are facing. Any one service call these days may bounce through multiple microservices.  By having each layer apply their signature, you can maintain the token binding through the stack. As we tell our developers to stop assuming a firewall is protecting them, they must resort to authenticating every request, and the token binding chain becomes one method to help with that.


While my write up is not ready. Bjorn suggested I at least make these suggestions known.

Thanks.





Michael Engan
Principal Systems Architect,
Authentication, Authorization, & API security
12920 SE 38th Street | Bellevue, WA 98006
Direct 425-383-2268 | Mobile 425-443-3463

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180515/8f34bf99/attachment.html>


More information about the Openid-specs-mobile-profile mailing list