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
