Subject: [Unbearable] -tokbind-https-02: "Federated token bindings" figures

From: =JeffH <[email-masked]>
Date: Sun, 28 Feb 2016 21:42:39 -0800

fyi/fwiw, when reviewing draft-ietf-tokbind-https-02 I found it somewhat 
difficult to follow along which entities play which roles and such, given 
all the various terminology in play, so I drew some figures (below, fixed 
pitch font is your fried) to try to tease it all apart.The first is the 
overall model, and the 2nd is the particular "Federation Use Cases" in the spec.

Are these accurate?  (if they get horribly mangled transiting email systems, 
i'll blog 'em or sumptin'..)

HTH,

=JeffH

Overall "Federated token bindings" model
per https://tools.ietf.org/html/draft-ietf-tokbind-https-02

                                                   Token          Token
                                                  Consumer        Provider
                        +--------+                +----+          +-----+
                        | client |                | TC |          | TP  |
                        +--------+                +----+          +-----+
                            |                       |                |
                            |                       |                |
                            |                       |                |
                            |                       |                |
1. Client interacts w/TC   |<--------------------->|                |
    TBID1 established       |                       |                |
                            |                       |                |
    TC gives client perms   |                       |                |
    to reveal TBID1 to TP   |                       |                |
                            |                       |                |
                            |                       |                |
2. Client interacts w/TP   |<-------------------------------------->|
    TBID2 established       |                       |                |
                            |                       |                |
    Client includes both    |                       |                |
    TBID1 and TBID2 in TB   |                       |                |
    message to TP           |                       |                |
                            |                       |                |

Illustration of section 3. Federation Use Cases
https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3

  What:
     Typical HTTP Redirect-based Web Broswer SSO Profile
     (no artifact, no callbacks), featuring binding of,
     e.g., a TLS Token Binding ID into an OpenID Connect "ID Token".

  Legend:

     ID Token: the "ID Token" in OIDC, is semantic equivalent
               of a SAML "authentication assertion"

     OIDC: Open ID Connect

     TBID:  Token Binding ID

     TBIDn: Token Binding ID number "n", i.e., mapped to particular TLS
            session(s) & connection(s) with particular party

     ETBMSG: Token-Binding header field conveying EncodedTokenBindingMessage,
             lists the conveyed TBID(s) and their type(s) within "[...]"

   Client,                      Token Consumer,       Token Provider,
   aka:                         aka:                  aka:
   User Agent                   OpenID Client,        OpenID Provider,
                                OIDC Relying Party,   OIDC Provider,
                                SAML Relying Party    SAML Identity Provider
   +--------+                        +----+                +-----+
   | Client |                        | TC |                | TP  |
   +--------+                        +----+                +-----+
       |                               |                      |
       |                               |                      |
       |                               |                      |
       | 0. Client interacts w/TC      |                      |
       | over HTTPS, establishes TBID1 |                      |
       | ETBMSG[TBID1:provided_token_binding]                 |
       |------------------------------>|                      |
       |                               |                      |
       |                               |                      |
       |                               |                      |
       | 1a. OIDC ID Token request, aka|                      |
       | "Authentication Request", conveyed with              |
       | HTTP response header field of:                       |
       | Include-Referer-Token-Binding-ID:true;               |
       | any security-relevant cookies |                      |
       | should contain TBID1          |                      |
     +<- - - - - - - - - - - - - - - - |                      |
     . | (redirect to TP via 301, 302, |                      |
     . |  303, 307 or 308)             |                      |
     . |                               |                      |
     +------------------------------------------------------->|
       | 1b. opens HTTPS & establishes TBID2,                 |
       | sends GET or POST with                               |
       | ETBMSG[TBID2:provided_token_binding,                 |
       |       TBID1:referred_token_binding]                  |
       | conveying ID Token request    |                      |
       |                               |                      |
       |                               |                      |
       |                               |                      |
       | 2. user authentication (if applicable,               |
       |    methods vary, particulars are out of scope)       |
       |<====================================================>|
       | (TP generates ID Token for TC containing TBID1, may  |
       |  also set cookie(s) containing TBID2 and/or TBID1,   |
       |  details vary, particulars are out of scope)         |
       |                               |                      |
       |                               |                      |
       |                               |                      |
       | 3a. ID Token containing TBID1, issued for TC,        |
       |    conveyed via OIDC "Authentication Response"       |
     +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -|
     . |   (redirect to TC)            |                      |
     . |                               |                      |
     . |                               |                      |
     +-------------------------------->|                      |
       | 3b. HTTPS GET or POST with                           |
       | TBMSG[TBID1:provided_token_binding]                  |
       | conveying Authn Reponse containing                   |
       | ID Token w/TBID1, issued for TC                      |
       |                               |                      |
       |                               |                      |
       |                               |                      |
       | 4. user is signed-on, any security-relevant cookie(s)|
       | that are set SHOULD contain TBID1                    |
       |<------------------------------|                      |
       |                               |                      |
       |                               |                      |

---

From: Nick Harper <[email-masked]>
Date: Mon, 29 Feb 2016 10:14:12 -0800

That matches my understanding of how referred token bindings are supposed
to work.

On Sun, Feb 28, 2016 at 9:42 PM, =JeffH <[email-masked]>
wrote:

> Are these accurate?  (if they get horribly mangled transiting email
> systems, i'll blog 'em or sumptin'..)
>
> HTH,
>
> =JeffH
>
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>