RE: [higgins-dev] Proposed updates to Higgins ArchitecturediagramperAust

[Michael McIntosh <mikemci@xxxxxxxxxx>]

higgins-dev-bounces@xxxxxxxxxxx wrote on 05/08/2007 08:48:34 AM:

> 
> SergeyL wrote:
> > 
> > > 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).
> > 
> > Yes, IdAS-based CPIP is implemented in this way. Personal I-Card 
contains
> > a
> > reference (ContextId + SubjectId) to a Digital Subject which contains 
a
> > list
> > of claims (). 
> 
> Good.
> 
> > On the other hand, STS shouldn't use this reference, if we
> > will need to develop some non-IdAS based CPIP. 
> 
> Why do we need to develop a non-IdAS-based CPIP? 
> 
> > There is a method
> > ICard.getClaims(), and it could be used by STS in case of Personal 
ICard.

It seems we are back to my initial issue - there is no current interface 
thru which an STS can acquire an i-Card instance and invoke methods on it.

> > 
> > Thanks,
> > Sergey Lyakhov
> > ----- Original Message -----
> > From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> > To: "'Higgins (Trust Framework) Project developer discussions'"
> > <higgins-dev@xxxxxxxxxxx>
> > Cc: <higgins-dev-bounces@xxxxxxxxxxx>
> > Sent: Tuesday, May 08, 2007 2:45 AM
> > Subject: RE: [higgins-dev] Proposed updates to Higgins Architecture
> > diagramperAustin 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
> > 
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev