OK, based on a private discussion on this topic with John, I’m going
to suggest that we change the language “The IP/STS MAY use this
value as-is or as an input seed to a custom function to derive a
value for the PPID claim” to “The IP/STS SHOULD combine this PPID
seed value with constant information known to the IP/STS and pass
the combination through a cryptographically non-invertible function,
such as a cryptographic hash function, to generate the PPID claim
value sent in the signed token”.
1. I've always had trouble with using the term "audit mode" for cards where
the IdP wants knowledge of the RP identity. I can think of many reasons why
an IdP might want to know the RP identity that are not limited to
2. I think part of the problem with this discussion is that we keep using
the term PPID when we mean ClientPsuedonym. The ClientPsuedonym is
typically used by an IdP in the computation of a PPID - and as John points
out, a poorly implemented IdP might use the identity function for that
computation, but calling them the same thing increases that probability.