Re: [higgins-dev] Claims vs. Attributes and Mapping

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

The distinction between a claim and an attribute is more a matter of usage
than the nature of the thing itself. Claims are a kind of attributes that
are intended for external consumption by relying parties and thus are under
some special constraints (e.g. they should be used (a) as sparingly as
possible and (b) must be in the namespace that the relying party understands
(c) are often packaged together and digitally signed (d) might even be
cryptographically blinded still further (e.g. with idemix), etc.) but
they're attributes all the same.

I can see the argument where "bankbalance=$10k", or "age=30" (attribute) transformed to "age>21" (claim) can be viewed as a an attribute or rendering of an attribute value as a claim. From that sense, it depends on usage.

I think the key semantic difference between a claim and an attribute is about 'authoritative source' and related trust. One can see which identity data source/context provider an attribute came from, .. and claims are about issuing party/token service.

So, while I see how claims and attributes have synergy and we look at use cases to determine our approach, i am still not convinced that "IdAS Context can be used directly as the source for Claim data. " I feel it will just confuse what they are authoritative for. I think IdAS Context must be scoped for attributes, while token service for claims... that will outline which entities in the framework are responsible for what. Else, we will have issues with how people use the framework and evaluate trust on the components

Regards,
Raj


"Tom Doman" <TDoman@xxxxxxxxxx>

"Tom Doman" <TDoman@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

11/03/2006 07:26 PM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	[higgins-dev] Claims vs. Attributes and Mapping

OK Paul.  Jim and I both looked at and discussed your proposal below and we decided to go ahead and implement it to see how it'd look.  If everyone else agrees, the only thing we'd do that we haven't already done, is create a mapping table XML Schema construct for our CP configuration file (to be quick and dirty, we just hard coded a specific mapping table in for Card Space schema, which, parenthetically, is VERY close to LDAP schema for the 12 or so items they've defined).  Anyway, the associated generated OWL which follows your suggestion below is attached.

>From our tests, here's a sample Digital Subject output:
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_organizationalPerson 
cn=tdoman,ou=people,o=bandit
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_objectclass 
top
person
organizationalPerson
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_structuralObjectClass 
top
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_modifyTimeStamp 
200308281414Z
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname 
Doman
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_cn 
tdoman
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_creatorsName 
cn=admin,o=bandit
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_modifiersName 
cn=admin,o=bandit
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_creationTimeStamp 
200308281414Z
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_userPassword 
Unknown: java.nio.HeapByteBuffer[pos=0 lim=6 cap=6]
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname 
Tom

Are we all in agreement on this as a long term approach to claim vs. attribute mapping?

Tom

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 11/02/06 3:03 AM >>>
Inline below

  _____  

From: higgins-dev-bounces@xxxxxxxxxxx 
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, November 01, 2006 4:39 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: [higgins-dev] Another topic (or two) for Nov 2 phone call

 

These have to do with claim/attribute mappings.

 

An area I've been thinking a lot about in the last week or so. 

I had initially thought for simple cases, if we were to implement an IdAS
"mapping provider" (a provider which could be plugged in front of a "real"
provider), that the IdAS consumer could pass claim names into IdAS and IdAS
(via the mapping provider) could map and emit attributes back out with claim
names (rather than the Attribute type URIs used by the underlying provider).

 

It seems this actually can't be done however, since claim URIs may not be
Higgins Attribute type URIs, and IdAS types must be Higgins Attribute URIs. 

 

I think perhaps it can be done: A Context could use a schema, that for
example, treated the Microsoft CardSpace surname claim type as a
higgins:attribute:

 

         <owl:ObjectProperty
rdf:about="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">

                     <rdfs:domain rdf:resource="#Person"/>

                     <rdfs:range
rdf:resource="&higgins;#StringSimpleAttribute"/>

                     <rdfs:subPropertyOf
rdf:resource="&higgins;#attribute"/>

         </owl:ObjectProperty>

 

Where #Person is a subclass of higgins:DigitalSubject. 

 

This is why I deleted last week the component called "Attribute/Claim
Mapping" from here <http://wiki.eclipse.org/index.php/Core_Components> . The
I-Card Provider must produce Claims, but we don't need a separate Higgins
component in the architecture. Whether the Token Issuer is pushed claim data
by an I-Card Provider or a Token Provider pulls it, I am increasingly
comfortable that an IdAS Context can be used directly as the source for
Claim data. 

 

The distinction between a claim and an attribute is more a matter of usage
than the nature of the thing itself. Claims are a kind of attributes that
are intended for external consumption by relying parties and thus are under
some special constraints (e.g. they should be used (a) as sparingly as
possible and (b) must be in the namespace that the relying party understands
(c) are often packaged together and digitally signed (d) might even be
cryptographically blinded still further (e.g. with idemix), etc.) but
they're attributes all the same.

 

I now think that an IdAS Context can offer to a I-Card Provider or a Token
Provider a higgins:attribute that, as shown above, uses a Claim namespace
(dictated by the RP) and that can be trivially converted into a Claim for
external consumption. 

 

 If this isn't the case, I need clarification.  

 

 

If it is the case, I suppose we could skip this topic and move right into
the next one:

 

claim/attribute mapping is now shown
<http://wiki.eclipse.org/index.php/Core_Components>  to happen inside I-Card
Providers

 

Well, I was trying to indicate that it is the responsibility of the I-Card
Provider. As I mention above, it can delegate this responsibility to a
Context Provider.

 

<snip>.

 

[attachment "test.owl" deleted by Nataraj Nagaratnam/Raleigh/IBM] _______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev