Codecov Report

Merging #1658 (78b782e) into master (9ae2211) will decrease coverage by 0.00%.
The diff coverage is 26.08%.

❗ Current head 78b782e differs from pull request most recent head 6765b78. Consider uploading reports for the commit 6765b78 to get more accurate results

@@             Coverage Diff              @@
##             master    #1658      +/-   ##
============================================
- Coverage     41.72%   41.71%   -0.01%     
+ Complexity     3660     3656       -4     
============================================
  Files           154      154              
  Lines         10721    10720       -1     
============================================
- Hits           4473     4472       -1     
  Misses         6248     6248              

"You need to set an entityID: a string that uniquely identifies this IdP or SP. It must be a URL or URN. We recommend to choose something that is likely to remain stable over time. Examples (replace example.com with your organization's domain name: https://example.com/saml-idp (or https://myapp.example.com/sp). The URL does not have to serve to any content, it's just an identifier."

If that's going to be our advice, we might as well continue to auto-generate it..

"An entityID should be chosen in a manner that minimizes the likelihood of it changing for political or technical reasons, including for example a change to a different software implementation or hosting provider."

It shouldn't hold an organization's domain name for that reason.

I'm totally in favour of giving explicit advice on how to generate a good entity ID. I'm also against automatically generating it, since we don't have absolutely any context to provide an identifier that's independent of the particular configuration / deployment, and as such, it is likely to be problematic in the future if anything in the deployment changes. Only the persons installing the software knows how they plan to use it, and as such, only they know what's a good unique identifier for it.

Regarding the discussion between URLs and URNs... is there any good practice or recommendations against using URNs? I'm not aware of any, and I think they have two immediate benefits:

1. They are not a URL, which means people won't try to access it, they won't get puzzled when it fails to load, and they won't expect metadata or anything to be available there.
2. They are more stable than URLs. The organisation's domain may change over time (e.g. some gov. TLD), while the URNs are less likely to be affected by those changes.

Let's separate out the discussion on what the advice should be.

I think all of the comments have been addressed and taken care of. Only thing left is the instructions to set a good entityID

\n This pull request has been automatically locked since there has \n not been any recent activity after it was closed.\n Please open a new issue for related bugs.