From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Wednesday, November 08, 2006
5:31 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
Paul
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”?
Claims.
If we call them claims then one must
say that in this particular case IdAS is acting as claim-providing service,
right?
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”.
Well, you
will find that to be the answer in certain cases (maybe in current
implementation) ... but not necessarily all the time.
I
realized you had dropped the 'attribute-to-claim transformation' component.
I dropped it because (a) it is ultimately
the I-Card Provider’s responsibility to somehow produce either a DigitalIdentity
token (for DI-issuing I-Cards) or metadata that points to some data source (e.g.
a URL from for RSS I-Cards) including any
necessary attribute-to-claim transformations. [In practice the
I-Card Provider probably uses other services like a TS or IdAS or both to
fulfill this responsibility] and (b) at present and for at least the short term
we don’t have any generic, separate code that does attribute-to-claim
transformation and I’m trying to follow a discipline that Higgins 1.0 has
code for each one of the component “boxes” in the component architecture
diagram.
If we had
that.. then the source of these claims is that component. It is the
resposibility of that component. It can be ONE implementation where that
transformation is a "no-op" and it delegates to IdAS. There can be
other implementations, where the claims-provider takes data/attributes from
IdAS and does its own "inference" and produces claims. Maybe we have
claims-provider.. and whether it gets from IdAS or makes up its own is upto it.
This would be the piece that both STS and ICard provider can use. In Higgins,
we could have a default claims-provider which is a no-op but delegates to an
IdAS.
We must interface a Token Provider (TP)
to IdAS directly (e.g. for the demo Novell is working on) because in that
deployment architecture there is no I-Card Provider at all! --just an STS with
a TP that happens to use IdAS.
If we did have a separate
attribute-to-claim transformer component, sheer convenience would dictate that
it use the same API as IdAS that TP already has to interface to.
And if that’s the case then you
can just think of an IdAS context being used
as an attribute-to-claim transformer. So again the logical function
of attribute-to-claims transformation disappears as a separate component and is
subsumed inside of IdAS. So thus your “claims-provider” is just a
kind of IdAS context provider.
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.
Don't
think so. See my points above. I don't see this as slippery slope at all.
IMHO, I
am ok with an implementation to take a particular approach, but the framework
must not. Fundamentally if we do not address this semantic difference and
capture it in our model and framework ... then by equating claims to
attributes, we are equating DigitalIdentity to DigitalSubject - which is not
what we would want to do.
My take is this:
·
We understand that there are times when attribute-to-claim
transformation is necessary and a no-op just won’t do.
·
In a “native” Higgins deployment (i.e. not what Novell is doing for the demo) it
is ultimately the I-Card Provider’s responsibility that this
transformation get done. How it does this, is up to it.
·
The I-Card Provider implementer may choose to leverage an
IdAS Context Provider that either (a) natively serves up attributes in the
claim namespace and with the needed claim types, etc. or (b) uses a Context
Provider that performs attribute-to-claim transformation on attribute data
provided by yet anther Context Provider.
·
Perhaps in the future there really will be attribute-to-claim
transforming code with “input” and “output” interfaces
that are different from IdAS’s interfaces and thus we can’t think
of this code as just a special kind of IdAS context provider implementation.
Thanks
Raj
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
"Paul
Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
11/08/2006 01:57 AM
Please respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|

To
|

"'Higgins
(Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
|

cc
|

<higgins-dev-bounces@xxxxxxxxxxx>
|

Subject
|

RE: [higgins-dev]
Claims vs. Attributes and Mapping
|
|
Raj, see inline below…
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_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev