| Paul and Susan,
Here's is where we are on one of the issues that you both (and Pam) have run in to... I used this as an opportunity to summarize what I understand. I'm hoping anyone on this list can chime in to correct anything I've gotten wrong.
Specifications
There are three specifications of how to compute the PPID. I have invented the term "IMI 1.0a" - ISIP 1.0
- IMI 1.0 (also known as ISIP 1.5)
- IMI 1.0a is IMI 1.0 with the change described in [2]): (see Changes Made in ISIP V1.5 on page 72). It says: "To provide a migration path from non-EV to EV certs, the RP PPID Seed for a non-EV cert containing the same OLSC values is the same as for an EV cert, resulting in the same PPID"
CardSpace Versions
- .Net 3.0 version: implements ISIP 1.0 (according to [1])
- .Net 3.5 version: implements ISIP 1.5 (according to [1])
- .Net 3.5 SP1 version: (i) implements IMI 1.0a for token of p-card (ii) implements ISIP 1.0, IMI 1.0 and IMI 1.0a (all three) to find a p-card that matches the PPID credentials of a "backed" m-card.
- .Net 3.5 SP2 version: same as .Net 3.5 SP 1?
- CardSpace 2.0 beta version: same as .Net 3.5 SP 1?
Azigo Versions
- 2.0.0.35 --> 2.0.0.40 versions: implements IMI 1.0
Avoco Versions
- It appears to use some different PPID logic than CardSpace WRT to finding a matching p-card against the PPID of a backed m-card.
Incompatibilities (bugs):
- Pam reported: You can't export a p-card backed m-card from Azigo 2.0.0.35 and import into .Net 3.5 SP1 version of CardSpace.
- PaulB reported: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace. 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector. In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=*.azigo.net|L=|S=|C=|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty.
The above bullets are caused by the same set of inter-related issues. The root cause is an inability to validate the certificate of cardpres.azigo.net and as a result Azigo computes the wrong PPID for this site. We thought that we could fix this by including then entire certificate chain in the .crd. We did this today, but there are other related issues and we need another 2 days to deploy a new version of our hosted i-card service (service.azigo.com)
--Paul
On Feb 21, 2010, at 3:42 PM, Paul Battersby wrote: Hi Paul, Ive done a bit more investigation into this from our side using the following scenarios from our Cloud selector: 1) An Azigo Managed card backed by a CardSpace Personal card using a crds imported from CardSpace 2) An Azigo Managed card backed by an Azigo Personal card using a crds imported from Azigo Desktop selector In the first case the PPID matches (i.e. the PPID calculated by the selector matches the PPID stored in the managed card). The algorithm uses a Relying Party Id generated from |O=*.azigo.net|L=|S=|C=|. The second scenario fails. However, if I force the code to use a Relying Party Id generated from the public key of the certificate then the PPID matches. This is rather strange as the certificates in the Managed cards from both scenarios are exactly the same and the public key should only be used if the certificate is not valid or the Organizational units are empty. Also, once the card is found and the selector contacts the Azigo STS web service I get an error: HTTP/1.1 500 Internal Server Error Date: Sun, 21 Feb 2010 20:20:35 GMT Server: Apache Accept: application/soap+xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 SOAPAction: "" Content-Length: 297 Connection: close Content-Type: application/soap+xml;charset=utf-8 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"><env:Header/><env:Body><env:Fault><env:Code><env:Value>env:Receiver</env:Value></env:Code><env:Reason><env:Text xml:lang="en">Incorrect result size: expected 1, actual 0</env:Text></env:Reason></env:Fault></env:Body></env:Envelope> Do you have any clues as to this difference in behavior and the error code that Im receiving? Thanks in advance, Paul Battersby. From: Paul Trevithick [mailto:Paul@azigo.com]
Sent: 19 February 2010 3:26 PM
To: Pamela Dingle
Cc: Paul Battersby; Susan Morrow
Subject: Re: PPID calculation Hi Pam, We're looking into these incompatibilities... I know I tried to export personal backed managed cards from azigo to cardspace classic and got errors. Can we get a copy of that/those cards by any chance? On Feb 18, 2010, at 4:32 AM, Susan Morrow wrote:
Hello Paul, We met last year at the OpenID summit. We have been testing with various cards in readiness for the test run this Friday for RSA and have come across a few issues with the Azigo cards backed by a personal card. I asked Pamela if she had any ideas about this and she said she also has had similar problems (see thread below). We were wondering if this was related to the way you calculate your PPID do you use the IMI V1.5 to do this? Be useful if you could let us know, so we can get to the root of the problem and try to get interoperability with all cards. All the best Susan Registered Office: Avoco Secure, 8 Clifford Street, London W1S 2LQ Company number : 04778206 - Registered in England and Wales. secure2trust has been awarded SC Magazine Best Buy and 5 stars in 2006 and 2008 Avoco Secure is a member of the Microsoft Secure IT Alliance which is defining the industry security solutions.
The Butler Group believes that secure2trust can provide organisations with a level of protection for content that cannot be provided through other types of applications.
This email including any attachments is confidential and may be legally privileged. This email is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error, please advise the sender IMMEDIATELY by return email and then DELETE it from your system. The unauthorised use, distribution, dissemination, copying or alteration of this email is strictly FORBIDDEN.
-----Original Message-----
From: Pamela Dingle [mailto:pameladingle@gmail.com]
Sent: 17 February 2010 15:09
To: Susan Morrow
Cc: Paul Battersby
Subject: Re: PPID calculation
As far as I know, IMI v1.5 is the gold standard, I would mail the
google group. I know I tried to export personal backed managed cards
from azigo to cardspace classic and got errors.
I can refer you directly to Paul Trevithick and Tom Carroll if you
would rather do that.
Cheers,
Pam
Sent from my iPhone
On 2010-02-17, at 2:26 AM, "Susan Morrow"
<susan.morrow@avocosecure.com> wrote:
> Hi Pam,
>
> We were wondering this end about how everyone is calculating the PPID?
>
> We have been testing our cloudcard with various cards and all are fine
> except for one of Azigo's, the personal backed card.
>
> We calculate our PPID based on Identity Selector Interoperability
> Profile
> V1.5 - do you know if Azigo use the same protocol?
>
> Sus
>
>
>
> Susan Morrow
> Avoco Secure
> http://www.avocosecure.com
> T: +44 (0) 7917 507 826
> E: susan.morrow@avocosecure.com
>
>
> Registered Office: Avoco Secure, 8 Clifford Street, London W1S 2LQ
> Company number : 04778206 - Registered in England and Wales.
>
> secure2trust has been awarded SC Magazine Best Buy and 5 stars in
> 2006 and
> 2008
>
> Avoco Secure is a member of the Microsoft Secure IT Alliance which is
> defining the industry security solutions.
>
>
> The Butler Group believes that secure2trust can provide
> organisations with a
> level of protection for content that cannot be provided through
> other types
> of applications.
>
>
> This email including any attachments is confidential and may be
> legally
> privileged. This email is intended solely for the use of the
> individual to
> whom it is addressed. If you are not the intended recipient, be
> advised that
> you have received this email in error, please advise the sender
> IMMEDIATELY
> by return email and then DELETE it from your system. The
> unauthorised use,
> distribution, dissemination, copying or alteration of this email is
> strictly
> FORBIDDEN.
>
>
>
|