Shibboleth Developers

["Scott Cantor" <>]

> (I apologize in advance for the lateness of these comments.)

I apologize in advance for rejecting some of them. ;-)

> - [line 123] s|step 5|steps 5 and 6|

Disagree. Keep in mind that Shibboleth composes two separate activities, SSO
and attribute queries. SSO is mandatory (without it, it's not formally a
Shibboleth 1.x use case), and queries are optional (in a deployment).
Whether a given implementation optimizes those activities in conjunction
with things like attribute push is not normative.

So strictly speaking, use of artifact is not a replacement for step 6,
whether or not it normally obviates it. And in my implementation, it
actually doesn't, at least in the case where you return no attributes in the
artifact response. Probably not common, but it illustrates why it's
separate.

> - [lines 352--353] This is only possible with Browser/POST, right?

If you mean the error message part, no, it's talking about returning an
error to the browser, not to the SP. (It is true that you can't signal an
error to the SP except with POST, but in practice, SAML's lack of end to
endness means we generally trapped errors at the IdP. Probably will
reconsider that in 2.0.)

> - [line 763] The label [Schema2] is the wrong font.
> - [line 769] The label [LibertyProt] is the wrong font.

Not in my source document, might be a PDF thing.

> - Move subsection 2.1 to the end of section 2.

A bit drastic, but I guess it's better that way.

> - If you're going to include the note in section 2.3, you should also
> include a note in section 2.2.3.

Meaning that it used to be "the Handle Service"? Good idea.

> - [lines 309--311] Replace these lines with "The URL of a resource
> accessed at the service provider (although an opaque reference MAY be
> used) returned by the identity provider as the TARGET parameter in the
> response".

I wouldn't want to emphasize that it could be a URL of a resource, as it's
just a horrible practice to do so. It's nothing but RelayState. I'll reword
a bit, and in fact I'll make its opacity a SHOULD.

> - [line 644] Append the sentence "The value of the Name attribute is a
> globally unique reference to the collection of entities enclosed by
> the element."

Slightly reworded, since the value has to be URI for it to be unique, and
SAML doesn't mandate this, I just made it a SHOULD here.

> Questions/Comments:
> 
> - [lines 119--120] This sentence may be true of IdP discovery in
> general, but is it true of Shib deployments in particular?

Real ones, yes. How many use a WAYF? Very few, I suspect. Many are based on
a more Liberty-like circle of trust (2-3 IdPs, or maybe just one). Of
course, the commercial providers are all doing it themselves because we told
them they should, so this is self-fulfilling.

> - Browser/Artifact is not referred to in the diagram on p.4, which is
> fine.  The remark in the opening paragraph of section 2.1 refers the
> reader to [SAMLBind] for more detail regarding Browser/Artifact, which
> is also fine.  Browser/Artifact is described in some detail in step 5
> on p.5, which unfortunately is confusing.  For clarity, I suggest the
> references to Browser/Artifact in step 5 be removed.

I really don't find it that confusing, but I broke up that text a little,
and cleaned up the language a bit.

May particular take is that the only thing Shibboleth adds here is the
request and the query steps. The profiles themselves are SAML, and I don't
think I can correct the deficiencies of that spec at this late stage. Your
tech overview does a pretty good job of covering this anyway.

> - [lines 206--207] Does Shib (the implementation) actually do this?  I
> thought the ITS was gone (or subsumed by the SSO service, however you
> want to look at it)?

Shibboleth never did it because we always had a request flow. I think the
reason the ITS was conceived was to deal with the awkwardness of starting
the profiles from the source side. Once you have the request side in place,
it's awkward to have a separate ITS. In retro, I could have just stripped
it, but I didn't want to create confusion by not aligning things.

> - [line 624] So NameQualifier is optional?  If it is omitted, it
> obviously can't be equal to the Issuer attribute.  Moreover, shouldn't
> this requirement be true of ALL NameIdentifier formats?

I can't make it true of all Formats because I don't control all Formats,
only this one. It is essentially unspecified in those cases, but I can't fix
that. I managed to get it semi-deprecated in 2.0 when those formats are
used.

But I'm just going to strip that second sentence, it doesn't read well.

> - [line 659] Why MUST a Shibboleth IdP "include the
> <md:IDPSSODescriptor> element in its metadata?  A GridShib IdP, for
> example, formulates metadata that does not contain this element.

A Shibboleth IdP is a SSO-enabling entity. That's it's purpose. In fact, if
you read SAML 2 core, an identity provider is quite tactically
defined...it's an entity that supports the AuthnRequest protocol. Reading
the glossary, it's much more vague, but core isn't. This was intentional on
my part to sidestep endless arguing about what an IdP was. I wanted the
role, in fact, to be IDPDescriptor, as it was in Liberty, but I lost that
argument.

A GridShib "IdP" is not technically an IdP in my parlance, if it only
supports attribute queries. That's just a SAML Attribute Authority.

I can't correct the glossary, so I guess the official TC position is not
mine, but having designed the AuthnRequest protocol, my position is quite
firm. You support AuthnRequests or you're not an IdP.

> - [lines 675--676] Although I don't have a use case, the keyword
> "MUST" in the opening sentence of section 3.4.5 may be overspecified.

I don't follow. I'm not saying you should document everything you'd ever
know about the service, but if I don't at least document the endpoint, I'm
really not using metadata.

Note that if I only push attributes, and don't support queries, I'm not an
Attribute Authority. The MUST only applies to deployments that do.

> - [line 682] Why MUST a Shibboleth SP "include the
> <md:SPSSODescriptor> element in its metadata?  An SP (such as a grid
> SP) that wishes to advertise only its attribute requesting ability
> does not need to specify this element.

This isn't quite as well-supported by the spec, it's perhaps not all that
clear what an SP is. But for consistency, I feel a Shibboleth SP is a
consumer of SAML authn assertions issued by an IdP using the web profiles.
Attributes are secondary in a technical sense, even if they did motivate
much of Shibboleth.

Once we get to 2.0 and this document goes away, everybody can get the mix
and match they want and just ignore me.

> - [lines 724--725] Should the WAYF be included in this sentence?

Sort of, but it's not really a security consideration as such, and doesn't
really add to the discussion here, I don't think.

> - In section 5.1, the labels [SAMLMeta-xsd] and [SAML1Meta] do not
> agree.  Should the latter be called [SAMLMeta]?

I cleaned that up.

Thanks,
-- Scott