Skip to Content.
Sympa Menu

shibboleth-dev - RE: comments: draft-mace-shibboleth-arch-protocols-02

Subject: Shibboleth Developers

List archive

RE: comments: draft-mace-shibboleth-arch-protocols-02


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>, <>
  • Subject: RE: comments: draft-mace-shibboleth-arch-protocols-02
  • Date: Sat, 30 Oct 2004 15:24:31 -0400
  • Organization: The Ohio State University

Thanks for reviewing...my comments below.

> - Applicable Shibboleth version is not mentioned anywhere in this
> document (intentionally, I presume, but it's still a significant
> omission)

Intentional. There's an unpublished conformance doc, and there are no
implementations of Shibboleth that are conformant. This is not about
implementation, so why should we mention one?

> - In Example 3.1.1.3, remove the URL encoding for clarity

Why? Then the example would be wrong...

> - In Examples 3.1.2.1, 3.2.1.1, and 3.2.2.1, insert indentation for
> clarity. Also, refrain from using default and/or redundant
> namespaces.

Will indent. I disagree about the namespaces, and I don't think any of them
are redundant, but I'll check. I use default namespaces all the time. They
save space.

> - Not sure sections 3.3 through 3.7 should be called "profiles"
> - Combine sections 3.3 through 3.5

I'm reworking 3.3-3.5 back into the earlier sections (I agree), but they are
all SAML profiles, IMHO. Except maybe 3.6, which just points at one. 3.7 is
probably going to be the basis of an actual submitted SAML profile.

> - IMHO, section 3.6 should be omitted. As written, it adds nothing to
> the existing SAML2 "profile", which itself is vague at best.

I think we, umm, disagree about the vagueness, or at least the necessity for
it to be any less vague. "Doesn't solve an unsolvable problem" I would agree
with.

We have to reference it because this is a SAML 1.1 based set of profiles,
and that's a SAML 2.0 profile that wouldn't otherwise apply.

> Moreover, there seems to be a lot of overlap between the IdP Discovery
> Profile and the WAYF. Perhaps the two should be combined?

I do, section 2.3 already allows for the use of that profile. The WAYF is a
non-normative component, it wouldn't be appropriate to require one to
utilize the SAML profile. It dovetails with it fine, since it's essentially
usable as a shared domain. It effectively just offloads the SP's role of
participating in the profile to it.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page