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

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

Based on this note and Mike's note ...

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

<sergey>
If we need similar CPIP we shouldn't oblige ICard provider to use IdAS to
store claim values of ICard.
</sergey>


I believe if we start to treat claims to be orthogonal to attributes in some sense, then STS could interact w DigitalIdentity (consisting of Claims).

One approach could be that we introduce a ClaimsProvider ... where one implementation of ClaimsProvider could tie it to IdAS directly (where claims are direct mapping of attributes to some extent, and); importantly, this approach to use a DI in STS and allowing for a ClaimsProvider to be plugged in would allow for other ClaimsProvider that could allow for obtaining claims from other places - be it from a set of cards, dynamically from a received token, from some other service issuing other claims like authorization assertions, etc. I believe this will help address various use cases that do not naturally fit into a IdAS like approach - dealing w attributes.

-Raj

"Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>

"Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

05/08/2007 09:35 AM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
cc	"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
Subject	Re: [higgins-dev] Proposed updates to Higgins ArchitecturediagramperAustin F2F discussions

> Why do we need to develop a non-IdAS-based CPIP?

It was only my supposition. We already have XML-based CMIP (perhaps for 
testing purposes only), which stores cards within encrypted xml data file. 
If we need similar CPIP we shouldn't oblige ICard provider to use IdAS to 
store claim values of ICard.

Thanks,
Sergey  Lyakhov
----- Original Message ----- 
From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
To: "'Sergey Lyakhov'" <slyakhov@xxxxxxxxxxxxxx>
Cc: "'Higgins (Trust Framework) Project developer discussions'" 
<higgins-dev@xxxxxxxxxxx>
Sent: Tuesday, May 08, 2007 3:48 PM
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