On 9/18/09 6:56 AM, "Sergey Lyakhov" <[email protected]> wrote: > Paul, > >> > 1. I presume that you¹ve stayed entirely within the IMI specifications? It >> seems that you have. That was the intent. > > I used MS CardSpace 1.5 doc and infocard xml schema > http://schemas.xmlsoap.org/ws/2005/05/identity. I reviewed IMI 1.0 > specification, and did not find any difference. However I found out that > ic07IssuerInformation element has a predefined data structure, and should not > be a string. As a result, I've added IssuerInformationEntry class, entryName > and entryValue datatype properties, replased ic07IssuerInformation with the > same object property. Also I fixed some my previous errors. I attached updated > i-card.owl schema. > > ## Great. Thanks. > >> > 2. WRT your #16: CDM does (in my mind) support polymorphism although I >> realize that the IdAS API does notbut we can fix this when we remove the >> Model APIs from IdAS > > Actually, Model API could correctly treat a polymorphism in a schema. Are you > going to replace it with a model proposed by Jim a year ago (I and Valery > think it is not convenient to use it) or plain just to use owl schema instead > of Model API? > > ## I have yet another idea up my sleeve. Valery probably won¹t like it either, > but we¹ll see. I¹ll let you know within 1 week. > >> > 4. WRT your #17: Do you have ideas about how to represent these values? > > I see the following cases: > 1. Store claim values in separate Entity. In this case transaction problems > possible if entities are stored in different contexts. > 2. Store values as a complex attribute value(s) : > 2.1. P-Card has a single-valied attribute with "Claims" value. All attributes > of this value has attrID == claim type. In this case claim values are > predefined in schema. > 2.2. P-Card has a multy-valied attribute with "Claim" values. These values, in > turn, have two attributes: claimType and claimValue. In this case we can use > the same schema for different sets of claims. > > ## Before I respond to your proposal, I want to see if we first agree on > something else. In CDM 1.1 attributes can have either (a) literal value(s) or > (b) complex value(s). If (b) the value IS an entity. Do you agree with that? > >> > 5. Would you be willing to create an i-card-instance.owl file that contains >> an example p-card and an example m-card? > > I attached icardinstances.owl with those example cards. This ontology imports > claimTypes.owl where claim type instances are defined. > > ## Wonderful, thank you. > > Thanks, > Sergey Lyakhov >> >> ----- Original Message ----- >> >> From: Paul Trevithick <mailto:[email protected]> >> >> To: Sergey Lyakhov <mailto:[email protected]> >> >> Cc: Vadym Synakh <mailto:[email protected]> ; Igor Tsinman >> <mailto:[email protected]> ; higgins-dev >> <mailto:[email protected]> >> >> Sent: Wednesday, September 16, 2009 6:47 AM >> >> Subject: Improved i-card.owl checked in >> >> >> Sergey, >> >> This is a giant improvement, thank you. I have checked it in here [1]. >> >> Questions for you: >> >> 1. I presume that you¹ve stayed entirely within the IMI specifications? It >> seems that you have. That was the intent. >> 2. WRT your #16: CDM does (in my mind) support polymorphism although I >> realize that the IdAS API does notbut we can fix this when we remove the >> Model APIs from IdAS >> 3. WRT your #18: I made these changes, thanks. >> 4. WRT your #17: Do you have ideas about how to represent these values? >> 5. Would you be willing to create an i-card-instance.owl file that contains >> an example p-card and an example m-card? If so I¹ll turn them into diagrams >> and I¹ll use them to replace the overly simplistic diagrams here [2]. I >> think that will help folks understand this sub-part of PDM 1.1 (i.e. The >> i-card.owl part) much better. >> >> --Paul >> >> [1] >> https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology >> /org.eclipse.higgins.ontology/i-card.owl >> [2] http://wiki.eclipse.org/Persona_Data_Model_1.1#I-Cards >> >> >> On 9/15/09 2:58 PM, "Sergey Lyakhov" <[email protected]> wrote: >> >> >>> Paul, >>> >>> I made the following changes to attached i-card.owl: >>> >>> 1. I-Card should be able to contain extensions (in xml form). >>> 2. ClaimType should also have the following datatype properties : >>> claimTypeName, claimTypeDescription. >>> 3. supportedClaimType should be object property with ClaimType range. >>> 4. I-Card should have supportedTokenType datatype property. >>> 5. pinDigest should have I-Card as a range (now CardSpace supports it for >>> both m- and p-card, we did not yet implement it for m-card). >>> 6. cardName property missed for I-Card. >>> 7. cardVersion property missed for I-Card. >>> 8. masterKey property missed for I-Card. >>> 9. langId property missed for I-Card. >>> 10. issuer property missed for I-Card. >>> 11. stsPrivacyPolicyVersion missed for M-Card. >>> 12. M-Card should have tokenService object property with TokenService >>> range. >>> 13. TokenService should have endpointReference object property with >>> EndpointReference range. >>> 14. EndpointReference should have address, metadataAddress and certificate >>> properties. >>> 15. TokenService should have userCredential object property with >>> UserCredential range (also, there is CredentialDescriptor class defined in >>> i-card.owl which duplicates UserCredential). >>> 16. UserCredential should be able to contain all forth credential type >>> descriptors. I added them as extended classes of UserCredential, but not >>> sure it is correct. Does CDM support polymorphism? >>> >>> Also the following changes need to be done: >>> >>> 17. P-card needs claim values. >>> 18. strongRecipientdentityRequired - the label contains "require aplies >>> to", but this is not quite correct. It meaning is RP should provide a >>> cryptographically protected identity, for example, an X.509v3 certificate. >>> Also "I" is missed in the name of this property, moreover, in CardSpace docs >>> it is named as RequireStrongRecipientIdentity. >>> >>> >>>> >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
