WIMSE Interim May 2024

• note takers: Yaron S, Thomas F

Service to Service Design Team

Yaron recap:

• s2s protocol reached more-or-less consensus within the DT

Arndt:

• Assumptions (slide 4):
  • KISS and extend later
  • the mechanism is at the application layer, allow different
    transports
  • keep identity provisioning out-of-scope
  • minimalist JWT cred
  • identity is opaque to allow different id providers (e.g.,
    SPIFFE/SPIRE, but not only)
  • some kind of freshness

Daniel:

• Identity Token options (slides 5-7):

  • Option 1: based on DPOP

    • iss isthe identifier of the workload
    • cnf info for verifying the token
    • uses HTTP

  • Option 2: using HTTP Message Signatures

    • avoid middlebox interference
      Joe:

• Open issues (slide 8):

  • cross-domain, maybe out-of-scope
  • identity chaining, ditto

  • symmetric crypto for performance?

    • key management is tougher => defer for now

  • which other types of claims could be added?

  • further security analysis needed in areas such as freshness,
    replay & theft, middlebox interference
  • do we need to define policy enforcement? this looks very much in
    scope

Discussion

Dapeng Liu: submitted a draft with use cases and an initial solution,
including platform attestation. would be happy to discuss with the
group. similarities with what discussed and proposed by the DT. happy to
share the contents of the document with the DT.

Justin: when the DT concludes (in a few weeks) we will open the
discussion.

Yaron: to the chairs: should the DT come up with an initial draft?

Pieter: yes.

Brian Campbell: token format is independent of the 2 options for
binding/proof mechanisms. Also, as Yaron points out, the token is not
a bearer token.

Joe: restating what Brian clarified above.

From chat:

Kai Lehmann
16:00
Has sending the workload identity token within the Authorization request
header be considered as an alternative to a new header?
Daniel Feldman
16:01
Kai - I don't think we have specifically considered that yet
Brian Campbell
16:02
i've been thinking that we don't want to "use up" the Authorization
header
there can only be one
George Fletcher
16:02
It may that some (or most) use cases will already have an Authorization
token and this is in addition
Brian Campbell
16:03
what George said :)
John Kemp
16:08
If there is already an Authorization HTTP header, what are the semantics
related to also having a WIMSE token elsewhere?
If there is no Authorization HTTP header, would it make sense to have
the WIMSE token appear there?
George Fletcher
16:09
We already or leveraging multiple HTTP headers (e.g. DPoP) so I don't
think that should be a big issue.

Token Exchange Design Team

Yaroslav:

• Uses cases: splitting the space of applications based on specific
  properties. It is expected that these use cases can be combined to
  describe more complex / real applications. Slides 4-11 explain
  grouping dimensions (e.g., token format, crypto, embedding, context,
  validity constraints, subjects, sender constraints changes). Real
  use cases are expected to be a combination of the dimensions above.
• Security considerations (slide 12): discussion on replay, access
  ctrl, privacy, privilege elevation, multi-tenancy, auditability.

Maybe more than one draft is needed.

Discussion

Watson Ladd: slide 8 is wrong. Should be "Token B" rather than "Token
A".

Evan: how much are we assuming on the exact token format?
Yaroslav: I don't think it's a question for this DT. Chairs?
Justin: Happy to listen what have you been thinking so far?
Yaroslav: we are not assuming any single token format. In fact, we are
taking token transform into consideration (see use cases dimension). we
cannot be completely opaque to format and we are allowing different
possible formats.
Ibrahim: cross-domain token transformation (e.g., protobuf to JSON)
guidelines are one of the expected DT outputs?
Yaroslav: yes, x-domain and !x-domain cases are covered.
George Fletcher: what are the kinds of transformations that can happen
to tokens and need to be represented.
John Kemp (from chat):

1. If there is already an Authorization HTTP header, what are the
   semantics related to also having a WIMSE token elsewhere?
2. If there is no Authorization HTTP header, would it make sense to
   have the WIMSE token appear there?

Final remarks from the chairs

Pieter: Thank you DTs for the work so far.
DTs: start drafting and communicate directions / recommendations
In Vancouver, DTs please share any final output.
Justin: echoing Pieter