Skip to Content.
Sympa Menu

shibboleth-dev - RE: comments: draft-mace-shibboleth-arch-conformance-05

Subject: Shibboleth Developers

List archive

RE: comments: draft-mace-shibboleth-arch-conformance-05


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>, "'Shibboleth Development'" <>
  • Subject: RE: comments: draft-mace-shibboleth-arch-conformance-05
  • Date: Sat, 10 Sep 2005 00:40:08 -0400
  • Organization: The Ohio State University

> - In section 2.2.1, why invent a new term "operational mode"? Isn't
> "role" good enough? In fact, the term "operational mode" is not used
> anywhere, so why not simply delete it?

The term came from the SAML 2 conformance spec which I copied to create this
document initially. I can remove it at this point.

> - Why MUST an IdP or SP support the Metadata Profile?

Because it really, really helps deployers. The interop was hell because half
the products didn't support metadata, and the SAML 1.x stuff was so newly
defined anyway. It was a mistake for SAML 2.0 not to require it.

I also cleaned up the language in the metadata profile requirements section
to make it mandatory to both produce metadata in that format and consume it.
How it gets put together and consumed is up to the implementations but the
interchange format has to be there. This arguably makes Shib 1.3
non-conformant because we don't have any way to automatically produce a
metadata file by reading a configuration yet. Something to work on.

> - MUST attribute push be supported?

I guess I would say that it's MTI for an SP and SHOULD for an IdP. I will
add a note about it to section 2.2.3. I'm open if people have other
opinions.

> - [line 85] What "profile" are you referring to?

That line is referring to the references to resolving entity IDs into
metadata instances in ShibProt (which I will explicitly say). That part is
optional.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page