Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Re: Improved i-card.owl checked in
Title: Re: Improved i-card.owl checked in
Paul,
 
>> 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.
When I wrote  "...replaces IModel interfaces with something you were going to propose" here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html  , I supposed you have a new idea to replace IModel interfaces with something.  It looks I misunderstood your sentence.
 
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Saturday, September 19, 2009 6:27 PM
Subject: Re: Improved i-card.owl checked in




On 9/18/09 6:56 AM, "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 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:ptrevithick@xxxxxxxxx>  
 
To: Sergey Lyakhov <mailto:slyakhov@xxxxxxxxxxxxxx>  
 
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>  ; Igor  Tsinman <mailto:itsinman@xxxxxxxxxxxxx>  ; higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>  
 
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" <slyakhov@xxxxxxxxxxxxxx>  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.

 


Back to the top