RE: [imi] Clarifications to the spec to discuss for our call onThursday

[Mike Jones <Michael.Jones@microsoft.com>]

On point 1 (ClientPseudonym):  One thing I could have been clearer on in my initial note is that this clarification is to have our spec match existing practice.  For instance, the OSIS tests http://osis.idcommons.net/wiki/I4:FeatureTest-Selector_Support_for_Auditing_Cards, http://osis.idcommons.net/wiki/I4:FeatureTest-Selector_Support_for_Auditing-Optional_Cards, and http://osis.idcommons.net/wiki/I4:FeatureTest-Selector_Support_for_Non-Auditing_Cards verify that selectors always make a ClientPseudonym/PPID value available to the IdP when the RP asks for a PPID.  All the selectors tested passed this test, so they’re clearly already doing this.  We should update our doc to fix this bug that was present in the ISIP 1.5 input doc (my bad!).  I believe that my initial proposed wording is still appropriate in this case.

 

On point 2 (IssuerId):  Mike, if you believe that this is valuable even when the card isn’t managed-backed-by-self-issued, I’m fine leaving things as-is, where it’s expected to be present for all managed cards.  This matches existing practice as well.  The one clarification I’d still like to make is in the sentence about “this can be empty”, which I find misleading as-is, since for managed cards, it should not be the empty string.  (And yes, it shouldn’t be NULL either, which we should also clarify.)  In that case, the only wording change I suggest that we make is changing “The element content may be empty” to  “The element content SHOULD be the empty string when the card is self-issued”.

 

On point 3 (Self-issued cards supporting the PPID claim even when not listed):  I agree that I would prefer that we have self-issued cards explicitly list the PPID claim going forward.  I mainly brought this up as a compatibility note since I was personally surprised when reading some decrypted .crds files to discover that this claim wasn’t listed.  I thought others would find this surprising as well and so thought I’d bring it to the working group’s attention as a compatibility note.  How about this wording?

 

Compatibility Note:  When saving a self-issued Information Card in the Information Cards Transfer Format defined in Section 6, some existing Identity Selectors omit listing the PPID claim as an ic:SupportedClaimType from the ic:SupportedClaimTypeList for a self-issued card, even though the PPID claim is supported by the card.  This behavior is deprecated, as all supported claims should be listed.  Nonetheless, Identity Selectors may choose to recognize this case and support the PPID claim for self-issued cards not explicitly listing this claim.

 

To Tony’s point about selectable PPID algorithms, I agree that there is value in that possibility, but there is no existing practice for us to standardize.  The working group could choose to investigate that as subsequent work, but I believe that that’s out of scope for the current effort.

 

And finally, I want to ringingly endorse Mike’s point “Any RP that blindly accepts a PPID and not a signed PPID+Issuer Key as the User's identifier is looking for trouble.”

 

                                                                Talk to you tomorrow,

                                                                -- Mike

 

From: Michael McIntosh [mailto:mikemci@us.ibm.com]
Sent: Wednesday, January 07, 2009 8:18 AM
To: John Bradley
Cc: imi@lists.oasis-open.org; Mike Jones
Subject: Re: [imi] Clarifications to the spec to discuss for our call on Thursday

 

John Bradley <jbradley@mac.com> wrote on 01/07/2009 11:00:04 AM:

<snip>  
>
> However a IP/STS trusting a PPID coming from a selector has always
> made me a bit nervous.   I could as an example modify the Higgins
> selector to send arbitrary PPID values in a RST.  If the IP/STS say
> Verisign blindly includes it in its signed response the RP checking
> the PPID and sig as it would for a p-card could be spoofed if it was
> relying solely on those two values.
>
> Including a pre-calculated PPID may make some IP/STS lazy and not
> calculate it themselves when they clearly can.
>
> Minimally I think the PPID coming from the selector should be used
> as input to some other hash function to at-least make spoofing more difficult.
>
> I know the spec allows for using the PPID as input to a custom
> function,  but I have never seen an explanation of why that is a good idea.  
>
> I am OK with always including the PPID in the request if someplace
> we document the security issues around PPID in m-cards.

In order for the IdP to compute the PPID, it needs to know the RP ID.
A user may not want to tell the IdP the name of every site they visit.
If the User's client computes a partial ClientPsuedonym as input to the PPID computation,
a proper PPID can be computed by the IdP,
assuming it also includes some additional user specific "secret" into the computation,
without letting the IdP know the RP.

Any RP that blindly accepts a PPID and not a signed PPID+Issuer Key as the User's identifier is looking for trouble.
Any user can set up an Issuer to generate a token with any PPID.

Any IdP that blindly returns the ClientPsuedonym as the PPID is looking for trouble.
Any user with an account on that same IdP can send another user's ClientPsuedonym and get a token from the IdP.

> Mike Jones <Michael.Jones@microsoft.com>
>
> In practice, the IssuerId is only used for managed cards backed by
> self-issued cards. Therefore, I propose to change “The element
> content may be empty” to “The element content may be empty when the
> card is not a managed card backed by a self-issued card” and to change “The
> ic:IssuerId value SHOULD be the empty string for self-issued cards” to “The
> ic:IssuerId value SHOULD be the empty string for self-issued cards
> and MUST NOT be empty for managed cards backed by self-issued cards”.
>

I don't agree. There are some IdP endpoints hosting multiple logical Issuers (different signing keys) that need this value to determine the correct Issuer.

> 3. Clarifying that self-issued cards support the PPID claim even
> though not listed as an ic:SupportedClaimType element
>
> I have recently learned that even though all self-issued cards
> support the PPID claim, when self-issued cards are written to the
> Information Cards Transfer Format (a .crds file), the PPID claim is
> not listed as a SupportedClaimType in the card’s
> SupportedClaimTypeList. I propose that we document this anomaly in
> the specification so implementations behave consistently.

Why not just add the ClaimType for PPID? I agree with Tony that there might need to be multiple PPID algorithms supported and maybe the claim type would need to specify the algorithm(s) supported.