Meeting 07-07-2023

Attendees

Agenda

  • Workload identities in leaf transaction tokens
    • George - need a way for intermediary servers to add extra authoritative information.
    • Justin's solution may help with this.
    • Justin - can we get away from putting everything in a single token.
    • Justin - we may have a type of graph instead.
    • Justin - we have a dictionary instead of a monolithic token.
    • Atul - this allows a token to send multiple tokens and then reference them. Can this work with JWT embedded tokens?
    • Justin - nothing is specific to JWT.
    • Atul - have a draft that can be referenced by embedded JWT spec.
    • Justin - its a seperable concern
    • George - for nested tokens, would like some real world solutions
    • George - can we use secure forward header (include hashes of previous tokens).
    • Justin - need a mechanism to add things in the middle.
    • Pieter - does not need to be tokens, can be other information? Correct.
    • Pieter - Can you establish a Merkel chain?
    • Justin - I don't think there's a single order chain. There will be things that care about all the previous intermediaries, but others that will be selective
    • George - In a call chain, you would need an order of events.
    • Justin - You can enforce order if you wanted to
    • Atul - Do all services need to sign in what George is proposing?
    • George - Most won't.
    • George - There may be a few cases where we may require the entire call chain to be secure, but in that case, the individual services will know they need to do that
    • Hannes - What kind of call-chain conversation do we want to standardise?
    • George - sometimes you need to know which servers were previously involved (like a log file). Ties back to specific AuthZ policies that need this level of information.
    • Rifaat - STIR has use cases like this (JWT embedded tokens helps with this)
    • Atul - Want to know if the same transaction was processed by another service.
    • Mike - Thinks a little different about a transation. Need to knwo the flow of information
    • Pieter - Does the ordering also matters - Mike to confirm. definately cares about the endpoints.
    • Rifaat - Why do you need the order? Mike to confirm.
    • Atul - May care about the ordering in some cases needs to be estabished.
    • Atul - the Draft does give you the order.
    • George - sometimes you get a transaction token, sometimes a nested token. May prefer option 4 - always get a fresh transaction token. Gives consistency - always a transaction token. Structural processing is the same. Always get a fresh transaction token instead of mixing it.
    • Atul - if we keep it, we should specify it more completely.
    • George - we need more use cases - perhaps remove the nested model?
    • Hannes - can we change the name of the token - if it is only about keeping call-chain information, perhaps calling it a signed log? AuthZ implementors may get confused by tokens and make bad decisions.
    • Justin - Security event working group - introduced as "JSON Web Logs" initially, eventually became "Security Event Token" (SET)
    • Atul - conclusion: work on more details for the Workload 4 flow. Need more discussion on Workflow 3.
    • Atul will submit doc so we have a discussion at IETF 117 in July.
  • Security considerations of leaf versus nested transaction tokens
  • Is the Transaction Token Service just another endpoint?
  • Standardizing machine identity terminology
  • Naming: tx-token => txn-token
  • Transaction Token lifetime
  • Transcribing claims
  • Mutual authN of Transaction Token requests
  • "tid" and "azc" claim definition (IANA registration?)
  • Explaining the self-signed nested transaction tokens part more clearly
  • Token Data Structures (Justin)

<item 1>