| RE: [higgins-dev] Claims vs. Attributes and Mapping |
|
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam 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
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nataraj Nagaratnam The distinction between a claim and an
attribute is more a matter of usage 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.
|
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
