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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: RE: [security-services] Untrusted Service Provider Profile

> I'd love to see a SAML model where an SP can trust an IDP, but an IDP
> doesn't necessarily trust an SP.  This is much more like the OpenID model.
> But there is no reason SAML cannot do this.

It more or less does now, unless you implement some things in extremely
strict ways. But in doing so, it creates some risks. Shibboleth has always
supported issuing assertions to "unknown" SPs, but it does this mainly
because the default settings only produced a one-time handle and no
attributes, and then the query coming back can be authenticated or
restricted to minimal sets of attributes.

> Here is how I'd see it:
> 1. An unknown/untrusted SP sends a signed authentication request to a
> trusted IDP.
> 2. The IDP looks up the metadata of the SP (it must be available online
> and on a secure endpoint such as https).
> 3. The IDP verifies that the metadata and the request come from the same
> provider.
> 4. The IDP sends the assertion.
> This certainly can be done within existing spec, but it mandates several
> things that are optional in the spec.  Should this be formalized as a
> profile?  Are people interested in such a profile?

I've suggested something along those lines a few times to people, in both
directions, with the metadata pull substituting for any meaningful notion of
peer authentication, but it being pretty close to what you get out of

I'm not really sure what https buys you though. You can't know who you're
talking to, or we wouldn't be having this conversation. The only security
you have is DNS, and you can get that without SSL.
-- Scott

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