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: OSSML web-user interactions

I believe that the Shibboleth use case is only different in the initial part (user interaction)
and identical to first scenario when it comes to the rest of the protocol steps.  Provided that
my suggested SSO Push Model #2 is used.  That is why I push this so hard :-) as both uses
seem very legitimate.  Regarding the go-to-RP first, there are a lot of variations on how
you find your back to the AP.  Shibboleth has a DNS-based variant.  Passport depends
on list of URLs to known providers.  Another is to explicitly specify an AP security service URL.
VISA's 3D-SSL uses the financial institution part of a credit card number to search in
a directory after the "bank-AP-URL".  Yes, VISA does some kind of Shibboleth, Purple and A2ML
already!  An observation regarding 3D-SSL: As far as I understand they use POSTed
forms for credentials (payment authorizations, payment requests).  This is an option
that is worth considering as an option.   Sorry for going slightly outside the use-case territory...


----- Original Message ----- 
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: "OASIS Security-Use List" <security-use@lists.oasis-open.org>
Sent: Monday, February 05, 2001 20:00
Subject: OSSML web-user interactions

> Considering just the vanilla end-user-with-web-browser case, I think there
> may be a little debate to be had about what interaction scenarios
> must/should/may be supported.
> I think we agree that in the common/minimal case there are three players:
> the user (with browser), the target resource site (relying party RP), and
> the "login" site (asserting party, AP).  The question is, what sorts of
> interactions are to be supported between the user and the RP and AP.
> One approach I might call go-to-AP-first.  The user, at first interaction
> with the "ecosystem" in Jamcracker terms, interacts with the AP to provide
> it with assurance of the user's identity (ie, "authenticates").  The user
> then indicates to the AP which target site (RP) the user wants to access.
> The AP constructs the right security stuff to be supplied to the RP, sends
> it to user along with redirection to RP site.  RP consumes security stuff
> and makes access decision (possibly with additional interaction with AP).
> Another is go-to-RP-first.  The user directs the browser to the RP, which
> notes lack of needed security stuff and provides the user the ability to
> navigate to the user's AP, while supplying info about the RP.  The user
> authenticates to AP, the AP uses RP info to construct right security stuff
> for that RP, gives it to user and redirects the user to RP as above.
> The scenarios we developed for the Shibboleth project were based on the
> go-to-RP-first approach.  There are several reasons for this, most of them
> design-related as I mentioned in a previous note.  But I suggest, just
> considering user experience, that go-to-RP-first is at least *desirable*
> to support since it's a natural way for people to use their browsers.  If
> go-to-RP-first isn't supported, and the user experience is, when they do
> go to the RP first anyway, that the system tells them they can't do what
> they want and can't help them get to the right place, I think this is
> clearly an inferior user experience.  Similarly, if the only way to get to
> a RP is to provide its URL to the AP, this strikes me as unnatural.
> It may be that go-to-RP-first is too hard to do in the general case so we
> have to live without it, but we should be aware of the tradeoffs.
>  - RL "Bob"

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

Powered by eList eXpress LLC