Hi Raj and
Dale,
Here’s
where I currently am on claims, and attributes, etc. (though the current code
doesn’t reflect this position).
I like the
conceptual simplicity that a DI is nothing more or less than a set of claims as
per http://spwiki.editme.com/DigitalIdentity.
So I’m proposing that a DI data structure consists literally (both persistently
and at run-time) of a set of claim data structures.
Each claim is
comprised of two properties (in the RDF sense of the word “property”
where a property has an explicit name expressed as a URI, and a value that may either
be a literal (e.g. a string) or another property, (or set of properties, etc.)).
The first property is a claimant property (more about its value in a moment). The second property would be a
property that corresponds to one of the DI’s Digital Subject’s
Identity Attributes.
An example:
If a Digital Subject “Paul Trevithick” had an Identity Attribute “eye-color”
of value “green”, and in a Context that was, say, one of the RMV’s
directories. Then Paul would be represented in the RMV Context as a DI containing
among others the following claim:
Claim:
{property,
value} : Claimant, RMV
{property,
value} : EyeColor, “green”
Where:
RMV is the name of the juridical entity that is the authority making
the claim
Claimant is a URI (e.g. http://socialphysics.org/PropertyNS/Claimant)
EyeColor is a URI (e.g. http://biometrics.fabrikam.org/RDFNS/EyeColor)
I’ve glossed
over the type of the value of the Claimant property
(e.g. RMV) while I await reactions to what I’ve already written here.
Raj wrote:
<stuff deleted>
Dale wrote:
At this
point I see no difference between the terms attributes, attribute value
assertions, and claims when applied to that structured data
I
agree there has been different usage of the terms leading to confusion. But on
way I tend to differentiate and helpful in some conversations/use cases is ...
attributes are stored information about identities (that are used in
'management' use case. e.g, attributes are stored in a directory); claims are
asserted information about identities (that are used during 'runtime'). I think
this is along the lines of what you said about being 'persistent'. I treat
that the information that are part of the claims are compared to the
attributes.. to evaluate if the claims are trusted. (claims need not be facts..
neither what is stored. but claims get compared to attributes that are in
trusted store leading to claim evaluation).
Raj
|
Dale Olds
<dolds@xxxxxxxxxx>
Sent
by: higgins-dev-bounces@xxxxxxxxxxx
03/09/2006 04:37 PM
|
Please
respond to
"Higgins (The Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
higgins-dev <higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[higgins-dev] entities, and digital
identities
|
|
I would like to discuss some terms in the context of Higgins interfaces and
classes. At this point I would rather not revisit any of these terms in the
sense of the identitygang lexicon, but see if we can reach a common
understanding in a more narrow scope of Higgins interfaces and code.
Entity
====
I know that "entity" is not in the interfaces or classes and is not
modeled directly, but I find it useful (and even necessary) to describe things
in the real world and we should be clear about what we consider to be
"real" and "things". I think "entity" is the most
likely term. Claims, attributes, digital identities, digital subject, and principals
all purport to be data about something -- some entity. I think of an
"entity" as anything that can be identified in human conversation.
This is very close to the identity gang lexicon, except that it would include
"concept" in the list with person, physical object, animal, and
juridical entity. In fact, I think of a juridical entity as a conceptual entity
that incurs legal policy. Also, note that a false assertion is still a concept
-- we can identify it and talk about it.
So it is useful to think of an entity as anything that can be identified in
human conversation. There is much discussion on the identitygang list that two
identities can be identical -- but I think that's because the discussion strays
between entities (anything that can be identified) and digital identities (a
chunk of data). Of course a particular chunk of data (e.g. a set of attributes)
can be insufficient to distinguish between two entities, but humans CAN
distinguish between the entities or we could not talk about them. The distinction
between entities may be as simple as sequence or physical position, be we can
identify them or we could not discuss them.
Digital Identity
===========
In networked systems we commonly store data about an entity. I think this
corresponds most closely with Digital Identity. It consists of a chunk of
structured data. At this point I see no difference between the terms
attributes, attribute value assertions, and claims when applied to that
structured data. Sometimes sets of attributes are stored as an entity within a
larger entity (e.g a user account within a directory service). Sometimes a set
of attributes are presented as part of some interaction with another entity
(e.g. name.password authentication, update address book, present credit card info,
etc.). Is this the difference between "digital subject",
"digital identity", and "claims" -- merely notions of
persistence and larger or smaller subset of attributes? If so, it seems like
the higgins interface can have class definitions for digital identity, and
attribute, and not (yet) need classes for digital subject, claims, persona,
party, etc.
>From what I have seen of the demo code, it seems like a Facet corresponds
to a digital identity. Is this where you see it going?
--Dale
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
