Shibboleth Developers

[Tom Scavo <>]

On Thu, 11 Nov 2004 13:58:46 -0500, Scott Cantor 
<>
 wrote:
> > [line 125] The dashed line from User Agent to Identity
> > Provider is not optional.
> 
> Which one? Far as I can see, it's correct. Only steps 4, 5, and 8 are
> actually required.

There is only one dashed line from User Agent to Identity
Provider---it's the bottom half of step 3.  This request is required,
I think.

> > [line 125] The diagram assumes the browser/POST profile and therefore
> > does not illustrate a possible back-channel exchange for artifact
> > resolution.
> 
> This is already noted in the text.

Yes, but a picture would be best IMHO.  There are as many different
pictures as there are documents.  I prefer the Liberty 1.2 diagram
best.  YMMV, of course. :-)

> > [line 182] Replace "SAML protocol" with "SAML SOAP protocol".
> 
> SOAP 1.1 is just one binding. If somebody invents a new SAML 1.1 binding,
> Shibboleth should permit its use. SOAP 1.2, for example. I'm always careful
> with my language around SAML protocol usage.

I didn't say "SOAP 1.1", just "SOAP".  That covers both cases, right?

> > [line 278] Delete the phrase "in accordance with the
> > Browser/POST profile".
> 
> Disagree. SAML does not describe how to return errors like this. And there
> is no way to do so with the artifact profile (yet another reason I dislike
> it). So it has to be done with POST.

I was thinking that the same statement could be made about the
assertion returned via artifact resolution, no?

> > [lines 422--426] The SAML spec requires that the IdP (not the SP)
> > enforce the artifact single-use rule.  (I suspect this is easier to
> > implement anyway.)
> 
> There is a security flaw in the profile if the SP doesn't also do this. We
> know it's harder, but it's necessary. The IdP already has to, by virtue of
> the profile itself. This is an added recommendation that matches the one
> added to SAML 2.0 because of the IBM paper.

Can you give a reference?  (Btw, the SAML2 security doc still mentions the 
IdP.)

> > [line 597] Delete the phrase "that supports an Attribute Authority
> > service as described in section 2.1.2" since a compliant IdP MUST
> > support attribute request/response.
> 
> Good point, but I wonder if it's a good thing to entangle that conformance
> rule into this section...

No different than requiring <md:IDPSSODescriptor>, right?

> > - What about persistent identifiers (referred to in GridShib)?
> 
> We haven't profiled anything in this space. The Grid use case would most
> likely use either DNs or transients, I imagine, or they'll need to define
> something. I haven't read the reference you're looking at, probably.

You probably should since they're making some implicit assumptions
about Shib 1.3.

> > - Give a specific example of a back-channel exchange for artifact
> > resolution in section 3.1.3 (referred to as section 3.1.4 below).
> 
> SAML already does, I think, doesn't it? 

Yes.

> > - Combine sections 3.1 and 3.3, and add a subsection entitled
> > "Artifact Resolution Profile".  For example:
> 
> Why? It's part of the artifact profile itself.

See specific comment submitted earlier.

> > - The URI urn:mace:shibboleth:1.0:profiles:SSO on line 594 seems
> > inadequate.  Like SAML 2.0, why not specify a group of URIs:
> >
> >  urn:mace:shibboleth:1.0:bindings:HTTP-Redirect
> >  urn:mace:shibboleth:1.0:bindings:HTTP-POST
> >  urn:mace:shibboleth:1.0:bindings:HTTP-Artifact
> >  urn:mace:shibboleth:1.0:bindings:SOAP
> 
> The SSO profile is strictly one thing...the request. I could add that to the
> URI, I guess. It doesn't have anything to do with POST/artifact or SOAP.
> 
> SAML 2.0 is different because I refactored the entire specification, but I'm
> not out to retroactively fix 1.1.
> 
> > This would allow multiple <md:AssertionConsumerService> elements to be
> > differentiated, for example.
> 
> We don't use a Shibboleth URI in those elements, we use the SAML-defined
> profile URIs. This aligns with the submission to the SSTC.
> 
> Note that while we could arguably use MACE URNs to identify our use of SAML
> profiles, this would wreck interop entirely without any great advantage.
> 

But there needs to be some way to distiniguish the two authn response
profiles in metadata.  Is that forthcoming?

Cheers,
Tom