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: metadata 1x question

> I'm looking at what should do in the binding attribute in an 
> artifact resolution service (IDPSSODescriptor).  Since mine 
> is a soap endpoint I assume that I put in the urn from saml 1 
> binding: urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding.   

That was the intent.

> But then I noticed in the SPSSODescriptor that the 
> assertionConsumerService uses the profile names in the 
> binding attribute.  Is that because the profile also 
> specifies the binding?  Should I instead be putting in 
> urn:oasis:names:tc:SAML:1.0:profiles:artifact-01? 

It's because SAML 1 profiles and bindings were a stew. The artifact profile
URI is what you use on the SP side to indicate how to do SSO, but the
callback is just the SOAP binding using the proper messaging, so we left it
that way.

It's not possible in 1.x to really isolate everything between profiles and
bindings, so the use of the Binding attribute is mix and match.

In 2.0, I think the Binding always means "binding", and the profile is
generally implied by the metadata element + Binding.

Of course, we could have had just generic Endpoint elements with profile and
binding, at which point we'd be modeling things more like WSDL or whatever,
abstractly. But that ends up being so generic that I figured something like
that will emerge outside of SAML and can be tackled later.

The first iteration in this TC I believed should do what's needed plus
explicit extensions, and something else can come along and justify how it
will do "everything that's ever going to be needed". Good luck to them.

-- Scott

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