[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Proposedupdates toHiggins ArchitecturediagramperAustin F2F discussions
|
Technically we could allow it (with changes to our architecture and its
layer, I just don't see why we need it.
The TS does need to generate i-card data files. But other than that, I don't
understand why a TS service needs to (i) refer to an i-card data instance
that is managed in the i-card registry and (ii) use its interface.
Tony wrote:
>
> So there should be no reason why an STS can't get or use an i-card
> interface for resolving identity attributes for a token
>
> -----------------
> Sent from my BlackBerry Handheld.
>
>
> ----- Original Message -----
> From: "Paul Trevithick" [paul@xxxxxxxxxxxxxxxxx]
> Sent: 05/08/2007 08:13 AM
> To: Michael McIntosh
> Cc: "'Higgins \(Trust Framework\) Project developer discussions'"
> <higgins-dev@xxxxxxxxxxx>
> Subject: RE: [higgins-dev] Proposed updates toHiggins
> ArchitecturediagramperAustin F2F discussions
>
>
>
> 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?
>
> My worldview: i-card providers are higher level objects that consume
> services from IdAS and the TS. Not the other way around. That's why the
> architecture diagram is layered vertically the way it is: i-card providers
> over TS and IdAS.
>
> http://wiki.eclipse.org/index.php/Architecture
>
>
>
> _______________________________________________
> 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
