Re: Improved i-card.owl checked inPaul, >> 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?
Now IdAS confirms to CDM 1.1. So, to store claim values of p-card we need to choose one of the following aproaches: 1. P-Card has a single-valied attribute with "Claims" Entity. All attributes of this entity has attrID == claim type. In this case types of claim values are predefined by schema. Example: xmlns:claims=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ <icard:ClaimList rdf:ID="myClaims"> <claims:givenname rdf:datatype="xsd:string">myName</claims:givenname> </icard:ClaimList> 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. Example: <icard:ClaimList rdf:ID="myClaims"> <icard:Claim> <icard:claimType rdf:datatype="xsd:string">http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname</icard:claimType> <icard:claimValue rdf:datatype="xsd:string">myName</icard:claimValue> </icard:Claim> </icard:ClaimList> Which aproach should we use? Thanks, Sergey Lyakhov ----- Original Message ----- From: Paul Trevithick To: Sergey Lyakhov Cc: Vadym Synakh ; Igor Tsinman ; higgins-dev Sent: Saturday, September 19, 2009 5:27 PM Subject: Re: Improved i-card.owl checked in 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 not-but 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 not-but 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
