Shibboleth Developers

[Tom Scavo <>]

On Wed, 5 Jan 2005 10:32:28 -0500, Scott Cantor 
<>
 wrote:
> > Thanks.  I can understand ProviderName, but as you mentioned earlier,
> > ProtocolBinding and AssertionConsumerServiceURL replace the shire
> > parameter, so I'm not sure why you would want to omit them.  Are you
> > making some assumptions about metadata?
> 
> Those attributes still assume metadata in most cases, so using the Index is
> shorter and simply going to be much more common.

I'm not sure what "Index" you're referring to? 
AssertionConsumerServiceIndex?  If so, then the original question
still stands: don't we need ProtocolBinding and
AssertionConsumerServiceURL/AssertionConsumerServiceIndex to replace
the shire parameter?  Seems these attributes are useful, if not
necessary.

> > I assume you're referring to a persistent identifier such as
> > eduPersonTargetedID.
> 
> No, I'm referring to the SAML 2.0 "persistent" format (at which point,
> hopefully our attribute name is subsumed).

Since the spec does not mention "persistent" with respect to
AllowCreate, this appears to be irrelevant.

> > As I read the SAML 2.0 spec, AllowCreate is
> > required for ANY identifier, not just persistent identifiers.  If
> > that's true (there is nothing in the spec to suggest otherwise), then
> > a value of true is required here (since the default value is false).
> 
> Yes, but:
> 
> a) nobody seems to even use most of the old SAML formats
> b) creation control pretty much assumes the Liberty use case
> c) people using emails or other long term IDs are probably not ceding
> control over ID creation to the SP

The use of AllowCreate is not spelled out in the spec.  (See

http://lists.oasis-open.org/archives/security-services/200410/msg00085.html

for instance.)  I included AllowCreate in the example since the
semantics are not clear.

Thanks,
Tom