| 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.
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. 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.
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.
Thanks
Raj
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 11/08/2006 01:57 AM
|
|
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>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 11/03/2006 07:26 PM
|
|
