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

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

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