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

Reply via email to