Sergey, I prefer #1 somewhat more than #2.
--Paul On 12/9/09 7:07 AM, "Sergey Lyakhov" <[email protected]> wrote: > Paul, > >>> >> 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 > <http://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/claim > s/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 <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: 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 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/ontolo >>>> gy/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
