FAL2 - Pairwise Pseudonymous Identifiers

[dhs-BI]

An outstanding item that the group should discuss is how the concept of Pairwise Pseudonymous Identifiers (PPI) should be supported, if at all, by IPSIE at any SL_x_.

I do not have a strong opinion on IPSIE support for PPI, therefore I am looking for others to help with understanding the importance of PPI for enterprise scenarios.

[sbroddy]

In my sector, things like journal access, dataset access, and research resources are likely one of the biggest use cases for this type of access. The org/enterprise pays for access to resources but does not wish the resource owner to be able to identify the individual accessing said resources.

I can think of other use cases in the federal/DoD spaces.

[dhs-BI]

Thanks @sbroddy, this is helpful. If you don't mind, please document the other use cases. We're queuing this up for discussion on the call next week.

[sbroddy]

A use case for pseudonymous identifiers could be things like ethics/whistleblower reporting. While the user could likely be identified internally, it is usually people that are bound by policy (or law) not to research those logs afterwards for things like retaliation. But the enterprise likely wants to make sure the user at least has some formal affiliation with the enterprise before they can report to the internal service and/or external contracted reporting service.

I'll let other speak to the DoD use cases rather than post them publicly here. But they do definitely exist, and I've been party to discussions of them previously in other forums.

While I'm thinking about it, targeting *AL level 2 across the board as a baseline may not make sense in all cases. Capability for, probably. Required, probably not. IPSIE should consider this and whether or not it makes sense to have the minimum (required) baseline at *AL-2 for all things. The case can be made for situations where the federated relationship is simultaneously IAL3 (PIV), AAL2, and FAL1 or 2 as an example.

[deansaxe]

As discussed on the 2025-05-13 call and in #81 and #82, I will plan to include this in the sidecar doc.

[deansaxe]

I have published a draft to address this issue. Please see https://deansaxe.github.io/draft-saxe-ipsie-common-requirements-profile/draft-saxe-ipsie-common-requirements-profile.html.

[deansaxe]

I have incorporated this into the common requirements doc. If the doc is adopted, this issue can be closed. Labeled as pending close.