Meeting On 03-29-2024

Attendees

• Kelley Burgin
• Hannes Tschofenig
• Arndt Schwenkshuster
• George Fletcher
• Atul Tulshibagwale

Agenda

• Transaction Tokens
  • Resolving subject_token issue (#53)
  • Security Controls on TraTs (#74)
  • Yaron's feedback
    • Move aud requirement out of terminology section (#76)
    • Make txn optional (#77)
    • purp claim name and optionality (#78)
    • Clarify difference between rctx and azd (#79)
    • Extensibility of azd and rctx (#80)
    • Clarify sub field (#81)
    • Possible confusion in IANA registry section (#84)
  • Long-lived tokens (#62)

Notes

• Solicit Yaron's feedback on ID-Chaining, since he is already profiling the draft

subject_token issue

• Subject_token type can be out of scope for this spec
• Implementers should have the freedom to define whatever subject token type they need
• We should add some explanatory text to this effect
• George to take it up
• (Arndt) Is this when we don't have an inbound subject token?
• (George) The example we have used is an email server, which doesn't have an incoming token
• (George) Internal requests where there is no incoming token is similar
• (Arndt) Should we use token exchange in that case? There may be more than one input in the context other than what we put in the subject_token value
• (George) There are two aspects:
  • The Subject itself
  • The other claims
• (Hannes) Is the subject_token well defined?
• (George) The subject_token in the Token Exchange represent the subject that is used to create the resultant Txn-Token. It could be a SAML assertion, an ID Token, or something else. There's nothing to stop someone from creating an internal "token", to put the subject information. We do not need to get into the details of what that format or content needs to be
• (George) For example, a requester may generate a self-signed JWT with just an email claim in it
• (George) We could make non-normative recommendations if it helps
• (Atul) The incoming request may not have a token at all, if it uses MTLS for example
• (Arndt) If I were to implement this, I'm going to trust any claim the requester they send, and produce a TraT. In this scenario, this is not really token exchange
• (Arndt) In many cases the TraT server may be the same as the AS, and then this becomes very problematic
• (George) The TraT service must do authorization in order for this to work. The requesters are limited (not every workload is able to request a Transaction Token)
• (George) We could have a separate API for minting that is not Token Exchange, but conceptually it is doing the same thing. But the goal is to use one API to do everything
• (Arndt) The Token Exchange API works great if you have an external access token, and you want to get a TraT for that
• (Arndt) But when we don't have an external token, it becomes problematic
• (George) You could implement it as the requesting workload generates a self-signed JWT, which is a token, and the TraT validates the signature and generates a TraT based on that. In the configuration you are basically trusting the requesting service
• (Arndt) If this were in WIMSE, I would agree, but in OAuth these things don't really exist, like keying material for each service
• (George) It's an interesting concept to use the actor_token that can be used by any service to request a TraT. The trust model in this case is based on using a bearer token for workload identity trust
• (Kelley) Are there any WIMSE considerations that we need to think about? Like not overly prescribing things so that it could be used in WIMSE
• (Arndt) In OAuth we don't assume private keying material in each service
• (George) We use MTLS to authenticate individual services in our OAuth implementations
• (Hannes) This is a good question for the working group
• (George) The thing we are going to run into in WIMSE is based on the OAuth authentication model. WIMSE is not dependent on that model, so the direct usage of ID-Chaining in WIMSE is going to have to resolve these issues
• (George) Similarly if you were to use TraTs in WIMSE, you would have to make similar assumptions
• (Kelley) I'm OK with that, I just wanted to make sure we are aware of this consequence
• (George) That is the assumption we are making today, but I'd like to have WIMSE contact us and recommend changes
• (George) If WIMSE wants to use CBOR / COSE, then this spec is not addressing that. I'm OK with that, but we may need to evolve this
• (George, Atul) There's value in continuing this work, and later work with WIMSE to extend it to CBOR / COSE / protobufs
• (Arndt) Agree with this
• (Arndt) In the "mint" scenario (where there is no incoming token), we should not use the subject_token parameter. It'll be easier for an AS to make the distinction
• (George) We can add some text that says subject_token should be N_A if there is no incoming token, and use the RAR for the authorization details that need to be minted
• (Arndt) But RAR requires authorization details to be copied into the resulting token
• (Atul) That would not be a good outcome, can we use the request context instead?
• (George) The request context is supposed to be just the contextual information (envrionmental information about the request). The authorization details is supposed to contain the subject info
• (George) Is it better to just create a new endpoint that is not based on Token Exchange and use that for the minting case
• (Atul) I'd prefer using Token Exchange and using N_A for subject_token, and putting the subject information in the request_details object
• (George) We should make a note of this in the spec
• (George) We're basically now saying that you can send in an incoming token, or specify everything in the request_details, which creates a bunch of new security considerations
• (George) Should we just then standardize that model? What are the security implications of that
• (Atul) Then it becomes even more glaring that we are not really using token exchange
• (Kelley) Defining a new endpoint might give more flexibility, but it's not a big advantage
• (Atul) I'll summarize this to the oauth list

ID-Chaining

• (Kelley) I'll create a PR to address the sender-constraint issue

Issue 76 - Normative language about aud in Terminology section

• (George) We could potentially move it to 5.2

Issue 77 txn should be optional?

• (George) I'd prefer to say that it is required, but it can be externally defined
• (Atul) I think this should be required, and the TraT service can inherit that value from some external source if required
• (Arndt) If we make it optional, we make it harder for implementers too
• (George) Effectively, the txn value is recommended to be a unique ID for this transaction
• (George) txn ties together all the workloads required to process the specific transaction. You can correlate all this through logs or SIEM. It gives observability. You could detect anomalies
• (Kelley) I will write up my use case