# Meeting 10-27-2023 ## sub versus sub_id - (Arndt) `sub_id` gives good flexibility. You could still use the `iss`/`sub` format for specifying `sub` - (Arndt) Personally I like the `sub_id` claim, but `sub` should be allowed - (George) How did Shared Signals solve this? It adds a little bit of complexity - (George) The parsing does get complicated - (Arndt) The spec actually says we can have both and they should be in agreement. - (George) What are the significant benefits of doing `sub` - (Atul) Token compactness - (Justin) Why is that important - (Atul) It was important in an earlier job - (George) If we do this, we must allow implementations that only allow one or the other. This should be the deployment guidance - (George) language to be added: 'there MUST be one and only one subject claim - either `sub` or `sub_id`' - (Justin) The separation of `sub_id` and SETs is deliberate in the SecEvents WG. So we should feel free to use `sub_id`, because it is not like we are profiling SETs - (Justin) The `sub_id` more clearly separates authorization tokens from messages like SETs - (Arndt) Is the issuer relevant? - (Justin) That is how the `sub` claim breaks down, because the moment you cross a domain boundary, it becomes uninterpretable - (George) If we have a model in which the Txn-Token service is distinct from the AS, then there is reason to use `sub_id`. We could make this a part of the guidance - (Arndt) We should provide guidance that if multiple trust domains are involved, then the Txn-Token must have `sub_id` - (Atul) The same logic can apply to the `iss` - (Justin) Its fairly clear that the `iss` represents the issuer of the Txn-Token. Because the `iss` should always be the issuer of the Transaction Token and nothing to do with the issuer ## Can Issuer claim be optional - (George) We should not make the `iss`claim optional - (Rifaat, Justin) agreed - (Arndt) If you know inside the trust domain, and token size is a big issue, then do we need the `iss` claim? - (George) In a distributed case, it's possible that there are multiple keys being used to sign Txn-Token - (George) The `iss` is just a URN, it doesn't have to be a URL, so the token bloat can be made minimal by keeping the value short - (Justin) IF size is a really big consideration, then you could use COSE or compress the JSON before it goes into the JOSE structure. - (atul) agree with not making `iss` optional ## Scope / `req_ctx` comment in email from Kai - (George) In Kai's case they are actually taking the external Az Token and copy the scope into the Txn-Token. But they can always do that through `req_ctx`, so we don't need to do anything ## Using Txn-Tokens - (Justin) I prefer that this draft be silent about that - (Justin) For a lot of the use-cases we're discussing, this isn't really authorization. Having it in the `Authorization` header - (George) I feel we had a similar issue from Naveen from Yahoo earlier. - (George) I feel we need to specify something - (George) In Kai's case, the Authorization header was being used for server-to-server trust, so they couldn't use that header - (George) We could eventually leverage the Bucket work Justin is doing to specify how to use Txn-Tokens, but not having it right now is a gap - (Atul) We could define a separate header to convey the transaction token - (Arndt) There is a IANA header name registry. We should make sure whatever we define doesn't conflict, and we register it in that registrty - (Arndt) I can see in the future proxies or other components needing to interpret it - (George, Atul) agree - (Atul) I can review the IANA registry to figure out if there's a header that we can use, or if we need to define a new header - (Justin) The real thing might be to bring this up with the HTTP working group or the HTTP API working group, and ask them what we should do # Identity Chaining - (Arndt) We published a new version. No big changes, but for discovering the other domain AS, we used the `WWW-Authenticate` header, but now in addition we point to the OPRM draft. Since it's a draft we cannot fully reference it.