Paul,
> 1. I presume that youve 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.
> 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?
> 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.
> 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.
Thanks, Sergey Lyakhov
----- Original Message -----
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:
- I presume that
youve stayed entirely within the IMI specifications? It seems that you
have. That was the intent.
- 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
- WRT your #18: I
made these changes, thanks.
- WRT your #17: Do
you have ideas about how to represent these values?
- 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 Ill turn them into diagrams and Ill
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.
|