It makes sense to me that the sub should always be the subject of an issued token.
thx ..Tom (mobile) On Sun, Oct 29, 2023, 7:54 PM Justin Richer <[email protected]> wrote: > 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 <[email protected]> on behalf of Atul Tulshibagwale < > [email protected]> > *Sent:* Thursday, October 26, 2023 4:07 PM > *To:* Kai Lehmann <[email protected]> > *Cc:* [email protected] <[email protected]> > *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= > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
