OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Use Case & Requirements Doc Strawman 1 Issues List


>     >> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC