|Mike Jones||Jan 6, 2009 9:45 pm|
|Anthony Nadalin||Jan 7, 2009 7:14 am||.gif, .gif|
|John Bradley||Jan 7, 2009 7:59 am|
|Michael McIntosh||Jan 7, 2009 8:17 am|
|Mike Jones||Jan 7, 2009 9:57 am|
|Anthony Nadalin||Jan 7, 2009 10:24 am||.gif, .gif|
|John Bradley||Jan 7, 2009 11:20 am|
|Michael McIntosh||Jan 7, 2009 12:17 pm|
|John Bradley||Jan 7, 2009 1:01 pm|
|Mike Jones||Jan 7, 2009 6:51 pm|
|John Bradley||Jan 8, 2009 6:23 am|
|Anthony Nadalin||Jan 8, 2009 7:07 am||.gif, .gif|
|Michael McIntosh||Jan 8, 2009 7:42 am|
|John Bradley||Jan 8, 2009 7:57 am|
|Mike Jones||Jan 8, 2009 7:58 am|
|Mike Jones||Jan 8, 2009 8:01 am||.gif, .png, .png|
|John Bradley||Jan 8, 2009 8:02 am|
|Subject:||Re: [imi] Clarifications to the spec to discuss for our call on Thursday|
|From:||John Bradley (jbra...@mac.com)|
|Date:||Jan 7, 2009 7:59:41 am|
1) I am neutral on including the including the selector calculated PPID in the RST where the scope information is present. On the surface it is only a small amount of overhead.
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.
2) How about “The element content may be the empty string when the card is not a managed card backed by a self-issued card” to make it clear it is not to be NULL.
3) I think I agree with Tony "Identity Selectors MUST 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."
On 7-Jan-09, at 12:15 PM, Anthony Nadalin wrote:
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
<graycol.gif>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
<ecblank.gif> From: <ecblank.gif> Mike Jones <Mich...@microsoft.com> <ecblank.gif> To: <ecblank.gif> "im...@lists.oasis-open.org" <im...@lists.oasis-open.org> <ecblank.gif> Date: <ecblank.gif> 01/06/2009 11:46 PM <ecblank.gif> Subject: <ecblank.gif> [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 188.8.131.52. 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 184.108.40.206. 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!