---
# System prepended metadata

title: Meeting-10-27-2023

---

# 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.


