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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] SAML2 metadata for a SAML1 IdP

> So what I hear you saying is that a deployment's implementation of
> Step 1 of the SAML1 browser profile determines the binding.  Okay,
> that makes sense.

Formally, it's still unspecified, but that's what the MAY is referring to.

> Let me ask a different question.  Does the use of
> IDPSSODescriptor/SingleSignOnService imply adherence to the four steps
> of the SAML1 browser profile?  In other words, is it wrong to use that
> descriptor for some other profile?

Well, I think it implies that you're doing stuff that an IdP would do, but
it's really just the SSO service element that implies what would follow.
SOAP-based IdPs can certainly use the descriptor, for example. It's the
combination of the element and a Binding that implies a particular profile.

The definition of an IdP in core (ignoring the glossary) is anything that
supports a SAML AuthnRequest. If something supports the moral equivalent,
then I would say it's an IdP for the purposes of metadata usage.

Nothing breaks based on whether something chooses to reuse an existing
descriptor, as long as the rest of the rules are followed. Either the
protocol or Binding strings should prevent anything from breaking existing
software. Or you can take the conservative approach and just define a new
role. The differences are just cosmetic.

-- Scott

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