I disagree with the utility of just "sub" here. The subject of the token is always contextual to the issuer of that subject - however, the "iss" field here is the issuer of the transaction token and not the issuer of the subject identifier. As such, it's much less ambiguous to use the compound field. The concerns are similar to SET, where sub_id was initially defined - - the source context for the subject can't be assumed to be the same as that of the transaction token.
-Justin ________________________________ From: OAuth <oauth-boun...@ietf.org> on behalf of Atul Tulshibagwale <a...@sgnl.ai> Sent: Thursday, October 26, 2023 4:07 PM To: Kai Lehmann <kai.lehmann=401und1...@dmarc.ietf.org> Cc: oauth@ietf.org <oauth@ietf.org> Subject: Re: [OAUTH-WG] sub_id in draft for Transaction tokens Hi Kai, Thanks for this and other feedback you have provided. The primary reason for using "sub_id" was to enable a format that can be more expressive than the "sub", which is always a string. I can see the benefit of having either "sub" or "sub_id" in the Transaction Tokens spec. "sub" will allow for more compact tokens where a richer subject format is not required. Atul On Thu, Oct 26, 2023 at 1:52 AM Kai Lehmann <kai.lehmann=401und1...@dmarc.ietf.org<mailto:401und1...@dmarc.ietf.org>> wrote: Hi all, I very much like the draft. We have a similar token mechanism implemented for our service infrastructure. I am not quite sure about the reasoning behind using “sub_id” for the subject identifier instead of using “sub” as used across OAuth technology. The referenced draft for SubjectIdentifiers is related to a security event environment. The origin of the sub can be manifold in those scenarios. In the OAuth environment, on the other hand, we do usually have the original access token at the beginning of the call and there, a sub is usually present and well defined within the trust boundary. In our implementation, we simply create an internal token (that’s our term for it) and copy the sub from the AT. We have a few entry points where we do not have a user interaction (for instance incoming mail via SMTP which needs to be delivered to the end-users mailbox storage). In those scenarios, we allow the very small list of gateways (e.g. SMTPD) to call the token exchange with other parameters than the AT. The recipient email address needs to be provided which is being used to look up the actual subject identifier (in our case it’s a UUID tied to the user account) which is put into the created internal token. This way we ensure that the “sub” claim is always the same type/format. The internal services do not need to interpret/support multiple formats as they can rely on the token exchange server to provide it. The referenced draft for subject identifiers for security events allows for the “sub” in parallel to the “sub_id”. My suggestion would be to allow to use either “sub” or “sub_id”. I would use “sub” as long as all parties (workloads) within the trust boundary understand what the sub value is and it is guaranteed that the transaction tokens are generated with the same sub format/type. Best regards, Kai _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
