3 submissions of potential new work items to the IMI TC

[Mike Jones]

1.  New optional ic:InformationCard elements

2.  X509 credential enhancements

3.  Information Card provisioning

 

http://lists.oasis-open.org/archives/imi/200904/msg00000.html

 

                                                                -- Mike

 

[Axel.N...@telekom.de]

The RoamingStore has no extension point but I want to store some data about the store inside the store.

 

Should we change:

 

<xs:element name="RoamingStore" type="tns:RoamingStoreType"/>
<xs:complexType name="RoamingStoreType">
 <xs:sequence>
  <xs:element ref="tns:RoamingInformationCard" minOccurs="1" maxOccurs="unbounded"/>
 </xs:sequence>
</xs:complexType>

 

to

<xs:complexType name="RoamingStoreType">
 <xs:sequence>
  <xs:element ref="tns:RoamingInformationCard" minOccurs="1" maxOccurs="unbounded"/>
 </xs:sequence>

 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:complexType>

 

As I am no XML expert I am not sure whether this is the right way to make the RoamingStore extendable.

If a selector finds elements in the roamingstore that it does not understand it should ignore them.

I think it makes no sense to request that those elements are restored when the cardstore is backuped because the cardstore might be a collection of cards from different roaming stores.

 

-Axel

 

---

Von: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] Im Auftrag von Mike Jones
Gesendet: Mittwoch, 1. April 2009 23:47
An: icf-wg...@googlegroups.com
Betreff: [ICF.WG.OASIS] 3 submissions of potential new work items to the IMI TC

[Axel.N...@telekom.de]

The InformationCardPrivateData has not extension point. Only the "public" InformationCardMetaData has an extension point in InformationCardType.

 

<xs:element name="InformationCardPrivateData" type="tns:InformationCardPrivateDataType"/>
<xs:complexType name="InformationCardPrivateDataType">
 <xs:sequence>
  <xs:element ref="tns:MasterKey"/>
  <xs:element ref="tns:ClaimValueList" minOccurs="0"/>
 </xs:sequence>
</xs:complexType>

 

Should we add an extension point after ClaimValueList?

 

I hesitate to suggest this because I have no immediate need for this but I looks like people should be able to store additional private data inside InformationCardPrivateData.

Only InformationCardPrivateData can be PIN protected.

 

-Axel

---

Von: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] Im Auftrag von Mike Jones
Gesendet: Mittwoch, 1. April 2009 23:47
An: icf-wg...@googlegroups.com
Betreff: [ICF.WG.OASIS] 3 submissions of potential new work items to the IMI TC

[Axel.N...@telekom.de]

Just remembered why I wanted this (it is midnight I should go to sleep).

 

ISIP requires that the PPID be unlinkable and suggests that the PPID SHOULD generated in a special but quite complex way specified in ISIP.

I want to store other values inside InformationCardPrivateDataType that helps the selector to generate an unlinkable PPID.

 

I might just generate a public-private RSA keypair for each RP and store it here keyed by RP_Identifier (perhaps).

 

This

    <xs:element ref="tns:MasterKey"/>

should be changed to
    <xs:element ref="tns:MasterKey"  minOccurs="0"/>

 

-Axel

---

Von: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] Im Auftrag von Nennker, Axel
Gesendet: Freitag, 3. April 2009 23:55
An: icf-wg...@googlegroups.com
Betreff: [ICF.WG.OASIS] InformationCardPrivateData extension?

[Mike Jones]

If you’re going to cache these values so save recomputing them later, I’d think that you want to actually cache triples of <RP ID,  PPID, SigningKey>.  When the RP ID matches the current RP, you would use the cached PPID and SigningKey values.

 

Even before there’s a standard extensibility point of the nature that you’re describing, there’s nothing stopping you from saving this data inside your selector’s private persistent card store data structures but never exporting it.  Given that this data is a cache of data values that can be dynamically recalculated, I see no real downside to this approach, which you can implement today.

 

                                                                -- Mike

<BR<BR

[Axel.N...@telekom.de]

Openinfocard currently uses its own cardstore format but I want to move away from that to a "standard" like RoamingStore.

But inside RoamingStore many things are not standardized; e.g. we have no standard to store the card-usage-history.

I would like to be able to store all the selector knows inside a RoamingStore without violating identity.xsd.

 

I think that an algorithm to achieve unlinkability that is a SHOULD in ISIP should not manifest itself in a required element (masterkey) in the roaminginformationcard.

 

--Axel

 

I think PPID might be a function of RP_ID and public key. So I index by RP_ID and store the keypair there.

 

---

Von: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] Im Auftrag von Mike Jones

Gesendet: Samstag, 4. April 2009 00:30
An: icf-wg...@googlegroups.com
Betreff: [ICF.WG.OASIS] Re: InformationCardPrivateData extension?

[Mike Jones]

I don’t think any of us believe that RoamingStore is an ideal card store format.  I know that CardSpace uses a different private format, as apparently does OpenInfoCard.  I personally wouldn’t advocate people using RoamingStore as the card store, in part, because the card usage history and potentially other selector-specific information is not captured there.

<BR

[Axel.N...@telekom.de]

When you want to transfer the cardstore to another location e.g. a cardstore in the cloud or a portable device it is not that farfetched to reuse the RoamingStore.

It has nearly all the information one needs and I see no harm if e.g. Azigo and Higgins and openinfocard and others agree on a format for card usage history.

Why reinvent the wheel four times.

 

When we are talking about one selector that moves the card store from place to place then it might prefer to use its proprietary card store format.

But if openinfocard would access an Azigo card store then we would need a common format and RoamingStore is not that bad.

 

-Axel

---

Von: icf-wg...@googlegroups.com [mailto:icf-wg...@googlegroups.com] Im Auftrag von Mike Jones

Gesendet: Samstag, 4. April 2009 01:00