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

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

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.
> 
> 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