Shibboleth Developers

["Scott Cantor" <>]

> 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.

Read the latest draft (3a). ;-)

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

Yep. The URL was there because we initially were hoping to push all of the
ECP wrapper material into the message. This didn't end up working out
because the client guys insist on not processing the full XML to get at some
of the information. I left it there because it didn't seem to be a problem
to allow it, but it still assumes you can bind the URL to the SP in metadata
of some form, in which case may as well just use Index.

The ProtocolBinding thing is sort of pointless now but initially the
metadata spec was more like ID-FF, where the binding isn't identified in the
same way that I ended up with.

So both are legal and not ambiguous or hard to support, but somewhat
anachronistic.

> 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.

I agree, but not everything can be in a spec or the spec becomes too large.
Implementation guidelines are a necessity. The intent is simply to allow the
SP to explicitly support account linking versus SSO without a new link. The
usual flow (I'm told) is:

- probe the IdP with IsPassive and AllowCreate=false to see if a quick login
is possible

- determine whether the user wishes to login or newly federate with the SP
and then request again without IsPassive and setting the flag to true

None of that is in the spec either.

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

You're right, I lost that argument and forgot I lost it. I don't like
duplicating text, and AFAICT profiles is just repeating core.

> 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 :).

I'm saying it is in the spec because it's useful (to some) when using the
"persistent" format. There's nothing to mention because the semantics aren't
specific to that format, it's just that I don't think the semantics are very
useful for the others.

> > 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?

Ultimately, it's up to the IdP in some sense, but a strict reading would say
no, since by definition every such identifier is "new". That's one reason I
wanted the default to be true.

A particular deployment (such as a federation) could choose to define a
policy that gets around the strictest interpretation. That's my guess as to
how this gets used in practice. Liberty will continue to use it as they did
before, and a lot of people will just ignore it.

-- Scott