Limitations of valid entityIDs

[Ian Young]

On 3 Jul 2014, at 02:39, Nate Klingenstein <ndk at internet2.edu> wrote:

> There are a number of other providers who have not followed that rule, and it's been painful for them afterwards.  I would advise choosing a URI in a namespace that they control.

I'd second this advice. As well as running up against strict checks in implementations, I'd note that ad hoc entityIDs like this are very unlikely to be accepted by any of the larger federations so sticking with something like this probably locks them out from wider federation.

> On Jul 2, 2014, at 7:36 PM, Jacob Lundberg <jacob at collegenet.com>
>  wrote:
> 
>> Obviously we can't set up an integration with them using this entityID.
>> I am curious what sort of response is recommended in this situation.  Is
>> this considered a Shibboleth-specific limitation or SAML2, etc?  What is
>> the specific error or limitation?

It needs to be a valid absolute URI.

>> I guess maybe there is some list of
>> valid URL method strings and University_of_Heresville is not on the
>> list, so it can't be followed by a : like it is?

Interpreting "University_of_Heresville:SAML2" as an entityID would involve treating "University_of_Heresville" as the scheme name component of the URI, and yes there is a registry of those.

There is also a constraint that a scheme name cannot contain the "_" character. I suspect that's the actual "cause" of the error here, although I would recommend strongly against just taking the "_" characters out to "fix" it. The correct solution, as Nate says, is to change to an entityID which is an https:-scheme or http:-scheme URI based on a host name in a domain they own.

	-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20140703/97b440b0/attachment.bin