Evan,
> >> ISSUE[UC-1-02:ThirdParty] Use case scenario 3 (single sign-on,
> >> third party) describes a scenario in which a Web user logs in
> >> to a particular 3rd-party security provider which returns an
> >> authentication reference that can be used to access multiple
> >> destination Web sites.
>
> AR> This is clearly a case of redundancy. If it is a third-party
> AR> security provider or business party ought to be
> AR> technology-independent IMO.
>
> I would counter that even if it would probably have the same
> implementation, it's a separate scenario. Rather than being a peer
> relationship between 2 Web sites, it's a one-to-many relationship
> between a security service provider and multiple destination sites.
I would say that use case 2 may very well have one-to-many relationships (different links)
so the only difference is then if they are peers. If that still makes it a separate use case
is then down to the philosophical level. It could actually be a part of the text to describe
a number of scenarious where the scheme and drawing applies. Someone mentioned
a "heath care" use case. You could say that the AP and RP could be hospitals and the
user is a doctor looking for journal data in the RP's files. AP vouches for the user to be
a Doctor at AP with a certain AMA license code. So the only thing one can say,
this is the really "phat" use case!
> In the concall yesterday, you brought up the fact that there are
> technical difficulties with this scenario. We all know 10 ways for
> transferring a token between a source and destination site, but
> transferring one between a security provider and multiple destination
> sites is a little bit trickier.
This problem unfortunately applies to actual uses of peer.to-peer as well.
Only Shibboleth and Passport approaches have something to offer here.
I would characterize these as a new (sort of only) use case not covered by strawman 1
Anders
