Shibboleth Developers

["Scott Cantor" <>]

> [line 77] The phrase "destination-site" uses legacy terminology.

I know, but I think "service-provider-first" sounds dorky. YMMV.

> [lines 88--89] Is the different font used on these lines intentional? 
> If so, why?

It's an example of use of the keywords. I stole all that stuff from a myriad
of specs that use the same boilerplate.

> [line 104] Is this URI still appropriate (assuming the emerging SAML
> 1.1 Metadata spec)?

There is no 1.1 metadata schema, only a profile of the 2.0 schema for SAML
1.1. It's the same thing I was doing, I just submitted it with Greg
Whitehead.

> [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.

> [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.

> [line 151, 185, 211] The use of the word "or" is troublesome.  The
> SAML spec seems to require SSL/TLS in this case yet makes no mention
> of digital signatures wrt SAML over SOAP over HTTP.

SAML never meant to force people to use SSL, it was a screwed up case of
putting conformance language into the binding. Nobody interpreted it as
requiring only use of SSL to do authentication.

> [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.
 
> [lines 250--254] Elevate this subsection one level so that it applies
> to all of section 3.1.  (See comment below.)

Disagree. It applies only to our new profile, not the SAML profiles (see
below).

> [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.

> [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.

> [line 435] The SAML artifact is not URL-encoded and therefore bugged. 
> The fact that the artifact should be URL-encoded should be mentioned
> in the text.  In fact, the SAMLart parameter should be mentioned in
> the text.

Oops, I meant to fix the plus sign, guess I forgot. I'd rather not go on at
length about the profile itself, since SAML already defines it. I try and
only say what we add.

> [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...

> - Major omission: Attribute Release Policies, especially content and
> XML representation thereof.  See Walter Hoehn's ARP spec
> https://umdrive.memphis.edu/wassa/public/ARPs/arp.spec.html
> for an introduction.

This is not part of our spec. It's an implementation of something the spec
requires that an implementation do. We do not force Shibboleth
implementations to use the same approach.

We need to document and publish it, but not here. Same goes for my trust
handling work.
 
> - 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.

> - 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? Maybe not, I'll check. I'm not
trying to create a stand-alone document by any means.

> - 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.

> - Combine sections 3.2 and 3.4.  For example:

That seems like a good idea.

> - What happened to <md:AttributeConsumerDescriptor> in section 3.6?

It was merged into the SPSSODescriptor to eliminate some ambiguities.
Uploaded spec forthcoming probably later today. Was discussed at length on
the last SSTC call.

> - 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.

> - Possible Shib-specific additions to the metadata specification:
> WAYF, Common Domain, and ARP.

See my other note on the WAYF issue, there doesn't appear to be anything of
value to add here. You'd have to propose something, I think.

ARPs seem entirely out of scope of metadata, I don't know what that would be
for.

> - Include a reference to [ShibConf] in section 5.

Should be the other way around, I don't think a circular reference is
needed.

Thanks,
-- Scott