Fair enough. Because the XML element sent to the IdP is <ic:>ClientPseudonym><ic:PPID>value</ic:PPID></ic:
ClientPseudonym> sometimes in dialog we tend to slip into saying PPID but I
agree that we should more consistent use the term ClientPseudonym for this
value.
Talk to you in a few…
--
Mike
From: Michael McIntosh
[mailto:mikemci@us.ibm.com]
Sent: Thursday, January 08, 2009 7:43 AM
To: Mike Jones
Cc: imi@lists.oasis-open.org; John Bradley
Subject: RE: [imi] Clarifications to the spec to discuss for our call on
Thursday
Mike Jones
<Michael.Jones@microsoft.com> wrote on 01/07/2009 09:52:23 PM:
> John Bradley, imi@lists.oasis-open.org
>
> 01/07/2009 09:52 PM
>
> 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”.
Two things...
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 audit/record-keeping.
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.