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

[Anthony Nadalin <drsecure@us.ibm.com>]

Mike,

1). I don't believe that the PPID should aways be specified (provided) as this is additional overhead that is not needed in all scenarios. I'm not convinced that 1 PPID algorithm is right either, we have seen flaws in this area before, so it may be good to go down the route of having a selectable PPID algorithm.

2). I don't think that "empty" content is also something we want as its not clear if this is a " " or a NULL

3). I don't think this helps, moving forward, I can see this for compatability but moving forward it not clear, so we should state that the selector MUST display as this is a new version of the specification

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Mike Jones ---01/06/2009 11:46:20 PM---I’ve identified a few clarifications that I believe we should make in the specification, which I’d like us to discuss on Thur

From:	Mike Jones <Michael.Jones@microsoft.com>
To:	"imi@lists.oasis-open.org" <imi@lists.oasis-open.org>
Date:	01/06/2009 11:46 PM
Subject:	[imi] Clarifications to the spec to discuss for our call on Thursday

---

I’ve identified a few clarifications that I believe we should make in the specification, which I’d like us to discuss on Thursday’s call.  They are:
 
1.  Clarifying that the ClientPseudonym/PPID value is always sent when a PPID is requested
 
While the draft currently implies that the ClientPseudonym/PPID value is only sent to Identity Providers for non-Auditing cards, in practice, it is always sent when the PPID claim is requested by the relying party, whether token scope information is sent or not.  This is useful for Identity Providers since it allows a single, consistent PPID generation algorithm to be used by Identity Providers for both auditing and non-auditing cards.
 
Lines 938-943 currently read:

When the target scope information is sent in the token request using the wsp:AppliesTo element, that information can be used by the IP/STS to generate the appropriate PPID value. When token scope information is not sent, an Identity Selector SHOULD specify the PPID value it would like to be used in the issued token by using the ic:PPID element in the RST request. This SHOULD be produced as described in Section 3.3.4.1. 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.

and lines 969-970 currently read:

When token scope information is not sent in a token request to an IP/STS that supports the PPID claim, an Identity Selector SHOULD compute the PPID information it sends in the RST message as follows:

Therefore, I propose to change lines 938-943 to read:

When a Relying Party requests a PPID claim, an Identity Selector SHOULD provide a PPID value that can be used to compute the PPID claim value in the issued token by using the ic:PPID element in the RST request. This SHOULD be produced as described in Section 3.3.4.1. 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. Alternatively, when target scope information is sent in the token request using the wsp:AppliesTo element, the IP/STS may instead choose to use that information to generate an appropriate PPID value.

and to change lines 969-970 to read:

When a token request for a PPID claim is sent to an IP/STS, an Identity Selector SHOULD compute the PPID information it sends in the RST message as follows:

2.  Clarifying when an ic:IssuerId value is required
 
Currently lines 1431-1434 of Committee Draft 1 read:

../ic:InformationCardMetaData/ic:IssuerId
This required element contains an identifier for the Identity Provider with which a self-issued credential descriptor in a card issued by that Identity Provider can be resolved to the correct self-issued card. The element content may be empty.

and lines 1499-1506 read:

6.1.2 Computing the ic:IssuerId
The ic:IssuerId value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically:
· Compute IP Identifier in the same manner as RP Identifier in Section 7.6.1, except that the certificate from ds:KeyInfo is used, rather than the Relying Party’s.
Use the IP Identifier as the ic:IssuerId value.
The ic:IssuerId value SHOULD be the empty string for self-issued cards.

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”.
 
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.
 
Therefore, at the end of the definition of the PPID claim, after line 2041, I propose to add this text:

Note: For compatibility with existing Identity Selectors, when saving a self-issued Information Card in the Information Cards Transfer Format defined in Section 6, an Identity Selector MAY omit listing the PPID claim as an ic:SupportedClaimType from the ic:SupportedClaimTypeList, even though the PPID claim is supported by the card. Likewise, Identity Selectors SHOULD support the PPID claim for all self-issued cards, even though this claim may not have been listed as an ic:SupportedClaimType when the card was imported.

====
 
Talk to you Thursday!
 
                                                                -- Mike