HackMD
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)
