From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Tuesday, May 08, 2007 9:26
AM
To: Higgins
(Trust Framework) Project developer discussions
Cc: higgins-dev-bounces@xxxxxxxxxxx;
'Higgins (Trust Framework) Project
developer discussions'
Subject: RE: [higgins-dev]
Proposed updates toHiggins
ArchitecturediagramperAustin F2F discussions
Digital Subject contains list of attributes not claims
! Like we discussed many times in the past and also in the recent F2F, claims
could be based on attributes of DigitalSubject,
From IdAS
they could be derived from attributes (but not
necessarily the attributes themselves),
Using IdAS
transformation CP
or could be derived from some other claim assertions
from other IPs/RPs
This might be
the part that I don’t understand. From where (what interface) would these
“claim assertions” be retrieved? Are you envisioning another
IdAS-like data abstraction layer with a pluggable interface? If so it sounds
like we’re reinventing IdAS.
I would like us to discuss this ... as we continue to treat attributes and
claims to be synonymous and IdAS to be 'THE' source of claims as well. I am not
sure that is always true.
You may be
right. I’m trying to understand the use case and/or data flow.
Raj
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
05/08/2007 08:48 AM
|
Please respond to
"Higgins \(Trust
Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Sergey
Lyakhov'" <slyakhov@xxxxxxxxxxxxxx>
|
|
cc
|
"'Higgins \(Trust Framework\) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Subject
|
RE: [higgins-dev]
Proposed updates to Higgins
ArchitecturediagramperAustin F2F discussions
|
|
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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
