In embodiments, token 600 issued by STS 232 is required to not divulge the real identity, or identifying information, of the user/remote principal from the domain of the user/remote principal, e.g., a member of group 318 of second domain 304 in FIG. 3 and/or the user/remote principal of tenant B/P 238 as illustrated in and described with respect to flow diagram 400 of FIG. 4. Accordingly, in embodiments, attributes such as but not limited to the following are not populated: “family_name”, “given_name”, “name”, “oid”, “onprem_sid”, “puid”, “unique_name”, “upn”, “deviceid”, etc. In some embodiments, claims which refer to conditional access policies and multi-factor authentication (MFA) “auth.state” are also not populated: e.g., “amr”, “controls”, “signin_state”, etc. However, in some embodiments, one or more portions of identifying information may be included in tokens based on an agreement therefor between data resource owners and accessors. Additionally, an attribute designating that a remote principal is specified in token 600, e.g., “rpo,” is included with token 600 that points to the RPO from which token 600 is created, in embodiments. This is used to correlate token 600 to the RPO(s) and through that to the ELM package that created the RPO. This example “rpo” claim is optional in some embodiments, and may only be provided for services/applications that subscribe to this claim. The “rpo” claim contains the RPO object ID in the customer tenant. In some embodiments, when workloads require additional information in the token for various purposes such as granular and compliance auditing, etc., the data resource owner and the partner/remote principal can mutually agree for additional information to be available in the token, such as partner user “oid”, partner user “upn”, etc.
