[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Proposed updates toHiggins ArchitecturediagramperAustin F2F discussions
|
>
> 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?
I wasn't trying to propose anything - just dealing with the realities of
what is there (for Personal i-Cards) now.
The issues are only for Personal i-Cards (managed Card values are ?always?
in a Context), so in that case I suspect a requirement of co-location with
STS isn't unexpected.
Though, I do not think there is anything preventing us from
defining/implementing service interfaces for the i-Card Registry and
i-Card Providers.
