RE: [higgins-dev] Proposed updates to Higgins Architecture diagramperAus

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Raj,

Raj, I really struggle with your question "Do cards contain claims or
attributes?", because of the problematic definition of the terms. 

Over the spectrum of use cases Higgins supports, the distinction between
claims and attributes goes from black/white to dark-grey/light-grey. 

Let me take a step back and try to motivate a definition of Claim by
following the data pathways.

I _think_ we agree on this generalized process (optional steps shown in [
]):

     Source-of-data-fields 
     -> [transformation] 
     -> [signing by issuer] 
     -> i-card (a user metaphor that is the reification of the concept of "a
source of data fields") 
     -> transport (to RP)
     -> data-fields-received-by-RP

- the transport might be implemented as "push with fields packaged in signed
tokens" (CardSpace Web Integration, etc.)
- the transport might be implemented as "pull with fields conveyed via a
source-to-RP feed" (RSS)
- the transport might involve "pull by browser redirect" from RP (OpenID)

- The data fields at the start are called "Identity Attributes"
- We could call the fields at the end of the process, "Claims" 
- We could decide that the "output" of an i-card was a set of "Claims"
- We could then call "transformation", "attribute-to-claim transformation"

If so then a Claim could be defined as:

   "An attribute made available by an i-card. The i-card may have
   transformed and/or derived the value of this attribute from one
   or more values of other attributes from one or more underlying 
   data sources prior to being made available, and it may have been
   packaged with other attributes and the resulting set signed by
   an issuer prior to being made available."

That's my best shot at defining Claims and their relationship to i-cards.

With that definition. The answer to your question is "Yes, an i-card is a
data channel that spits out Claims"

As you can see, it is a lot of work to try to define the term Claim and
reliably distinguish it from an Attribute. 

-Paul

________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Monday, May 07, 2007 11:58 PM
To: Higgins (Trust Framework) Project developer discussions
Cc: 'Higgins (Trust Framework) Project developer discussions';
higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Proposed updates to Higgins Architecture
diagramperAustin F2F discussions

Do cards contain claims or attributes? 

I believe card is a representation of DI, and thus contains claims
(metadata/references to claims). Thus, we need to have the DI representation
as a collection of claims (we have that in STS now) .. and allow for a layer
to deal w Claims and Attributes. That could be a direct mapping, some kind
of indirect mapping, or variety of others.

comments?

-Raj


"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>

"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 
Sent by: higgins-dev-bounces@xxxxxxxxxxx 
05/07/2007 07:45 PM 
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] Proposed updates to Higgins Architecture diagram perAustin
F2F discussions







Mike wrote
> 
> Paul,
> 
> We are trying to figure out a few things wrt attributes for "personal"
> i-Cards.
> In "managed" mode, the STS pulls attribute values for claims from a
> Context via Context Provider/IdAS.
> In "personal" mode, it is unclear where the attibute (and master key)
> values are - are they in the i-Card Store?

SergeyL has been designing and developing the CardSpace Personal i-card
provider (CPIP). So he should answer rather than I. The doc he wrote here
[1] is extremely vague (and should be fixed).

But thinking out loud here...if I were designing the CPIP I think I would
have stored within the CPIP object itself a URI field: "<ContextId> /
<SubjectId>", where ContextId points to, say, a Jena-backed Context. And
SubjectId to a DS within it (the SubjectId can be null if there is only one
DS in the Context, BTW). That way I could pass this ContextId/SubjectId
reference along in the RST to the TS and the TS could open this
ContextId/SubjectId. I would have separately developed a parser to import
the MSFT-defined personal i-card format. And I'd have separately developed a
generator to export to this same format.

> It seems as if there is a need for the iCard Store for personal i-Cards to
> be accessible via Context Provider/IdAS.
> If so the lines aren't drawn to reflect that.

As mentioned I'm assuming that the runtime storage of CPIP attributes is in
IdAS. So only the existing blue link from the CPIP i-card provider to the
IdAS Component is required.

[1] http://wiki.eclipse.org/index.php/CardSpace_Personal_I-Card_Provider

<snip>

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev