InCommon metadata support

[Nick Roy <>]

On 1/10/18 5:00 PM, Cantor, Scott wrote:
> On 1/10/18, 6:50 PM, 
> "
>  on behalf of Tom Poage" 
> <
>  on behalf of 
> >
>  wrote:
> 
>>  Probably an off case, but a vendor registered a new instance of their 
>> application for us into InCommon and
>> inadvertently used another school's ACS URL. Given (what I think are) the 
>> several cases where SP ACS URLs span several
>> domains, I imagine a consistency/sanity check on ACS URLs is nigh on 
>> impossible.
> 
> There used to be a DNS-based approval step for cross-registering endpoints, 
> but as I understand it from a recent case, that's no longer done. They vet 
> the entityID, but the URLs are at the discretion of the registrant. If you 
> think about it, you have to approve somebody registering a host in your DNS 
> anyway, so them asking again is kind of superfluous.

That's right, for all these reasons (and more), we no longer inspect the
domains in endpoints at all.  Customers asked us for more flexibility to
allow them or their vendors to publish metadata for each other, and this
is one of the results of that request.  Two further results of that
request are that we now only do DCV-type checking (proof of control) on
domains in scopes and entityIDs.  If you as an InCommon Site
Administrator can convince a DNS registrant to set a DNS record with a
nonce that the InCommon RA gives you, you can assert that domain as the
basis for a scope and/or an entityID.  This is because people want to do
things like use outsourced / "cloud" IdPs.  So - we relaxed our
controls.  The community consultation on the scopes/entityIDs and proof
of control took place last year, and is at:

https://spaces.internet2.edu/x/TgL9Bg

The change regarding endpoint locations was made in consultation with
the InCommon TAC's operations advisory group and went info effect in April.

Best,

Nick

> 
> -- Scott
> 
> 
>