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> 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 > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
