The good news is that the current PPID algorithm doesn’t use the cert chain –
just specific fields from the leaf cert that are expected to be invariant across
cert renewals and even change of cert provider.

Cheers, -- Mike

From: Anthony Nadalin [mailto:drse...@us.ibm.com] Sent: Thursday, January 08, 2009 7:08 AM To: John Bradley Cc: im...@lists.oasis-open.org; Mike Jones Subject: Re: [imi] Clarifications to the spec to discuss for our call on
Thursday

The certificate chain can produce different results, we have already seen this

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

[cid:image001.gif@01C97167.641FDDF0]John Bradley ---01/08/2009 08:25:52
AM---Better, thanks Mike.

From:

John Bradley <jbra...@mac.com>

To:

Mike Jones <Mich...@microsoft.com>

Cc:

"im...@lists.oasis-open.org" <im...@lists.oasis-open.org>

Date:

01/08/2009 08:25 AM

Subject:

Re: [imi] Clarifications to the spec to discuss for our call on Thursday

________________________________

Better, thanks Mike.

For auditing mode cards do we want to say that the IP/STS SHOULD use the
certificate chain to produce the PPID with a cryptographically non-invertible
function, such as the one used to calculate the PPID for p-cards.

If we are going to have the spec say that the selector should send the PPID for
auditing mode cards, I don't want to infer that using that even with a hash
function is better than calculating it from the site cert chain.

=jbradley On 7-Jan-09, at 11:52 PM, Mike Jones wrote: 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”.

-- Mike

From: John Bradley [mailto:jbra...@mac.com] Sent: Wednesday, January 07, 2009 1:02 PM To: im...@lists.oasis-open.org<mailto:im...@lists.oasis-open.org> Subject: Re: [imi] Clarifications to the spec to discuss for our call on
Thursday

<snip> On 7-Jan-09, at 5:17 PM, Michael McIntosh wrote:

John Bradley <jbra...@mac.com<mailto:jbra...@mac.com>> wrote on 01/07/2009
02:21:00 PM:

Not completely. The IdP (AKA Card Issuer) gets to specify whether the RP identity is required,
not required, or optional - and that information is in the card and/or IdP
metadata (I forget which). The RP gets to specify whether or not a specific IdP is required, or whether any
is acceptable. The user gets to select which card (and therefore which IdP) will be used.

If a user does not want to use a card that requires disclosure of RP identity to
the IdP, it can choose another card. If the only cards the user has that match the RP policy are cards that require
RP disclosure, the user can go elsewhere. As far as I know there is nothing in the selector that tells the user that it is
going to disclose the identity of the RP to the IdP.

So I agree that in principal the user is free to select any card that matches
the required claims but if they have two cards one auditing and one not they
have no easy way to distinguish between them.

I have to go back and look at how optional auditing mode works that is a new one
to me.

As near as I can see with current selectors the power is in the hands of the
IdP, unless I am missing something.

=jbradley