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