Can a sub_id change?

[PieterKas]

Is a sub_id considered constant throughout the transaction, or can this change over time. If it does change, how should the "old sub_id" be recorded? As part of the azd claim? Should we add information to that effect?

@tulshi and @gffletch

[gffletch]

I think we moved away from sub_id to just using sub. However, the larger question is an interesting one. Is there a case where in completing a requested transaction, one of the calls to one of the workloads SHOULD NOT receive the sub claim. Is the TraT then leaking information? I haven't thought about this more than writing this comment :)

[tulshi]

Hmm. interesting question. We do not have a means of creating constrained versions of TraTs today. I'd punt this for later though. I'm not sure this is critical to the TraTs draft as of now.

[gffletch]

I agree. Within a single trust domain, this is probably less of an issue.

[gffletch]

So I was have a conversation the other day about authorization and the topic of Transaction Tokens came up. One of the interesting discussion points was whether the authorization model is consistent throughout the life of the transaction token. For example, maybe the data tier doesn't know about users when it comes to enforcing authorization policy. Maybe that is done through fine-grained entitlements. That keeps the data tier from needing to reach into the user authorization store to determine which data the user can access. Or maybe there is a authorization layer closer to the edge that will redact data the user isn't allowed to see.

In either of these cases, should it be possible to get a replacement transaction token that doesn't have a sub but does have the list of data tier entitlements that are authorized for this particular request.

[tulshi]

George and I discussed this and I feel that the sub_id is a core value of the Transaction Token, which assures the user identity throughout the call chain. Changing that would be dangerous. We have therefore agreed to close this issue.