Anders,
my point here is that the need for a "security discovery" service
has nothing to do with browsers. It should be kept distinct from
the web browser use-case. Providing this type of service
is a reasonable requirement that the use-case group can discuss
should it choose to do so.
I do not follow your statements:
> where the latter is effectively involving the RP performing a
> challenge-response authentication on the AP,
> after first giving AP its identity and cred-requirements.
I do not see what this has to do with providing a "security discovery"
security service.
- prateek
> -----Original Message-----
> From: Anders Rundgren [mailto:]
> Sent: Thursday, February 08, 2001 4:22 AM
> To: Mishra, Prateek; 'OASIS Security-Use List '
> Subject: Re: Use Case & Requirements Doc Strawman 1 Issues List
>
>
> Prateek,
>
> > >ISSUE[UC-1-04:ARundgrenPush] Anders Rundgren has proposed on
> > >security-use an alternative to use case scenario 2 (single sign-on,
> > >push model). The particular variation is that the source Web site
> > >requests an authorization profile for a resource (e.g., the
> > >credentials necessary to access the resource) before requesting
> > >access. Should this scenario replace the existing use case
> scenario 2?
> > >Should it be made an additional scenario?
> >
> > I would argue that what Anders is referring to is a security
> > service called "security discovery": given a resource protected
> > by a security engine we wish to query the security engine
> > about the security properties of the resource.
> > This is an important topic but completely distinct from the
> > [Web Browser Use-Case]. I would strongly recommend that we
> > keep the two topics separated.
>
> It is possibly a part of a more advanced Web Browser Use-Case like
> in Shibboleth as this "security discovery" gives a new set of
> possibilties (and problems).
>
> So then I propose: "Basic Web Browser Use-Case" and "Advanced
> Web Browser Use-Case",
> where the latter is effectively involving the RP performing a
> challenge-response authentication on the AP,
> after first giving AP its identity and cred-requirements.
> This is BTW the use case that I'm interested in as
> the advanced use case is a true super-set of the basic use
> case, which IMO makes the basic use case
> a dead end.
>
> Anders
>
>
