Shibboleth Developers

[Tom Scavo <>]

On Wed, 5 Jan 2005 11:46:00 -0500, Scott Cantor 
<>
 wrote:
> > 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.
> 
> Yes, AssertionConsumerServiceIndex stands alone (with the associated
> metadata). Nothing else is needed or likely to be used in most cases. It is
> (as the spec says) mutually exclusive with the two attributes you included.

The spec says that AssertionConsumerServiceIndex and
AssertionConsumerServiceURL are mutually exclusive, yes, but it says
no such thing about ProtocolBinding AFAIK.  This may be the intent (it
makes sense actually) but the spec does say this.

In any event, what I hear you saying is that
AssertionConsumerServiceIndex is more likely to be used than
AssertionConsumerServiceURL, correct?

> > Since the spec does not mention "persistent" with respect to
> > AllowCreate, this appears to be irrelevant.
> 
> AllowCreate applies to all formats, but its origin is the Liberty "federate"
> flag. That's what it's for. The fact that it can be used with the others is
> mostly irrelevant.

If there's something in the Liberty spec that makes the intent of
AllowCreate more clear, then a reference would help.  Otherwise it
will remain a mystery to most.

> > The use of AllowCreate is not spelled out in the spec.  (See
> 
> It is spelled out fine. It's in core, where it belongs. I disagreed with
> saying anything in profiles then, and I still do. It's not a profile issue.

Actually, there's more in the profile doc than anywhere else.  It's
where I obtained my (naive) understanding of the attribute.

> > for instance.)  I included AllowCreate in the example since the
> > semantics are not clear.
> 
> They are to me. It means the IdP can create an identifier if one doesn't
> already exist. It just doesn't seem very likely to be used except as a
> federate switch with "persistent".

The spec does not mention the word "persistent" with respect to
AllowCreate.  I think you're reading more into it than is actually
there (not surprising since you wrote it :).

> All of OSU's users would already have an email address, and generally a
> Kerberos name. What does AllowCreate add? Nothing.

What about transient identifiers?  Will a transient identifier be
created if AllowCreate is omitted?

Tom