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.