RE: [higgins-dev] Proposed updates toHiggins ArchitecturediagramperAusti

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Mike wrote:
> 
> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> wrote on 05/08/2007 10:13:39
> AM:
> 
> > Mike wrote:
> > <snip>
> > >
> > > 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.
> > >
> > <snip>
> >
> > Why is this needed? What use case have you in mind?
> 
> There exists an i-Card provider which stores A/C (Attribute/Claim (or
> whatever Raj wants to call them)) values for "personal cards" with the
> cards (not in IdAS). These values are accessible only thru the i-Card
> interface, not thru any context. In addition to values to put into Calims
> in the token, the STS needs access to the "master key" associated with the
> i-Card.

Got it. So here are the alternatives:

1. rewrite the i-card provider to just use IdAS 
2. have it "push" the attribute/claim values and master key to the TS
3. [What you're proposing] "pull" attribute/claim values and master key from
the i-card. 

If we implement #3 as you propose, then the implication is that the TS is in
the same process space as the both the i-card registry and the i-card
provider. Is that your assumption? If not, how would you propose to make #3
work across the process boundary?

<snip>