From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Tuesday, November 07, 2006
9:23 PM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions';
higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] Claims
vs. Attributes and Mapping
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
Okay, let be
wade into this swamp again…I think we’d all say that our Token
Service a provider of claims (not attributes). So far so good. But in reality
the Higgins Token Service is just a “signer”
and acts as the trust authority that you mention. When you examine where the
Token Service (TS) and its associated Token Providers gets its/their data fields
(as I’ll call them for now) you find the answer is “from IdAS”.
Other systems may do things differently, but armed as we are with something as
powerful as IdAS, it just keeps making sense to retrieve these data fields from it directly, and have the
TS just be a “signer.” Ah, but what is the namespace of these data fields? Since TS only wants to “think”
in terms of claim namespaces (e.g. the CardSpace claim type namespace (URIs))
it’s going to want to consume data
fields from IdAS in the claim namespace. While it is true that the
TS may well transform these data fields
(e.g. the proverbial “age=33” to “age>21”
transformation), it is still going to want something external to itself like,
say, IdAS to provide it with data fields
whose URI for “age” is in the claim namespace that it “thinks
in” and understands. So…. although in theory we can stick to our
canon that IdAS is all about attributes,
and the TS, ISS, etc., are all about claims,
in practice the picture is a big fuzzier. Our IdAS provides data fields in claim namespace. The
only difference between these data fields
and claims output by the TS are (a) privacy-enhancing transformations may not
have been done and (b) the whole set of them has not been signed. If, as I
think we will, we decide to continue call these data fields attributes, then we’ll at least
have to say, awkwardly, that (at least in this case) that these IdAS attributes
are in claim namespace.
BTW, the picture
gets still fuzzier when we deal with I-Card types that don’t even use a Token
Service. I-Cards that, for example, don’t send a DI/token to the RP, but instead
send the metadata necessary for the RP to open a dynamic RSS channel back to
the IdAS data source. In this case what should we call what we provide directly
to the RP, “claims” or “attributes”? If we call them
attributes, then we need to have a Relying Party Security Policy language that
sometimes talks about required claims
and sometimes (e.g. for RSS-consuming sites) talks about required attributes. That seems messy. If,
on the other hand, we call them all claims then we’re back on the
slippery slope to saying that IdAS is a provider of claims. And we don’t
really want to do that either.
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
